On Wed, 5 Feb 2003, Ian Romanick wrote:
> Leif Delgass wrote:
> > Ian, now that you've merged in the software support for combine3 from the
> > Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
> > (impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
> > the registers. I'm attaching a patch of what I've got. My assumptions
> > are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
> > corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
> > I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
> > _COMP_ARG_A to get GL_ONE.
>
> 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?
> > 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.
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:
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
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
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)
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)
--
Leif Delgass
http://www.retinalburn.net
-------------------------------------------------------
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
