Deferred Rendering - High FPS Causing Empty Frames

[CypherStone]

Hi everyone!

I have come across an issue which I can't seem to fix and need some advice.

The problem is that I am developing my own deferred renderer and I am using SFML as the window framework and I am having rendering issues of anything above 1000fps. I know this is a very high framerate and not realistic at all in anyway but anything above this causes "black frames" or essentially a few empty frames, I have checked everything my side is populated but the only conclusion I can come to is that SFML doesn't wait to swap the buffers(?).

An example setup code I have:

window.clear(sf::Color::Black);

geometryPass();

// Output has been stored to render targets.

lightPass();

// At this point the rendering has been outputted to window buffer, ready to be swapped to the front buffer.

window.display();
 

The reason for the need for high fps is due to my university dissertation on speed and efficiency on a rendering technique but I need to get the deferred rendering implemented beforehand. My PC is currently running the project at just under 4000fps but again, flickering occurs at anything over 1000fps.

Any ideas and advice will be appreciated.

[binary1248]

First of all, you have to tell us whether you are using OpenGL or SFML's graphics module. I assume that the former is the case, since I really can't imagine sfml-graphics running at 4000 FPS .

If that is the case, you also have to tell us whether you are using any sfml-graphics objects as a convenience in your own code. They all come with their own subtleties.

Finally, without a bit more code, we hardly have an idea of what your code might look like and thus it is hard for us to tell what could possibly be going wrong. It might be a synchronization issue. At such high frame rates, you might be writing into your buffers faster than the GPU can even be finished with them, and it is common for the GPU to just spit out black screens if it doesn't like something. GPUs work in a highly asynchronous manner, and often they are lagging 3 frames behind the CPU (I've noticed this in every measurement I've ever done). So a call that finishes on the CPU does not mean that its associated command will be finished in nearly the same time on the GPU.

[CypherStone]

Thanks for the reply!

Sorry, was sort of in a rush doing the post and yes, I'm using just pure OpenGL.
I've just literally came to gather that it was a synchronization issue and your advice has helped me realise where it is happening.

So a call that finishes on the CPU does not mean that its associated command will be finished in nearly the same time on the GPU.

After calling to render each mesh, I've added glFinish() to allow time for synchronization, this has solved the problem of flickering but at the cost of the framerate, which I guess is acceptable due to how fast it is running.

Thank you and thanks for SFML as whole due to how much the framework has helped easing the process of development! 

[binary1248]

You should look into sync objects . They were made for fine grained control of CPU-GPU synchronization without having to resort to glFinish(), and when the correct strategy is employed, you can probably retain that 4000 FPS without blank screens occuring. This is how I did the measurements that showed me that the GPU always lags behind by 3 frames in the typical case, probably because of triple-buffering . glFinish() should never be used anyway, if there are alternatives...

[CypherStone]

You should look into sync objects . They were made for fine grained control of CPU-GPU synchronization without having to resort to glFinish(), and when the correct strategy is employed, you can probably retain that 4000 FPS without blank screens occuring. This is how I did the measurements that showed me that the GPU always lags behind by 3 frames in the typical case, probably because of triple-buffering . glFinish() should never be used anyway, if there are alternatives...

I believe you may have solved my problem! Thank you  !