Leif Delgass wrote:
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.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?
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.OK, will do. Do you want to commit your patch for combine3 to texmem? IWRT 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.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.
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.
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 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. :)
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.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:
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.
Shouldn't this be one of the following?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
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 ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
