Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
elvisish opened this issue May 13, 2024 · 11 comments
Closed

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

elvisish opened this issue May 13, 2024 · 11 comments

Comments

@elvisish
Copy link

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:
image

But trying in 3.6 it looks stuttery in comparison:
image

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:
image

3.6:
image

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
Copy link
Member

akien-mga commented May 13, 2024

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

CC @lawnjelly

@clayjohn
Copy link
Member

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

@lawnjelly
Copy link
Member

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
Copy link
Author

elvisish commented May 14, 2024

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:
image
image

2024-05-14.13-29-30-00.00.04.477-00.00.09.075.mp4

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

2024-05-14.13-35-23-00.00.04.595-00.00.10.599.mp4

image

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):
image
image

2024-05-14.13-39-32-00.00.04.562-00.00.10.548.mp4

And the same in 3.6.b4:

image

2024-05-14.13-44-23-00.00.03.101-00.00.07.528.mp4

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

lawnjelly commented May 19, 2024

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. 😁

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. 😀 )

@elvisish
Copy link
Author

elvisish commented May 19, 2024

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
Copy link
Member

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. 👍

@lawnjelly
Copy link
Member

lawnjelly commented May 20, 2024

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. 🤔

@lawnjelly
Copy link
Member

Fixed by #92152.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants