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

[Roland Scheidegger]

Am 22.11.2017 um 20:46 schrieb 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.

Yes, they will (it's a required dx11 feature). They just don't bother
with the legacy formats (alpha/intensity/luminance), even for texturing
- if they can't or they just don't want to bother, I don't know (trying
to create a a8_snorm texture will indeed generate a gl error). So you
can use snorm formats just fine (as it's a gl 3.1 feature for
texturing), even for rendering/blending (which isn't guaranteed by gl in
any version), just not the legacy ones, since EXT_texture_snorm isn't
supported.

Roland