See Gallium PIPE_FORMATs. They all have consistent names. The translation between Mesa and Gallium formats takes place in st_format.c. I'm inclined to rename all Mesa formats to match the Gallium names.
Marek On Wed, Dec 18, 2013 at 3:50 AM, Mark Mueller <markkmuel...@gmail.com> wrote: > > > > On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmuel...@gmail.com> > wrote: >> >> >> >> >> On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <mar...@gmail.com> wrote: >>> >>> On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller <markkmuel...@gmail.com> >>> wrote: >>> > >>> > >>> > >>> > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák <mar...@gmail.com> wrote: >>> >> >> >> >> [...] >> >>> >>> >> >>> >> > MESA_FORMAT_RGBA1555_REV, >>> >> >>> >> I don't think you can have R with 1 bit. >>> >> >>> >> > >>> >> > /* Blue Green Red Alpha */ >>> >> > MESA_FORMAT_BGRA_INT8, >>> >> > MESA_FORMAT_BGRA_INT8_REV, >>> >> > MESA_FORMAT_BGRA_UINT8, >>> >> > MESA_FORMAT_BGRA_INT16, >>> >> > MESA_FORMAT_BGRA_UINT16, >>> >> > MESA_FORMAT_BGRA_FLOAT16, >>> >> > MESA_FORMAT_BGRA_INT32, >>> >> > MESA_FORMAT_BGRA_UINT32, >>> >> > MESA_FORMAT_BGRA_FLOAT32, >>> >> > MESA_FORMAT_BGRA4444, >>> >> > MESA_FORMAT_BGRA4444_REV, >>> >> > MESA_FORMAT_BGRA5551, >>> >> >>> >> All these look good. >>> >> >>> >> > MESA_FORMAT_BGRA1555_REV, >>> >> >>> >> I don't think you can have B with 1 bit. >> >> >> Doesn't the _REV force A to be the first component, i.e. 1 bit? This >> format is listed as valid in http://www.opengl.org/wiki/Pixel_Transfer - see >> below. >> >>> >>> >> >>> >> > MESA_FORMAT_BGRA1010102, >>> >> >>> >> This one looks good. >>> >> >>> >> > MESA_FORMAT_BGRA2101010_REV, >>> >> >>> >> I don't think you can have B with 2 bits. >> >> >> Same as above. >> >>> >>> >> >>> >> > MESA_FORMAT_BGRA5999_REV, >>> >> >>> >> This one doesn't exist either and cannot be specified by TexImage. >> >> >> You are correct according to the Pixel_Transfer spec, thanks. >> >>> >>> > >>> > >>> > BGRAs and RGBAs were based on this from the spec: >>> > "GL_INVALID_OPERATION is generated if type is one of >>> > GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, >>> > GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, >>> > GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, >>> > GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV, or >>> > GL_UNSIGNED_INT_5_9_9_9_REV, and format is neither GL_RGBA nor >>> > GL_BGRA." >>> >>> Nowhere can I see that B has 1 or 2 bits. Also the occurence of >>> GL_UNSIGNED_INT_5_9_9_9_REV seems to be a spec bug, because it should >>> be GL_RGB (the 5 bits contain a shared exponent). >> >> >> It does appear to be a spec bug. Here is a quote from >> http://www.opengl.org/wiki/Pixel_Transfer which addresses that an other >> issues above: >> >> "OpenGL restricts the possible sizes. They are: >> * 3_3_2 (2_3_3_REV): unsigned bytes. Only used with GL_RGB. >> >> * 5_6_5 (5_6_5_REV): unsigned shorts. Only used with GL_RGB. >> >> * 4_4_4_4 (4_4_4_4_REV): unsigned shorts. >> >> * 5_5_5_1 (1_5_5_5_REV): unsigned shorts. >> >> * 8_8_8_8 (8_8_8_8_REV): unsigned ints. >> >> * 10_10_10_2 (2_10_10_10_REV): unsigned ints. >> >> * 24_8 (no _REV): unsigned ints. Only used with GL_DEPTH_STENCIL. >> >> * 10F_11F_11F_REV (no non-REV): unsigned ints. These represent floats, and >> can only be used with GL_RGB. This should only be used with images that have >> the GL_R11F_G11F_B10F image format. >> >> * 5_9_9_9_REV (no non-REV): unsigned ints. Only used with GL_RGB; the last >> component (the 5. It's REV) does not directly map to a color value. It is a >> shared exponent. Only use this with images that have the GL_RGB9_E5 image >> format." >> >> >> I'm working on V2 of this patch with incorporation of Marek, Brian's, and >> Roland's feedback. I have also made changes as a result of further >> development and testing on the i965 GPU texture upload work. I will be >> posting that shortly. >> >> Thanks Marek. >> > > OK, I think I've realized why this is so difficult. There are some > MESA_FORMAT component orders that are counter to their OGL counterparts in > name, and the same appears true for the bit count numberings. For example > these two cases in _mesa_choose_tex_format: > > case GL_BGRA: > RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB8888); > > vs. > > case GL_RGBA32F_ARB: > RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32); > > > and Mesa defines these: > > MESA_FORMAT_ARGB1555, /* ARRR RRGG GGGB BBBB */ > MESA_FORMAT_ARGB1555_REV, /* GGGB BBBB ARRR RRGG */ > > while in OGL it's this way: > GL_UNSIGNED_SHORT_5_5_5_1 > GL_UNSIGNED_SHORT_1_5_5_5_REV > > I'll modify my additions to better match Mesa's convention and hopefully > that will clear a few things up. Or would it be better to fix this dilemma > once and for all? I've heard Ken suggesting that that be done. It has been > causing me so much grief that I'd _love_ to eliminate the problem but would > rather move on if I can't get buy in. > > Cheers, > Mark > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
