Comment # 18
on bug 79223
from Pierre Ossman
(In reply to comment #17) > > glReadPixels is currently always synchronous with all Gallium based drivers, > as there's no hardware acceleration for PBOs yet. > Hmm... But I'm not consistently seeing a delay around glReadPixels(). The area is small though, so maybe it just goes too fast and any delays I see is waits for vblank... > 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. I dug around more and there are at least one glFlush() earlier. I can't swear it covers all the drawing, but at least parts of it. > (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(). It seems to fit this scenario well, yes. Unfortunately xbmc is very non-trivial, and also has a lot of abstraction to support other backends (like DirectX). Their current solution seems very similar to glXWaitForMscOML() though, but using m_glXWaitVideoSyncSGI() and conditionals. I guess the easiest solution for now is to look at that wait function (2.) and get rid of the degeneration condition. As for this bug, I'm not sure if you want to close it or not?
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
