glFinish() as a blocking call to get frame onset time

[bsureshkrishna]

Hello,

I dont know much about Godot, and so this is a naive question, but hopefully along the right lines and posted in the right place.

I am interested in using Godot for visual experimental research, so being able to control exactly what is on the monitor at a given time. If vsync is on, the _process runs once per frame. Delta does give the interval between successive calls to _process - I assume this delta is either the interval between the previous call and the current call, or the interval between the two previous calls ?
However, it seems to me there are at least two ways in which the interval between successive calls to _process would vary from the inter-frame interval (on the monitor)... one is a lag between the call to _process and the succeeding frame display (because, say, Windows decided to steal some cycles) or because _process is called at different times within the inter-frame interval, since I am guessing that, within a frame, the call to _process is not tied to the Vsync or vertical blanking interval in any way. For example, _process() may run as fast as possible between frames and then if there are two buffers, the flip of the back buffer happens during the vertical blanking interval, but _process() may have finished well before that….

Put differently, in Godot, what can we know about the time logged about when _process is called, and the actual buffer flip and display at the openGL/monitor level ? In openGL, glFinish() waits until the graphics card is done and is ready to accept commands again, and so (with many caveats), gets the time at which the display happened (when vsync is on). Pyglet exposes this for example, and Psychopy uses this to know better (with caveats) when the stimulus came on. Now I am wondering if this particular option is exposed or available in Godot. I understand that as a game engine, Godot would much rather be doing other things during that time and this is not that important and so glFinish is not available ?

I did search for glFlush (which does not block) in the Github for GodotEngine and got nothing; searching for glFinish gave this -

but I have no idea what this means for my use-case.

Thank you !

[theraot]

Last time I checked, searching in Github will only give you results from the main branch.

Godot moved away from OpenGL ES in favor of Vulkan in Godot 4, and then OpenGL was reintroduced. That is from where you found that code.

It is likely that using Godot 3.x is better for your use case.

By the way, vulkan more options for synchronization than OpenGL. Although I cannot tell you how to get the same result as you would with OpenGL, I can't rule it out either.

In any case, search for VSync in project settings.

[bsureshkrishna]

ps. Not sure if this helps at all, but Unity has a QualitySettings.maxQueuedFrames parameter in Direct3D 11 and 12 at least.. that apparently roughly does the same thing..

[Calinou]

In Godot 4.3, the number of queued frames is exposed as a project setting:

This project setting is only effective for RenderingDevice-based rendering methods, i.e. Forward+ and Mobile (which use Vulkan).

Using a Frame Queue Size of 1 would achieve what you want here, but it's intentionally blocked as it leads to much lower performance (easily 20-30% slower than the default 2). You'd have to modify Godot's source code and recompile to lift this limitation:

https://github.com/godotengine/godot/blob/aaa4560729bf0161deb71789b47eba5623893845/core/config/project_settings.cpp#L1543

https://github.com/godotengine/godot/blob/aaa4560729bf0161deb71789b47eba5623893845/servers/rendering/rendering_device.cpp#L5051

A value of 1 allows minimizing input latency which could make sense for competitive games, but it really limits the number of graphics features you can use due to the overall lower rendering performance.

[bsureshkrishna]

Thank you, I will look into it ! Could I also find out here what exactly delta is in the call to _process ? Is it the interval between the previous call and the current call, or the interval between the two previous calls ? Or something else ?

[Calinou]

Could I also find out here what exactly delta is in the call to _process ? Is it the interval between the previous call and the current call

I believe it's the difference between the current call and the previous call, but I can't say for sure.

[bsureshkrishna]

Thank you !

I have 1 other question. Until recently, I always thought that if the GPU had already displayed a frame, and before the time to display the next frame, whatever commands were processed were all operations being done on the back buffer and then the back buffer was just flipped. It is clear form the existence of this Frame Queue Size parameter, that this is not how it works.. and that multiple frames can accumulate in a queue and apparently, it is not always the last/most recent frame that is presented on the next refresh... and perhaps it is even the next frame (though that could potentially lead to a lot of delay in display if frames are lining up)...

Could someone please explain ? Or is there some place where I can read about this model ? Thank you !