On Tue, 2004-01-13 at 14:51, Felix KÃhling wrote:
On Tue, 13 Jan 2004 14:38:37 +0100 Michel DÃnzer <[EMAIL PROTECTED]> wrote:
On Mon, 2004-01-12 at 17:44, Michel DÃnzer wrote:
There are still minor problems, e.g. in the xscreensaver endgame hack, but those might be related to colour material (known to horribly break trackballs, e.g.).
The funny thing about the problem in endgame is that it's much less severe if run as
R200_DEBUG=state /usr/lib/xscreensaver/endgame 2>/dev/null
as opposed to just
/usr/lib/xscreensaver/endgame
A timing problem?
Apparently...
Then maybe the old lockup workaround for radeon would solve this. It put a "wait for 3D idle" on the command queue before emitting the state. It's a performance hit though. Even if it's not adopted as final solution it could prove that these problems are caused by emit_state oddities (or maybe not ;-).
I thought of this as well, but it doesn't make a difference.
What makes the difference is calling _mesa_lookup_enum_by_nr() at the beginning of r200Enable(), probably due to the delay. Granted, it doesn't help with the reflections, and if those are disabled, it doesn't help at all, but I don't understand why delaying there would have any effect...
Does a usleep(1) in the same place have the same effect?
Does the hardware actually "see" the delay? It will only be exposed to delays *between* command buffers - delays aren't preserved within a buffer submitted to hardware as a whole...
Keith
------------------------------------------------------- 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
