Hi Nicolai,
Thanks for putting your code in CVS :)
More below,
On Fri, 15 Oct 2004, Nicolai Haehnle wrote:
Hi,
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 */
This looks like a hardware issue - from the datasheet I would have expected the WAIT_FOR_3D_IDLE as well as ISYNC register settings to work properly.
A simple solution might be to do a cache flush every time we do wait_for_idle in Xserver. Since, presumably, it does 2d operations only this should have negligible impact.
best
Vladimir Dergachev
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
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
