Hi, I have uploaded my changes to the r300_driver CVS. I haven't merged any changes to the R200 driver that might apply, and I haven't merged the drm-core changes. I will do that within the next days. Accelerated color buffer clear and basic clipping (without GL scissors) works, although I have noticed a flickering regression - this might be an interaction with updated Mesa CVS or a stupid merging mistake on my part, I'm not sure.
I have also uploaded a new patch for the DDX, which is especially necessary
for stability. With this patch, there are currently no known lockups, and I
have tested running multiple DRI clients thoroughly.
Securing against lockups comes at a price. The basic problem is that there
is too little communication between what the DRM writes to the ring buffer
and what the X server sends via indirect buffers. For now, the X server
will alway issues a single cp_idle ioctl before sending indirect buffers.
To quote my comment in radeon_accel.c:
/* TODO: Fix this more elegantly.
* 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
*/
My hope is that the X server will become just another DRM client as far as
accelerated rendering is concerned, which will eventually allow this to be
dealt with cleanly in the DRM. I am not interested in performance right
now, and since these idle calls seem to be the most foolproof thing to do,
I will leave them in.
cu,
Nicolai
pgpACVOpeXt02.pgp
Description: PGP signature
