MatrixQW wrote: ↑24 May 2021, 07:22
If not GPU-bounded, render queue can't be 0 (I think) so it must be something.
I didn't say the render queue was "0," or
wasn't reduced with these settings in non-GPU-bound scenarios, I said they don't typically reduce actual frame
delay further in said scenarios, as the render queue is not as filled (or sometimes not filled at all).
If the render queue is set to "1," it doesn't mean there is always 1 pre-rendered frame, it means there can now only be
up to "1" pre-rendered frame created in advance at a time. Same goes for when it's set to 2, 3, etc...
And by the way, unlike LLM "On," which lowers the maximum render queue count, Reflex technically bypasses the render queue entirely by dynamically setting an FPS limit just under the current framerate to avoid max GPU usage, which, in turn, can prevent pre-rendered frames from queuing up in the first place.
If there is one or more pre-rendered frame in the queue, it means the CPU is creating new frame information in advance while waiting on the GPU to complete render of one or more frames based on now previous CPU-generated frame info, which is why render queue settings typically only help in scenarios where the GPU is maxed out to the point that its still busy working on rendering a frame or multiple frames based on older CPU-generated frame info.
Render queue "input lag," in this sense, is very similar to what happens with double buffer V-SYNC backpressure, just earlier in the process; the frames are displaying in sequence, but what is being displayed has been delayed, and thus isn't the reflecting the latest information.
The goal with any render queue reduction-related setting is to ensure that the CPU > GPU frame information handover is as close to 1:1 as possible, that is, the latest CPU frame info being handed over is what the next rendered GPU frame to be delivered is generated off of.