Flickering screen in Neverball on drm-radeon-testing

[Mario Kleiner]

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.kleiner at 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)