On 12/17/2013 06:50 PM, Mark Mueller wrote: > > > > On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller <markkmuel...@gmail.com > <mailto:markkmuel...@gmail.com>> wrote: > > > > > On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák <mar...@gmail.com > <mailto:mar...@gmail.com>> wrote: > > On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller > <markkmuel...@gmail.com <mailto:markkmuel...@gmail.com>> wrote: > > > > > > > > On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák <mar...@gmail.com > <mailto: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
Mapping from GL to MESA_FORMAT to hardware formats has always confused me - there does seem to be some inconsistency between MESA_FORMATs. For example, a bunch of the integer formats seem to use a different convention than the unorm formats. It would be great to: 1. Document the prevailing convention for MESA_FORMAT. 2. Document how it compares to GL and DX. 3. Fix formats to follow the convention, either one format at a time, or a related group of formats that have the same problem. It may be worth sending out any proposed renames before actually coding it up, so people can discuss the convention. --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
