2010/5/5 Michel Dänzer <mic...@daenzer.net>: > On Die, 2010-05-04 at 10:36 -0700, Kristian HXXgsberg wrote: >> Module: Mesa >> Branch: master >> Commit: 06c72da97a1bce87bc4b3fb8e7e18bf966926acb >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=06c72da97a1bce87bc4b3fb8e7e18bf966926acb >> >> Author: Kristian Høgsberg <k...@bitplanet.net> >> Date: Tue May 4 13:35:23 2010 -0400 >> >> intel: Update renderbuffers unconditionally in intelSetTexBuffer2() >> >> --- >> >> src/mesa/drivers/dri/intel/intel_tex_image.c | 3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c >> b/src/mesa/drivers/dri/intel/intel_tex_image.c >> index 9db96ac..a0e734b 100644 >> --- a/src/mesa/drivers/dri/intel/intel_tex_image.c >> +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c >> @@ -728,8 +728,7 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target, >> if (!intelObj) >> return; >> >> - if (dPriv->lastStamp != dPriv->dri2.stamp) >> - intel_update_renderbuffers(pDRICtx, dPriv); >> + intel_update_renderbuffers(pDRICtx, dPriv); > > This seems like a step in the wrong direction — doing a round-trip to > the X server on each glXBindTexImageEXT() call kind of defeats the > purpose of 'direct' rendering.
It was a temporary step towards correctness :) > Of course, avoiding this only works correctly if the app calls > glXWaitX() between receiving damage events (or itself doing X operations > on the pixmap in question) and doing GL operations using the results, > and if glXWaitX() actually guarantees that the X operations before it > will be executed before the GL operations after it, which I don't think > is the case yet with DRI2 (as it's a NOP in libGL when there's no fake > front buffer). glXWaitX() will only guarantee that whatever X rendering is queued up on the display connection the GLX client uses is flushed and received by the X server. It doesn't guarantee anything about rendering from other X clients, which in the case of TFP by a compositor is what we're interested in. If you want to synchronize rendering between client and compositor you either need to grab the server (bad, simple approach) or introduce a sync protocol between the compositor and clients (better, compiz, gnome-shell, gtk+ support this as far as I know). But intel_update_renderbuffers() isn't about flushing or synchronizing new content, it's about getting new buffers in case the window got resized. We can't really shortcut that without the DRI2 invalidate event, but we have that now and I recently committed a few patches to use that when available. Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
