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 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 > > > > ------------------------------------------------------- > 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
