[Bug 79223] extra vsync when reading back pixels in xbmc

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79223

--- Comment #18 from Pierre Ossman <pierre-bugzilla at ossman.eu> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140603/97b4e490/attachment.html>