[Android] eglSwapBuffers with triple buffering

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

[Android] eglSwapBuffers with triple buffering

Post by Hotshot5000 »

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.
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

No, eglSwapBuffers doesn't need to be called twice, else you're negating triple buffer. Normally with double buffer you do
  • Render to A, present B
  • Render to B, present A
  • Render to A, present B
  • Render to B, present A
The 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.
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.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: [Android] eglSwapBuffers with triple buffering

Post by Zonder »

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...
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

Re: [Android] eglSwapBuffers with triple buffering

Post by Hotshot5000 »

dark_sylinc wrote:No, eglSwapBuffers doesn't need to be called twice, else you're negating triple buffer. Normally with double buffer you do
  • Render to A, present B
  • Render to B, present A
  • Render to A, present B
  • Render to B, present A
The 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.
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.
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?

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.
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

Hotshot5000 wrote:but when presenting A is finished it will jump directly to presenting C, skipping presenting B. Am I correct in this?
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)
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.
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

Re: [Android] eglSwapBuffers with triple buffering

Post by Hotshot5000 »

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.
Post Reply