A patch is attached. The order in which state atoms are emitted now is pretty arbitrary. It may be worth finding out exactly which permutations of state changes trigger the lockup. In the interest of security we could detect them in the DRM driver and emit a 3D idle to prevent an engine lockup. Finding all these permutations would take a lot of time (and reboots) though and it may even be too late to prevent a lockup when such a condition is detected. But maybe someone with hardware docs has a good guess, like dependencies of different state change commands that could cause inconsistencies if certain pairs of them are emitted in the wrong order.
On the other hand we may just clean up my hack and be content with it. How do people feel about this?
Do you think that this could be useful for r200, too?
I can't tell and I don't know about reproducible lockups on r200. If you are experiencing lockups, you can try if this helps.
I don't experience reproducible lockups (well I do with multiple simultaneous OGL apps like everyone else but this is a different topic), but I've attached that patch to the r200 driver anyway.
This did change the random color flashing all apps with a bit more complex lighting experience (like nwn, specviewperf 7.1) quite a bit - sometimes it got worse, sometimes better, but definitely different which I think is remarkable (well of course if I didn't suspect this I wouldn't have tried it).
I've just used the order of the atoms as defined in r200_context.h, I have no idea what the correct order would be (if such a thing even exists).
Roland
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
