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

[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.

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.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140808/9b7cf5c1/attachment.sig>