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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 17 on bug 79223 from
(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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux