From: Ian R. <id...@us...> - 2003-02-06 18:24:34
|
Leif Delgass wrote: > On Wed, 5 Feb 2003, Ian Romanick wrote: > >>Leif Delgass wrote: >> >>Those assumptions seem to be correct. For the most part, your patch >>looks a lot like what I have in my local tree. :) The only thing I did >>different was I overlapped the zero and one tables. >> >>static GLuint radeon_zero_alpha[] = >>{ >> RADEON_ALPHA_ARG_A_ZERO, >> RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A, >> RADEON_ALPHA_ARG_A_ZERO >>}; > > OK, so you add one to op for GL_ONE then? Right. It's not that big of a deal either way. I mean, it just saves 4 bytes of static data. :) I also made 'op' non-const and arranged it to just increment op and fall-through to the GL_ZERO. I was a little iffy about that change. >>>Does this look right? Ian, you mentioned seeing problems with SUBTRACT, >>>and in an older message you were wondering about the difference between >>>how r100 and r200 handle PREVIOUS. Two questions: Did you come to any >>>conclusions on either of those questions? and what are you using to test >>>this? I was thinking of trying to add support to the glean texcombine >>>test, but I wanted to see if you had something already. >> >>WRT GL_PREVIOUS, my conclusion is that the I didn't understand the way >>that r200 texture combiners work. :) It's actually quite different from >>the r100. Based on numerous glean tests, both are correct. >> >>About GL_SUBTRACT on r100, I just don't know. I hacked up the >>ttexcombine test in glean to test GL_MODULATE_*_ATI and GL_SUBTRACT. >>EVERY mode that uses subtraction failed on the r100. Looking at the >>"expected" and "got" output from glean, I could see that it was >>expecting the right thing, but the output was wrong. >> >>>Also, should I go ahead and commit my revised texmem patch? >> >>Yes. > > OK, will do. Do you want to commit your patch for combine3 to texmem? I > don't have an R200, so I can't test that, but it looks like it should be > easy to add there too. If SUBTRACT is the only problem, I don't think > that should prevent you committing it, as that's apparently a problem even > without the extension. I hadn't commited it yet because I have some other stuff in my tree (that I was too lazy to separate out) and I wanted to track down the problem with GL_SUBTRACT. I think if you commit your patch, it will probably get into the tree faster than if I do mine. I've had to dedicate a lot of my time this week to other stuff. :-/ I should be able to whip something up for R200 next week. I think I'll also have a fix for the DOT3 problems that were reported on R200 some months ago. It's amazing how much easier it is to fix driver bugs when you actually have hardware to test. :) > Regarding glean, I need to test again, but I was seeing some other > failures even with the mesa-4-0-4 and trunk. I think there were some > off-by-one scissor errors and a couple of others. One question I had was > whether the Radeon driver should really advertise a destination alpha > channel. At depth 24, glxinfo reports 8 bit alpha for color and accum > buffers. This doesn't seem to be consistent across the drivers. Some > don't even seem to be consistent for a given entry between alpha bits, > alpha mask, and buffer size. Here's a little chart I made a while back: Some time ago there were some scissor problems that caused every glean test to always fail. I think those were fixed in the radeon and r200 drivers about 6 months ago. On my R100 the only tests that failed for me were the subtract tests and the alpha channel in some combinations of DOT3. I haven't had a chance to dig into that either. Intuitively, it seems that NONE of these drivers, except Mach64 & Rage128, is reporting the right thing. There seems to be at least one field wrong in each. I'm not 100% clear on the meaning of all the fields, so I could be wrong. Hopefully Brian or Keith can enlighten us on what they should mean. :) I'm mostly unsure of what amask means in this context. > Mach64/R128 > r g b a amask bsz ar ag ab aa Xvisual dpth > 5 6 5 0 00000000 16 16 16 16 0 16 > 8 8 8 0 00000000 24 16 16 16 0 24 > > Radeon/R200 > r g b a amask bsz ar ag ab aa Xvisual dpth > 5 6 5 0 00000000 16 16 16 16 0 16 > 8 8 8 8 ff000000 24 16 16 16 16 24 Shouldn't this be one of the following? 8 8 8 0 00000000 32 16 16 16 0 24 8 8 8 8 00000000 32 16 16 16 16 24 I know that in the XFree86 Radeon driver in 24-bit each pixel is actually 4 bytes, whether the alpha channel is used or not. > MGA > r g b a amask bsz ar ag ab aa Xvisual dpth > 5 6 5 0 00000000 16 16 16 16 0 16 > 8 8 8 8 00000000 32 16 16 16 0 24 8 8 8 8 00000000 32 16 16 16 16 24 > GLINT > r g b a amask bsz ar ag ab aa Xvisual dpth > 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn->depth) > 8 8 8 0 00000000 32 16 16 16 0 24 (pScrn->depth) This might be right. > tdfx > r g b a amask bsz ar ag ab aa Xvisual dpth > 5 6 5 0 00000000 16 16 16 16 0 16 > 8 8 8 0 00000000 16 16 16 16 0 24 (pScrn->bitsPerPixel) > 8 8 8 8 ff000000 16 16 16 16 16 32 (pScrn->bitsPerPixel) 8 8 8 0 00000000 32 16 16 16 0 24 8 8 8 8 00000000 32 16 16 16 16 24 |