On Sun, 2004-09-26 at 09:12, Nicolai Haehnle wrote: > Hi, > > I'm trying to completely understand the command buffer stuff for my R300 > driver work, and I noticed something about the save_on_next_unlock code. > I'm concerned about the state_atom::check function. > The check functions use the current state of the context to figure out which > atoms must be emitted. Now, consider the following scenario: > 1. The driver unlocks and saves the state. > 2. The application issues a rendering command. The buffer is not full yet, > so FlushCmdBuf isn't called. > 3. The application changes some state (e.g. texture enable/disable) and > issues some more rendering commands. > 4. This time, FlushCmdBuf is called. It sees the lost_context flag and > triggers the state backup code. > 5. The state backup code still uses check() to see which state atoms are > active, but this produces wrong results because the state at time (2) at > the beginning of the command buffer is different from the state now. > > So either I haven't fully understood the mechanisms yet (please enlighten > me), or I found your bug ;) > Unfortunately, I can't verify this because I don't have R200 hardware.
Good catch. Fixing this isn't helping in my tests, but I've got a patch locally to fix it that'll go in. Reordering state emits seems to slowly but surely be fixing neverball's intro screen issues. Of those intro screen issues, all but the eye seemed to be related to the backup emit, and all seem tcl-related. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
