On 12/17/2013 07: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
<https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/wiki/Pixel_Transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=YqhEgUkmBDO%2B90crzawcdIBPS5y1FiM0BS%2FljcrWPrI%3D%0A&s=d19ac6c07923331addd8b21f7efab34b5ad7bc2560fbd2d51c9b392a4a1abb20>
- 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
<https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/wiki/Pixel_Transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=YqhEgUkmBDO%2B90crzawcdIBPS5y1FiM0BS%2FljcrWPrI%3D%0A&s=d19ac6c07923331addd8b21f7efab34b5ad7bc2560fbd2d51c9b392a4a1abb20>
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.
Just FYI: there's no intention that MESA_FORMATs match any OpenGL
format/type/internalFormat. MESA_FORMATs are intended to match what the
hardware wants. Ideally, we hit TexImage/etc paths where the
user-specified format/type/internalFormat exactly matches a MESA_FORMAT
to avoid conversion/swizzling.
Back in the early days of OpenGL, most OpenGL formats directly
corresponded to SGI hardware formats. Over time, as PC GPUs arrived,
newer formats (like GL_BGR[A]) were added.
Throw in big vs. little endian issues and it's kind of a mess.
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);
Part of the issue here is do you treat the pixel/texel as a packed value
or as an array of values? Most of the 4-byte rgba formats expect texels
to be treated as packed 4-byte words while the 16-byte floating point
format is treated as an array of four floats. That leads to confusion too.
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
Again, the apparent inconsistency comes from old OpenGL (SGI)
conventions vs. PC hardware conventions.
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.
I guess I'm still not clear on what the new MESA_FORMATs are supposed to
represent? API/user-space data or hardware/GPU data? Or both?
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
