From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 79223] extra vsync when reading back pixels in xbmc Date: Tue, 03 Jun 2014 06:34:49 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0683326430==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 164666E6B5 for ; Mon, 2 Jun 2014 23:34:49 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0683326430== Content-Type: multipart/alternative; boundary="1401777289.bbB710.12007"; charset="us-ascii" --1401777289.bbB710.12007 Date: Tue, 3 Jun 2014 06:34:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D79223 --- Comment #17 from Michel D=C3=A4nzer --- (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 p= oint > > > where I'll have to switch over to looking in the X server soon... > >=20 > > Yep, it's waiting for DRI2 buffer information from the X server, which = is > > delayed until the previous buffer swap actually finishes. >=20 > 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 glFinis= h() > > before glXSwapBuffers(). >=20 > 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 s= pent 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 m= ay 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.? >=20 > Now is that an unreasonable expectation? I'm afraid so. It would be better to use something like GLX_OML_sync_contro= l's glXSwapBuffersMscOML() for timing buffer swaps, instead of explicitly waiti= ng for vblank and then calling glXSwapBuffers(). --=20 You are receiving this mail because: You are the assignee for the bug. --1401777289.bbB710.12007 Date: Tue, 3 Jun 2014 06:34:49 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 17 on bug 79223<= /a> from Michel D=C3=A4nzer
(In reply to comment #=
14)
> (In reply to comment #13)
> > (In reply to comment #12<=
/a>)
> > > Down to dri2_drawable_get_buffers() now. I assume I'll be hi=
tting a point
> > > where I'll have to switch over to looking in the X server so=
on...
> >=20
> > Yep, it's waiting for DRI2 buffer information from the X server, =
which is
> > delayed until the previous buffer swap actually finishes.
>=20
> Is that expected behaviour? I.e. am I chasing an already known limitat=
ion?

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 comm=
and 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().
>=20
> 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 ca=
n 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 s=
pent
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 m=
ay
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.?
>=20
> Now is that an unreasonable expectation?

I'm afraid so. It would be better to use something like GLX_OML_sync_contro=
l's
glXSwapBuffersMscOML() for timing buffer swaps, instead of explicitly waiti=
ng
for vblank and then calling glXSwapBuffers().


You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1401777289.bbB710.12007-- --===============0683326430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0683326430==--