On Jun 4, 2010, at 7:27 PM, Michel Dänzer wrote:
On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote:
I think your analysis is spot on.
The ideal solution would probably be to make the kernel block in the
command stream (CS) submission ioctl if the CS renders to (and
from?) a
buffer object (BO) which is involved in a pending swap.
Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help
here, YMMV.
I think that is what the Intel drm does. Your dri2-flicker-mesa.diff
patch makes sense to me as a newbie with limited understanding. If
this ends up calling DRI2GetBuffers... in the server, it will block
in DRI2ThrottleClient until the swap completes.
I doubt that the dri2-flicker-xf86-video-ati.diff patch has a real
effect? For a regular glXSwapBuffers() command, the code-path isn't
taken, where you placed the DRI2BlockClient() call, so it can't have
an effect. If it would be taken as part of some call to the new
glXSwapBuffersMscOML() function, it would likely do bad things(tm)
which are against the purpose of this new extension.
-mario
*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: mario.klei...@tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax: +49 (0)7071/601-616
www: http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
