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. cu, Nicolai
pgp10ZHxbwSWz.pgp
Description: PGP signature
