[Piglit] [PATCH] fbo-blending-snorm: new test for testing snorm blend behavior

[Ilia Mirkin]

On Wed, Nov 22, 2017 at 2:19 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
>> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
>>> sroland at vmware.com writes:
>>>
>>>> From: Roland Scheidegger <sroland at vmware.com>
>>>>
>>>> The existing fbo-blending-formats test is mostly useless for anything but
>>>> unorm formats, since it does not test any values outside [0,1] (neither for
>>>> src, dst, intermeidate calculations, blend result).
>>>> I tried to enhance it but it got too complex, in particular because I really
>>>> want to test snorm, not floats (which aren't really validated much neither),
>>>> because if you actually use int math for them it's difficult to handle and
>>>> llvmpipe had lots of bugs. And it's not even obvious from the GL spec when
>>>> clamping actually happens (in particular, the inverse blend factors will be
>>>> in range [0,2]). snorm blending is sort of semi-supported in GL, the
>>>> presence of EXT_texture_snorm doesn't guarantee it (and nvidia doesn't support
>>>> the extension, presumably because they can't or don't want to deal with the
>>>> legacy alpha/luminance/intensity formats), and while GL 3.1 introduces the
>>>> snorm formats too it isn't guaranteed for rendering neither (for GLES OTOH
>>>> there's a EXT_render_snorm extension), so the format handling of the
>>>> fbo-blending-formats test isn't really sufficient and not easily extensible.
>>>> So, this test will test actual blend behavior with values which will need
>>>> clamping, and where the intermediate and final values will be negative (and,
>>>> for the inverse blend factors, be even larger than one).
>>>> This passes (now) on llvmpipe, and nvidia blob. softpipe is a complete
>>>> failure (if there's clamping it will always clamp to [0,1] for starters),
>>>> and as a matter of fact, softpipe doesn't get the clamping right even with
>>>> unorm neither, since values outside [0,1] won't get clamped in the tile
>>>> cache when there's no clamping, hence they'll enter the blend later when
>>>> blend is enabled unclamped - but there's no test for this (note this is
>>>> only an issue if the fragment color clamp is disabled).
>>>
>>> I thought the ARB_color_buffer_float/render test was trying to cover
>>> this.
>>>
>>
>> You are quite right, I missed this one also covers blend functionality
>> (and also covers snorm formats).
>> It does not however test the really interesting blend combinations,
>> because it only really tests one/zero blend factors. The really
>> interesting ones are those with inverse blend factors.
>> And it looks quite complex to change too (this test actually just draws
>> one rectangle and relies on the clear color for the dst values).
>>
> Oh and FWIW this one also requires EXT_texture_snorm (which at least
> nvidia doesn't support) for snorm format testing.

The (NVIDIA) DX10 series didn't support snorm blending. I think the
DX11 ones do though -- not completely sure.

  -ilia