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. 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). -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
