CVS lock ?

[Michel Dänzer]

On Thu, 2004-12-16 at 07:43 -0500, Vladimir Dergachev wrote:
> 
> +    /* TODO: Fix this more elegantly.

Why do you commit code that contains so many question marks without any
prior discussion?

> +     * Sometimes (especially with multiple DRI clients), this code
> +     * runs immediately after a DRI client issues a rendering command.
> +     *
> +     * The accel code regularly inserts WAIT_UNTIL_IDLE into the
> +     * command buffer that is sent with the indirect buffer below.
> +     * The accel code fails to set the 3D cache flush registers for
> +     * the R300 before sending WAIT_UNTIL_IDLE. Sending a cache flush
> +     * on these new registers is not necessary for pure 2D functionality,
> +     * but it *is* necessary after 3D operations.
> +     * Without the cache flushes before WAIT_UNTIL_IDLE, the R300 locks up.
> +     *
> +     * The CP_IDLE call into the DRM indirectly flushes all caches and
> +     * thus avoids the lockup problem, but the solution is far from ideal.
> +     * Better solutions could be:
> +     *  - always flush caches when entering the X server
> +     *  - track the type of rendering commands somewhere and issue
> +     *    cache flushes when they change
> +     * However, I don't feel confident enough with the control flow
> +     * inside the X server to implement either fix. -- nh

RADEONEnterServer() gets called whenever the X server grabs the hardware
lock after a 3D client held it.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer