On Thu, 22 Jan 2004 00:16:52 +0100 Roland Scheidegger <[EMAIL PROTECTED]> wrote:
[snip]
xdemos/glthreads: I didn't have the courage to test this (I just didn't feel like rebooting ;-)) - in the past it always locked up immediately when at least 33 threads were specified, or locked up after some time if less than 33 threads were specified (generally, the more threads, the faster it would lock up). Can try that later if someone is interested in the results...
The 32 thread limit probably comes from the limited number of DMA buffers (happens to be 32) that have to be shared by all DRM clients, including the Xserver. Hmm, I wonder what it would take to make DRM clients fail more gracefully when they run out of DMA buffers. A lockup sounds like they are is trying to grab new DMA buffers before releasing old ones. This is only speculation though. I havn't looked at the code recently.
I believe this is what's happening. I think the DRM dma mechanism has all sorts of flaws if you start trying to use more than one dma buffer at a time, which the current radeon/r200 code does. It probably makes more sense to stop this behaviour and flush the cmdbuf whenever the dma buffer is filled.
Unfortunately, some behaviour, like the CVA drawelements path, really works better if the restriction is relaxed.
Keith
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
