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 <mic...@daenzer.net >>> <mailto:mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
