Re: R200 - save_on_next_unlock
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
R200 - save_on_next_unlock
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
Re: r200 depth readback problem.
Philipp Klaus Krause wrote: Has anyone else experienced problems reading back depth values with the r200 driver? Whenever I read back a depth value from the right part (about a seventh or eighth of the width) I get 1.0. Reading back from other parts of the buffer works OK as does software Mesa everywhere. There is an extensive calculation to derive the address of a particular depth value in the depth buffer, which is tiled & swizzled. Have a look in r200_span.c. If one of the terms of that calculation is incorrect, it could produce the symptoms you're seeing. Keith --- 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
