Performance between 3.5.3 and 3.6.b5 framerate/shader/material worse

[elvisish]

Tested versions

3.6.b5

System information

Windows 10

Issue description

I've been testing a project I've been working on in 3.5 for 2 years in 3.6 and there was a noticeably worse framerate/performance in 3.6:

3.5 always has a solid framerate on 165 on my laptop:

But trying in 3.6 it looks stuttery in comparison:

I am using a few shader materials, one of which has its transform matrix update on each frame, which is fine in 3.5 but there's definitely more draw calls in 3.6:

3.5:

3.6:

I'm not sure if this would affect the framerate to this degree, but it is a significant increase from 3.5. I tried making a barebones test movement project for example purposes, but the performance returned to its usual speed once most of the game was removed so I'm not sure how I can share an example of this without uploading my entire game.

Steps to reproduce

Load a game that uses a few shader-materials from 3.5 into 3.6 and compare the draw calls.

Minimal reproduction project (MRP)

N/A (I attempted to make one but it wasn't possible for this example).

[akien-mga]

Could you test earlier 3.6 beta releases to pinpoint when the regression started?

CC @lawnjelly

[clayjohn]

Could you also provide some more information about the game, for example is it 2D or 3D?

[lawnjelly]

Yes, there have been a lot of changes since 3.5, with no MRP it will be up to you to work out what feature causes the regression, unless we get other reports.

• bisecting the betas will let us know ball park
• some features you can turn on and off in project settings
• building from source will allow you to bisect to commit

You can also give access to maintainer to your private project temporarily we sometimes do this. Note i will be away till friday with limited internet.

[elvisish]

Could you test earlier 3.6 beta releases to pinpoint when the regression started?

CC @lawnjelly

Just as great feeling and looking in 3.6.b1:

https://github.com/godotengine/godot/assets/16231628/bb05f3f0-d8e8-4bc8-a4f0-e6fe9fc7bb08

Also good in 3.6.b2, but almost imperceivably feels a little stuttery:

https://github.com/godotengine/godot/assets/16231628/ef66a432-3438-4834-b1eb-bc3e6737ca49

Strangely it claims to be running at 165 in 3.5.b3, but this is the first one that looks un-interpolated (as if the physics interpolation is broken or changed):

https://github.com/godotengine/godot/assets/16231628/4d5b6c0a-f067-4254-83b0-d19ceb8a6000

And the same in 3.6.b4:

https://github.com/godotengine/godot/assets/16231628/cce56ea7-6df6-4adc-991d-a89dafa83451

Can I also clarify that actually the game reports as being 165fps when it's fully focused, the lower FPS seems to be from when I switched to the monitor tab but it actually shows a solid 165fps when focused. It looks unplayably stuttery on a 165hz monitor though, and only 3.6.b1 (and possibly 3.6.b2) still look as good as 3.5 did.

FRAPS even reports it at being 165fps, so I can only think that between beta 1 and beta 3 the physics interpolation changed and its somehow making the framerate appear at a non-equally divisible framerate comparatively to 165hz?

[lawnjelly]

I"ve been looking through as best I can with limited internet, but beta 3 coiincides with 2d physics interpolation. One possibility is I made a small adjustment to the place where ticking was called for 3d to unify with 2d.

I was aware at the time to watch for regressions and this may be related, if so it may be easily fixed. I will do more on this from saturday when home.

[elvisish]

I"ve been looking through as best I can with limited internet, but beta 3 coiincides with 2d physics interpolation. One possibility is I made a small adjustment to the place where ticking was called for 3d to unify with 2d.

I was aware at the time to watch for regressions and this may be related, if so it may be easily fixed. I will do more on this from saturday when home.

That definitely sounds potential, if you need access to my test project I can always privately share it but it is huge after 2 years of work so I'm not sure if it's the best way to compare. It looks very much as though it's an interpolation bug (though why it hasn't been reported until now is surprising, maybe fewer people are on 3.6 with 165hz screens?)

[lawnjelly]

I'm finally able to have a look at this.

It looks very much as though it's an interpolation bug (though why it hasn't been reported until now is surprising, maybe fewer people are on 3.6 with 165hz screens?)

This may be related to this:

I tried making a barebones test movement project for example purposes, but the performance returned to its usual speed once most of the game was removed so I'm not sure how I can share an example of this without uploading my entire game.

Some basic testing of the 3D physics interpolation looks ok from my side, so it may be something specific in your project that is triggering the problem, so it will definitely be useful if you can give me access + instructions. I wouldn't worry about the project size, I think the largest supplied MRP I've had to date has been around 30gb. :grin:

Are you using multithreaded rendering by any chance?

(Just checked, and the multithread rendering is glitchy with interpolation, I should probably add this to documentation, as the multithread rendering option seems to just cause problems in general in my experience, and I'm not convinced it is any faster. :grinning: )

[elvisish]

Some basic testing of the 3D physics interpolation looks ok from my side, so it may be something specific in your project that is triggering the problem, so it will definitely be useful if you can give me access + instructions. I wouldn't worry about the project size, I think the largest supplied MRP I've had to date has been around 30gb. 😁

Sure thing, would it be best if I add you to access my backup repro for the project or send a link to you? (I've not done this before)

Are you using multithreaded rendering by any chance?

Actually no, it's on single-safe still as I think it can be a little unstable using multi-threaded?

[lawnjelly]

Sure thing, would it be best if I add you to access my backup repro for the project or send a link to you? (I've not done this before)

Either is fine, if you add me temporarily access on github, or send me a message with link to my twitter account ( https://twitter.com/lawnjelly ) I'll check there. :+1:

[lawnjelly]

Just to keep this updated, by looking at this project, @elvisish noticed that the Viewport defaults to interpolation mode OFF rather than INHERIT. This explains why nothing underneath the viewport was interpolating.

This makes sense because ViewportContainer derives from Container which derives from Control, and all controls now default to OFF rather than INHERIT since 2D interpolation was added. This is to prevent user interface elements from interpolating (by default anyway, you can explicitly set them if you are prepared to handle reset_physics_interpolation() for them and you want that effect).

So I'm currently looking at which we should have e.g. a special case for Viewport (keep it as INHERIT) or have this mentioned in the docs. :thinking:

[lawnjelly]

Fixed by #92152.