Felix Kühling wrote:
I think it's misleading to label this as a race - you don't know enough about what's happening inside the card to call it one thing or another.On 07 Dec 2002 02:07:03 +0100 Michel Dänzer <[EMAIL PROTECTED]> wrote:On Die, 2002-12-03 at 23:17, Felix Kühling wrote:
I just tried glaxium myself. And it freezes the Xserver here too. However, I don't have to move the window :-/ it always freezes about 3 seconds after I enter the game. I also tried it without TCL. Then it seemed to run fine (at least a few seconds longer than usual) and locked up as soon as I pushed a button. I also get the error message about IrqWait. That probably means that the hardware stops generating interrupts and is in some messed-up state. Would it be helpful for a developer with Radeon specs to see the last DMA buffer that was submitted to the card before it locked up?Unfortunately, the specs are missing a section 'DMA command streams which cause lockups'. ;)I could dump DMA buffers to a file and insert a radeonWaitForIdle right after submitting (and dumping) DMA buffers, so I'm sure I really get the last one *before* the card locks up.This sounds like a good plan for you to debug this though.I think I tracked it down to a race condition. If state is emitted while the card is still processing vertices this could be a potential problem, especially if things like texture offsets and sizes are changed. As a workaround I emit a RADEON_WAIT_3D into the cmd buffer before emitting state in radeon_emit_state_list. A patch is attached. This is really just a workaround. A proper fix would have to be in the kernel since a malicious client could still exploit the race condition.
What it is is a workaround for a unspecified failure that may be a hardware bug, or may be some unknown bug in the way we put together command streams, or in fact might be any one of a zillion other things.
I'd be interested to see if you can narrow down the circumstances in which it's necessary to emit this as it looks fairly heavy handed -- effectively disables all state pipelining in the hardware. Graphics cards not only know how to (normally) avoid statechanges scribbling on in-process vertices, they know how to handle statechanges without the overhead of a full pipeline flush.
It would be interesting to try and figure out which state changes are responsible for the lockups you're seeing...
Keith
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
