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

Godot (4.3 beta 1): multi-threaded rendering; debug menu (1.2) reports different fps than godots inbuilt monitor. #26

Open
LeeWannacott opened this issue Jun 2, 2024 · 2 comments
Labels

Comments

@LeeWannacott
Copy link

LeeWannacott commented Jun 2, 2024

Hey Calinou,

I'm testing out the multi-threading rendering in Godot 4.3 beta 1. (I know its not considered ready to be a default yet)

debug menu shows around double the fps of Godots built-in monitor. With v-sync on multi-thread I get 165fps (165hz monitor) in Godot's monitor and (debug menu reports) 320-350 with multi-threaded. Without v-sync Godot reports ~500-700fps and debug-menu reports 1200-2000fps with multi.

image

Steps to reproduce:
Rendering -> Driver -> Threads -> select multi-threading.

Is this an issue with godot-debug-menu?, or with how Godot monitors fps? (or issues with both).

What I would expect:
v-sync on should match the monitors refresh rate when on. When v-sync is off, I would assume multi-rendering is giving the performance boost of double the fps (I'm guessing/hoping debug menu is correcter than godot in this instance?, but wrong when v-sync is on)?

Note: I haven't opened any issue in Godot for this.

Specs:
image

@LeeWannacott LeeWannacott changed the title Godot (4.3 beta 1): multi-threaded rendering; debug menu reports different fps than godots inbuilt monitor. Godot (4.3 beta 1): multi-threaded rendering; debug menu (1.2) reports different fps than godots inbuilt monitor. Jun 2, 2024
@LeeWannacott
Copy link
Author

LeeWannacott commented Jun 2, 2024

I also notice the game crashes (with no error) if you look at the editors Video RAM tab with multi-threaded on. (I assume they are already aware of this 🤔 )

@Calinou
Copy link
Member

Calinou commented Jun 2, 2024

This is likely because when using multi-threaded rendering, _process() time can no longer be assumed to match frame rendering time. I'd need a way to query the exact time a frame took to render to be able to give out accurate results when multi-threaded rendering is enabled.

@Calinou Calinou added the bug label Jun 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants