<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - extra vsync when reading back pixels in xbmc"
href="https://bugs.freedesktop.org/show_bug.cgi?id=79223#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - extra vsync when reading back pixels in xbmc"
href="https://bugs.freedesktop.org/show_bug.cgi?id=79223">bug 79223</a>
from <span class="vcard"><a class="email" href="mailto:michel@daenzer.net" title="Michel Dänzer <michel@daenzer.net>"> <span class="fn">Michel Dänzer</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=79223#c14">comment #14</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=79223#c13">comment #13</a>)
> > (In reply to <a href="show_bug.cgi?id=79223#c12">comment #12</a>)
> > > 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?</span >
Yes, it's a limitation of DRI2 (at least without triple buffering, which is
hard to do with DRI2).
<span class="quote">> 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.</span >
glReadPixels is currently always synchronous with all Gallium based drivers, as
there's no hardware acceleration for PBOs yet.
<span class="quote">> > 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?</span >
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 <a href="show_bug.cgi?id=79223#c16">comment #16</a>)
<span class="quote">> 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?</span >
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().</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>