From: Leif D. <lde...@re...> - 2003-02-05 22:27:05
|
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 |