Well, the interesting thing is that when running X at depth 24 w/ 32 fbbpp
on Radeon, glxinfo still shows buffer size as 24 after the patch. Is this
because it's being intersected with the X visual depth of 24? Afaik,
there's no such thing as a depth 32 in the Xserver ("-depth 32" doesn't
work as an argument to the server).
According to the glx spec GLX_BUFFER_SIZE, as you say, should be the sum
of the four channel sizes (GLX_RED_SIZE, GLX_GREEN_SIZE, etc.). It also
says that "this value may be larger than the depth value reported in the
core X11 visual since it may include alpha planes that may not be reported
by X11." So it looks like a bug in GlxSetVisualConfigs. I haven't been
able to track down where the actual code for that is yet, though.
--Leif
On Thu, 6 Feb 2003, 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".
>
>
> >>>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
>
--
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
