Comment # 17
on bug 79223
from Michel Dänzer
(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().
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
