[Android] eglSwapBuffers with triple buffering
-
- OGRE Contributor
- Posts: 226
- Joined: Thu Oct 14, 2010 12:30 pm
- x 56
[Android] eglSwapBuffers with triple buffering
It's not clear to me from the egl docs if eglSwapBuffers() on a native window will actually get me the drawn contents on the screen if I'm using triple buffering. Might sound like a stupid question but would I need something like 2 eglSwapBuffers() to get things on screen for the just drawn content? I just need to be sure because some devices might use double buffering where one eglSwapBuffers() would work and others would need two eglSwapBuffers() to get the first drawn thing on the screen to show. I'm trying to render one static image, basically call Root::renderOneFrame() and then do an eglSwapBuffers() without continuous rendering in a loop.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Android] eglSwapBuffers with triple buffering
No, eglSwapBuffers doesn't need to be called twice, else you're negating triple buffer. Normally with double buffer you do
But with triple buffer you get ABC, so if you're presenting A, and done with B; you can start working in C. If C takes longer than expected, you still have the headroom start that finishing with B gave you; hence you won't miss any VBlank.
- Render to A, present B
- Render to B, present A
- Render to A, present B
- Render to B, present A
But with triple buffer you get ABC, so if you're presenting A, and done with B; you can start working in C. If C takes longer than expected, you still have the headroom start that finishing with B gave you; hence you won't miss any VBlank.
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: [Android] eglSwapBuffers with triple buffering
I think he's referring to the first frame render for a title screen maybe?
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
- OGRE Contributor
- Posts: 226
- Joined: Thu Oct 14, 2010 12:30 pm
- x 56
Re: [Android] eglSwapBuffers with triple buffering
So basically if I am presenting A, done with rendering in B and called an eglSwapBuffers() but I'm still blocked because I am still presenting A, I can get on rendering to C and call eglSwapBuffers(), but when presenting A is finished it will jump directly to presenting C, skipping presenting B. Am I correct in this?dark_sylinc wrote:No, eglSwapBuffers doesn't need to be called twice, else you're negating triple buffer. Normally with double buffer you doThe thing is, while you're presenting A, if you're done with B too early, you'll find the GPU goes to sleep. If the next frame takes too long to render; you'll miss a VBlank.
- Render to A, present B
- Render to B, present A
- Render to A, present B
- Render to B, present A
But with triple buffer you get ABC, so if you're presenting A, and done with B; you can start working in C. If C takes longer than expected, you still have the headroom start that finishing with B gave you; hence you won't miss any VBlank.
http://gamedev.stackexchange.com/questi ... games[url][/url] seems to answer my question: you always get the latest buffer B or C when finally vsync does its job and A has been presented.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Android] eglSwapBuffers with triple buffering
If both B & C are ready, and A is about to be done from being presented, whether the next one to present will be B or C really depends on the API and driver (obviously presenting C is the lowest latency option; but presenting B offers more stability and gives more headroom)Hotshot5000 wrote:but when presenting A is finished it will jump directly to presenting C, skipping presenting B. Am I correct in this?
IIRC presenting B then C was called "render ahead"; in D3D this can be controlled via IDXGIDevice1::SetMaximumFrameLatency.
Beware if you get deeper into these topics (latency, VSync, presentation timing) you'll find the industry performs horrible bad practices. This wasn't a topic getting the attention it deserved until VR came in (specially since until VR, higher framerates in reviews meant better marketing; nobody was measuring latency).
If you see Valve's VR presentation from 2015; you'll see they use an external process that runs on a busy spin loop to measure VSync intervals and report them to the main process through shared memory in order to get accurate timing and reduce latency and keep GPU bubbles to a minimum. These are nasty workarounds for the "good" APIs such as D3D11.
You can begin to imagine the wildlife that must be in the "bad" APIs like GLES.
-
- OGRE Contributor
- Posts: 226
- Joined: Thu Oct 14, 2010 12:30 pm
- x 56
Re: [Android] eglSwapBuffers with triple buffering
Given my experience with OpenGL ES I will no longer pursue this 'stop the rendering pipeline to freeze a loading screen' on screen. I was hoping to not waste a few cycles with rendering the same thing over and over, but in the future I was going to add a progress bar on the loading screen so it only was a temporary solution anyway. The conclusion is that I will continuously render everything so that I won't have to think about what the driver might do and what the last rendered thing might be.