https://bugs.freedesktop.org/show_bug.cgi?id=79223
--- Comment #17 from Michel Dänzer michel@daenzer.net --- (In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12)
Down to dri2_drawable_get_buffers() now. I assume I'll be hitting a point where I'll have to switch over to looking in the X server soon...
Yep, it's waiting for DRI2 buffer information from the X server, which is delayed until the previous buffer swap actually finishes.
Is that expected behaviour? I.e. am I chasing an already known limitation?
Yes, it's a limitation of DRI2 (at least without triple buffering, which is hard to do with DRI2).
The xbmc code seems to assume that those gl command will execute asynchronously as it is using querires to determine when the rendering and glReadPixels() is done.
glReadPixels is currently always synchronous with all Gallium based drivers, as there's no hardware acceleration for PBOs yet.
FWIW, you might get somewhat less confusing timings if you call glFinish() before glXSwapBuffers().
I'll play around with it. But that doesn't sound like a good solution upstream as I guess it will remove parallelism for the drivers that can do all of this in the background?
Of course, this wasn't intended as a solution but just as a debugging aid to try and make your timings correspond better to where the time is actually spent in the driver / hardware.
That said, in the scenarios you described, there would need to be at least a glFlush() call before waiting for vblank, otherwise the driver / hardware may not even start actually rendering the frame before the glXSwapBuffers call.
(In reply to comment #16)
I guess the behaviour that xbmc is expecting is that the only time it will wait for a vblank, is that explicit vblank waiting in step 2.?
Now is that an unreasonable expectation?
I'm afraid so. It would be better to use something like GLX_OML_sync_control's glXSwapBuffersMscOML() for timing buffer swaps, instead of explicitly waiting for vblank and then calling glXSwapBuffers().