Re: [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  
> wrote:
>> Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
>>> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
 srol...@vmware.com writes:

> From: Roland Scheidegger 
>
> 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

___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

Re: [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  wrote:
> Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
>> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
>>> srol...@vmware.com writes:
>>>
 From: Roland Scheidegger 

 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
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

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

[Roland Scheidegger]

Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
>> srol...@vmware.com writes:
>>
>>> From: Roland Scheidegger 
>>>
>>> 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.

Roland

___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

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

[Roland Scheidegger]

Am 22.11.2017 um 19:45 schrieb Eric Anholt:
> srol...@vmware.com writes:
> 
>> From: Roland Scheidegger 
>>
>> 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).

Roland
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

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

[Eric Anholt]

srol...@vmware.com writes:

> From: Roland Scheidegger 
>
> 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.


signature.asc
Description: PGP signature
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

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

[Jose Fonseca]

On 22/11/17 03:19, srol...@vmware.com wrote:

From: Roland Scheidegger 

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).
---
  tests/all.py   |   1 +
  tests/fbo/CMakeLists.gl.txt|   1 +
  tests/fbo/fbo-blending-snorm.c | 358 +
  3 files changed, 360 insertions(+)
  create mode 100644 tests/fbo/fbo-blending-snorm.c

diff --git a/tests/all.py b/tests/all.py
index 70f8efd..472024a 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -3180,6 +3180,7 @@ with profile.test_list.group_manager(
  g(['fbo-alphatest-nocolor'])
  g(['fbo-alphatest-nocolor-ff'])
  g(['fbo-blending-formats'])
+g(['fbo-blending-snorm'])
  g(['fbo-bind-renderbuffer'])
  g(['fbo-clearmipmap'])
  g(['fbo-clear-formats'])
diff --git a/tests/fbo/CMakeLists.gl.txt b/tests/fbo/CMakeLists.gl.txt
index 2db8bf7..d594c24 100644
--- a/tests/fbo/CMakeLists.gl.txt
+++ b/tests/fbo/CMakeLists.gl.txt
@@ -29,6 +29,7 @@ piglit_add_executable (fbo-blit fbo-blit.c)
  piglit_add_executable (fbo-blit-d24s8 fbo-blit-d24s8.c)
  piglit_add_executable (fbo-blit-stretch fbo-blit-stretch.cpp)
  piglit_add_executable (fbo-blending-formats fbo-blending-formats.c)
+piglit_add_executable (fbo-blending-snorm fbo-blending-snorm.c)
  piglit_add_executable (fbo-colormask-formats fbo-colormask-formats.c)
  piglit_add_executable (fbo-copypix fbo-copypix.c)
  piglit_add_executable (fbo-readdrawpix fbo-readdrawpix.c)
diff --git a/tests/fbo/fbo-blending-snorm.c b/tests/fbo/fbo-blending-snorm.c
new file mode 100644
index 000..a7c2bba
--- /dev/null
+++ b/tests/fbo/fbo-blending-snorm.c
@@ -0,0 +1,358 @@
+/*


We should update copyright here.

Otherwise looks great to me.  Thanks.

Reviewed-by: Jose Fonseca 

Jose


+ * Copyright © 2010 Intel Corporation
+ * Copyright © 2010 Marek Olšák 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Eric Anholt 
+ *Marek Olšák 
+ *Roland Scheidegger 
+ *
+ */
+
+#include "piglit-util-gl.h"
+
+PIGLIT_GL_TEST_CONFIG_BEGIN
+
+