Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
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 amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 24 16 16 16 0 24
Radeon/R200
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 ff00 24 16 16 16 16 24
Shouldn't this be one of the following?
8 8 8 0 32 16 16 16 0 24
8 8 8 8 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 amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
8 8 8 8 32 16 16 16 16 24
GLINT
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth)
8 8 8 0 32 16 16 16 0 24 (pScrn-depth)
This might be right.
tdfx
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel)
8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel)
8 8 8
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Wed, 5 Feb 2003, Leif Delgass wrote: 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 went ahead and committed my texmem changes as well as combine3 for radeon and r200 (including the change to the zero/one table). I can't test the r200 version, but it looks almost identical to R100. I noticed that in the check for the scale factor in the Radeon driver, it uses RADEON_SCALE_4X for dot3. Should that be RADEON_SCALE_1X? That's what the r200 driver uses for the EXT version (R200_TX[C,A]_SCALE_1X). -- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Leif Delgass wrote: On Wed, 5 Feb 2003, Leif Delgass wrote: 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 went ahead and committed my texmem changes as well as combine3 for radeon and r200 (including the change to the zero/one table). I can't test the r200 version, but it looks almost identical to R100. Cool. I can't think of any reason why those changes couldn't also go into the trunk. I noticed that in the check for the scale factor in the Radeon driver, it uses RADEON_SCALE_4X for dot3. Should that be RADEON_SCALE_1X? That's what the r200 driver uses for the EXT version (R200_TX[C,A]_SCALE_1X). There's two issues at play here. The first is that the R200 driver is wrong. The second is that R100 cannot fully implement the ARB version of the extension. From table 3.20, the equation for DOT3_RGB is: DOT3_RGB_ARB4*((Arg0_r - 0.5)*(Arg1_r - 0.5) + (Arg0_g - 0.5)*(Arg1_g - 0.5) + (Arg0_b - 0.5)*(Arg1_b - 0.5)) http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_dot3.txt http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_env_dot3.txt In addition, RGB_SCALE is applied. On BOTH R100 R200, the DOT3 combine mode does not automatically apply the '4*' in the combine equation. On r100, the only way to get this is by setting an RGB_SCALE of 4x. This is why the R100 driver falls back to software rasterization for DOT3_RGB_ARB when RGB_SCALE != 1x. The R100 cannot handle an RGB_SCALE larger than 4x. I actually asked some ATI engineers at the September ARB meeting about this. This does not apply to the EXT version because it ignores the scale value. That's why the EXT and ARB versions have different enumerants. This is part of the problem on R200 as well. The other part of the problem is that R200 does not automatically do the '- 0.5' bias. The driver has to set R200_TXC_SCALE_ARG_[AB] and R200_TXC_BIAS_ARG_[AB]. It also has to increase the post-scale by 1 (i.e., a scale of 1x becomes 2x, 2x becomes 4x, and 4x becomes 8x). --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Thu, 6 Feb 2003, Ian Romanick wrote: 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. ok. I'll try again and see if I'm still getting scissor problems. 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. amask here is the mask for the alpha channel in the framebuffer. The reason I brought this up is that I think glean will ignore differences in the alpha component and skip cases using destination alpha read from the framebuffer if the visual reports 0 alpha bits, and I thought this might be the cause of some of the failures. I guess my question is, should the alpha bits, alpha mask, buffer size, and visual depth reflect the framebuffer bits-per-pixel, or the presence of a destination alpha that's actually written to by the card when rendering and readable by the span functions (Radeon span functions currently read the alpha from the framebuffer, Rage128/mach64 always return 255). Mach64/R128 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 Radeon/R200 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 ff00 24 16 16 16 16 24 Shouldn't this be one of the following? 8 8 8 0 32 16 16 16 0 24 8 8 8 8 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 amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. tdfx r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel) 8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel) 8 8 8 0 32 16 16 16 0 24 8 8 8 8 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 -- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Ian Romanick wrote: Leif Delgass wrote: On Wed, 5 Feb 2003, Ian Romanick wrote: [...] 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. The mask values indicate which bits in the pixel (word) correspond to each color channel. The buffer size is the sum of the red, green, blue, and alpha bits. Mach64/R128 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 AFAIK, Mach64 doesn't support destination alpha. This looks correct. Radeon/R200 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 ff00 24 16 16 16 16 24 bufferSize should be set to 32 in radeon_dri.c Shouldn't this be one of the following? 8 8 8 0 32 16 16 16 0 24 8 8 8 8 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 amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. 8 8 8 8 32 16 16 16 16 24 GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. tdfx r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel) 8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel) 8 8 8 0 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 In hw/drivers/tdfx/tdfx_dri.c bufferSize should be set to 32. I'll check in corrections for these shortly. Thanks! -Brian --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Thu, 6 Feb 2003, Ian Romanick wrote: I went ahead and committed my texmem changes as well as combine3 for radeon and r200 (including the change to the zero/one table). I can't test the r200 version, but it looks almost identical to R100. Cool. I can't think of any reason why those changes couldn't also go into the trunk. Done. -- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Leif Delgass wrote: On Thu, 6 Feb 2003, Brian Paul wrote: The mask values indicate which bits in the pixel (word) correspond to each color channel. The buffer size is the sum of the red, green, blue, and alpha bits. Mach64/R128 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 AFAIK, Mach64 doesn't support destination alpha. This looks correct. Radeon/R200 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 ff00 24 16 16 16 16 24 bufferSize should be set to 32 in radeon_dri.c Shouldn't this be one of the following? 8 8 8 0 32 16 16 16 0 24 8 8 8 8 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 amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. In the argb READ_RGBA in mgaspan.c, alpha is always returned as 255. One or the other of these is wrong. Hmmm, I don't remember if the g200/400 supports dest alpha. The span functions would seem to indicate no. 8 8 8 8 32 16 16 16 16 24 GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. Shouldn't the buffer size be 24 here? Ooops, yes. tdfx r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel) 8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel) 8 8 8 0 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 In hw/drivers/tdfx/tdfx_dri.c bufferSize should be set to 32. I'll check in corrections for these shortly. Thanks! Sure. Could you also check these in on the mesa-4-0-4-branch? Looks like Ian did. -Brian --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Brian Paul wrote: Leif Delgass wrote: On Thu, 6 Feb 2003, Brian Paul wrote: The mask values indicate which bits in the pixel (word) correspond to each color channel. The buffer size is the sum of the red, green, blue, and alpha bits. Mach64/R128 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 AFAIK, Mach64 doesn't support destination alpha. This looks correct. Radeon/R200 r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 ff00 24 16 16 16 16 24 bufferSize should be set to 32 in radeon_dri.c Shouldn't this be one of the following? 8 8 8 0 32 16 16 16 0 24 8 8 8 8 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 amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. In the argb READ_RGBA in mgaspan.c, alpha is always returned as 255. One or the other of these is wrong. Hmmm, I don't remember if the g200/400 supports dest alpha. The span functions would seem to indicate no. I've changed the mga_dri.c to report 0 for alpha bits, and 24 as the buffer size. 8 8 8 8 32 16 16 16 16 24 GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. Shouldn't the buffer size be 24 here? Ooops, yes. Fixed. tdfx r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel) 8 8 8 8 ff00 16 16 16 16 16 32 (pScrn-bitsPerPixel) 8 8 8 0 32 16 16 16 0 24 8 8 8 8 32 16 16 16 16 24 In hw/drivers/tdfx/tdfx_dri.c bufferSize should be set to 32. I'll check in corrections for these shortly. Thanks! Sure. Could you also check these in on the mesa-4-0-4-branch? Looks like Ian did. Err, he updated the texmem branch. I've updated the mesa-4-0-4 branch so it matches the trunk. Perhaps Ian can update the texmem branch again with the mga and glint changes. I don't have a copy of that branch checked out. -Brian --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Brian Paul wrote: Err, he updated the texmem branch. I've updated the mesa-4-0-4 branch so it matches the trunk. Perhaps Ian can update the texmem branch again with the mga and glint changes. I don't have a copy of that branch checked out. Done. --- 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
RE: [Dri-devel] R100 GL_ATI_texture_env_combine3
first let me separate the framebuffer data from GL data by four more spaces. MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. In the argb READ_RGBA in mgaspan.c, alpha is always returned as 255. One or the other of these is wrong. Hmmm, I don't remember if the g200/400 supports dest alpha. The span functions would seem to indicate no. I've changed the mga_dri.c to report 0 for alpha bits, and 24 as the buffer size. Then result should be: MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 it seems that no one never ever tried that alpha bits or used the bsz value. GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. Shouldn't the buffer size be 24 here? Ooops, yes. Fixed. Assumed result: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) Hey and why does 5+5+5+5 = 20, but sum up to 24 in your sheme? i mean the alpha bits would be only 1 bit (my prefrered thing, matches Xvis) or the bsz is truely 24 for the first line. (dont like that) here my prefered fix: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 1 8000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) sorry i dont have that hardware handy or any specs nearby. -Alex. --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Alexander Stohr wrote: first let me separate the framebuffer data from GL data by four more spaces. MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. In the argb READ_RGBA in mgaspan.c, alpha is always returned as 255. One or the other of these is wrong. Hmmm, I don't remember if the g200/400 supports dest alpha. The span functions would seem to indicate no. I've changed the mga_dri.c to report 0 for alpha bits, and 24 as the buffer size. Then result should be: MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 Right. it seems that no one never ever tried that alpha bits or used the bsz value. Most likely, the later. I've never seen any application care about GLX_BUFFER_SIZE. GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. Shouldn't the buffer size be 24 here? Ooops, yes. Fixed. Assumed result: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) Hey and why does 5+5+5+5 = 20, but sum up to 24 in your sheme? Huh??? It looks like 5+5+5+5 was mistakenly adding to 16, not 24 (or 20). It's not my scheme - I didn't write that code! i mean the alpha bits would be only 1 bit (my prefrered thing, matches Xvis) or the bsz is truely 24 for the first line. (dont like that) here my prefered fix: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 1 8000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) sorry i dont have that hardware handy or any specs nearby. Me neither. I don't know what it's supposed to really be. The span fallback functions treat the first mode as a 565 RGB visual. I think Alan H. did some work on this driver a while back. Do you remember anything about this? -Brian --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Thu, Feb 06, 2003 at 04:39:11PM -0700, Brian Paul wrote: Alexander Stohr wrote: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) Hey and why does 5+5+5+5 = 20, but sum up to 24 in your sheme? Huh??? It looks like 5+5+5+5 was mistakenly adding to 16, not 24 (or 20). It's not my scheme - I didn't write that code! I don't remember writing that either, but I've just committed the fixes. Alan. --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
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
};
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.
---
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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
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 ;) ). Where do I find at least a short explanation on the effect this patch should show to me (to the user) ? The only impression I have after a short test is decreased frame rate in FlightGear under certain conditions. I'm pretty shure this is not your primary intention with this patch ;-) So obviously this patch is considered to improve something else that FlightGear das not benefit from, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
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 amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 24 16 16 16 0 24
Radeon/R200
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 ff00 24 16 16 16 16 24
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
GLINT
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth)
8 8 8 0 32 16 16 16 0 24 (pScrn-depth)
tdfx
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 16 16 16 16 0 24 (pScrn-bitsPerPixel)
8 8 8 8 ff00 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Martin Spott 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 ;) ). Where do I find at least a short explanation on the effect this patch should show to me (to the user) ? The only impression I have after a short test is decreased frame rate in FlightGear under certain conditions. I'm pretty shure this is not your primary intention with this patch ;-) So obviously this patch is considered to improve something else that FlightGear das not benefit from, Which patch do you mean? Do you mean the patch in Leif's e-mail in this thread or the patch in his e-mail with the [PATCH] texmem-0-0-1 branch subject? Or do you mean something else? :) The patch in this thread should not have any impact on performance. It adds a couple of extra combine modes to the list in ARB_texture_env_combine. The patch in the other thread fixes some bugs that can lead to texture corruption when there are multiple active GL contexts. It's possible that could effect performance, but only in the case of multiple active contexts. That would be easy enough to verify with oprofile. Just take a profile with and without the patch. In order to get profile data on the GL driver, do this: oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so Or whatever your driver is. If more time shows up in any of the functions in lib/GL/mesa/src/drv/common/texmem.c or in the texture upload functions in the driver, then you can blame the patch. :) Either way, it would be interesting to see profiles of common apps. --- 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
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
That would be easy enough to verify with oprofile. Just take a profile with and without the patch. In order to get profile data on the GL driver, do this: oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so Thanks for the explanation. If there's anything else I can do to support your effort instead of pointing to FlightGear related trouble every day I'd be glad to hear - I mean, except writing C code, you don't really want to look at my C skills Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
