[Mesa-dev] Mesa (master): mesa/formats: Add layout and swizzle information

[Roland Scheidegger]

Am 08.08.2014 09:46, schrieb Kenneth Graunke:
> On Thursday, August 07, 2014 10:41:36 PM Roland Scheidegger wrote:
>> Am 07.08.2014 20:25, schrieb Jason Ekstrand:
>>> Michel,
>>>
>>> On Thu, Aug 7, 2014 at 12:04 AM, Michel Dänzer <michel at daenzer.net
>>> <mailto:michel at daenzer.net>> wrote:
>>>
>>>     On 07.08.2014 02:02, Jason Ekstrand wrote:
>>>     > Michael,
>>>
>>>     Close, but no cigar. :)
>>>
>>>
>>> I'm sorry about that.  I must have read too quickly. :-/
>>>  
>>>
>>>
>>>     > Could you please point me at the failing tests.
>>>
>>>     spec/!OpenGL 1.1/depthstencil-default_fb-drawpixels-FLOAT-and-USHORT
>>>     spec/!OpenGL 1.1/draw-pixels
>>>     spec/!OpenGL 1.1/stencil-drawpixels
>>>     spec/!OpenGL 1.4/copy-pixels
>>>     spec/ARB_depth_buffer_float/fbo-depthstencil-GL_DEPTH32F_STENCIL8-drawpixels-FLOAT-and-USHORT
>>>     spec/ARB_depth_buffer_float/fbo-stencil-GL_DEPTH32F_STENCIL8-drawpixels
>>>     spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
>>>     spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
>>>     spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX14-drawpixels
>>>     spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
>>>     spec/EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-drawpixels-FLOAT-and-USHORT
>>>     spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-drawpixels
>>>
>>>     (The total number of regressions is around 20 because some of these are
>>>     run for several numbers of samples)
>>>
>>>
>>>     > I don't have a radeon, but I can run with llvmpipe or dri swrast and
>>>     > try to find the bug that way.
>>>
>>>     At least the draw-pixels test indeed regressed with llvmpipe as well.
>>>
>>>
>>> The draw pixels regression on llvmpipe is different.  The changes I made
>>> to texture upload included a subtle change in the way we handle signed
>>> input data.  In older GL versions there were two formulas, one which
>>> mapped [-128, 127] to [-1, 1] and one which mapped [-127, 127] to [-1,
>>> 1].  The former formula was used when uploading a non-snorm texture from
>>> signed integer data or when doing operations such as DrawPixels and
>>> ReadPixels.  In GL 4.3, this first formula is going away and we will
>>> only have the later formula.  (The later formula has the advantage of
>>> mapping 0 to 0.)  If we think it's needed, I can add code to the
>>> swizzle_and_convert function to be able to handle the legacy formula in
>>> those cases where older GL versions say that it's needed.
>>>  
>>
>> Yeah the two different formulas in older GL versions are quite a pity.
>> I'm not sure if we really need to honor the old formula, but I guess if
>> binary drivers do we might be required to as well. The gallium util code
>> though never did. Maybe should just make the tests more lenient...
>>
>> Roland
> 
> I have a pretty strong preference to ditch the old formula entirely:
> 
> 1. OpenGL will silently promote you to a 4.2 context if you ask for less than that, because it's deemed "backwards compatible" (even though it strictly isn't, due to things like this).
> 
> Implementing both sets of rules means that GL4-class hardware will use one formula, and GL3-class hardware will use the other...on the same driver.  That seems weird.
Yes that sounds a bit odd. Still could use the old formula on compatibility
context but I guess if you can get the new formula automatically it is
possibly not
really needed.

> 2. OpenGL ES 3.x strictly uses the new formula.
> 
> 3. The new formula matches DirectX, so it's probably what ported applications
> (or a virtualization environment) would expect.
> 
> 4. Intel hardware cannot honor the older GL formula (we'd have to do the conversion manually, which seems like a waste).
> 
> My preference would be to make tests accept either formula.
> 
Sounds ok to me but I don't really have a strong opinion on that. It
would certainly simplify things.

Roland