Revert "renderer: swizzle sampler border color channel if we emulate alpha format"

Submitted by Elie Tournier on Aug. 3, 2018, 4:10 p.m.

Details

Message ID 20180803161055.32602-1-tournier.elie@gmail.com
State New
Series "Revert "renderer: swizzle sampler border color channel if we emulate alpha format""
Headers show

Commit Message

Elie Tournier Aug. 3, 2018, 4:10 p.m.
This reverts commit 6a4ef6d8a284d163236d99f30bc5e1480d009544.

Fix a bunch of dEQP-GLES31.functional.texture.border_clamp.* failures when
running on GLES

Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
---
 src/vrend_renderer.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

Patch hide | download patch | download mbox

diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
index ddf7f3a..f3051d6 100644
--- a/src/vrend_renderer.c
+++ b/src/vrend_renderer.c
@@ -4866,17 +4866,8 @@  static void vrend_apply_sampler_state(struct vrend_context *ctx,
       }
    }
 
-   if (memcmp(&tex->state.border_color, &state->border_color, 16) || set_all ||
-       is_emulated_alpha) {
-      if (is_emulated_alpha) {
-         union pipe_color_union border_color;
-         border_color = state->border_color;
-         border_color.ui[0] = border_color.ui[3];
-         border_color.ui[3] = 0;
-         glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, border_color.ui);
-      } else
-         glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, state->border_color.ui);
-   }
+   if (memcmp(&tex->state.border_color, &state->border_color, 16) || set_all)
+      glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, state->border_color.ui);
    tex->state = *state;
 }
 

Comments

Erik Faye-Lund Aug. 3, 2018, 5:35 p.m.
On 03. aug. 2018 18:10, Elie Tournier wrote:
> This reverts commit 6a4ef6d8a284d163236d99f30bc5e1480d009544.
>
> Fix a bunch of dEQP-GLES31.functional.texture.border_clamp.* failures when
> running on GLES
>
> Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
> ---
>   src/vrend_renderer.c | 13 ++-----------
>   1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
> index ddf7f3a..f3051d6 100644
> --- a/src/vrend_renderer.c
> +++ b/src/vrend_renderer.c
> @@ -4866,17 +4866,8 @@ static void vrend_apply_sampler_state(struct vrend_context *ctx,
>         }
>      }
>   
> -   if (memcmp(&tex->state.border_color, &state->border_color, 16) || set_all ||
> -       is_emulated_alpha) {
> -      if (is_emulated_alpha) {
> -         union pipe_color_union border_color;
> -         border_color = state->border_color;
> -         border_color.ui[0] = border_color.ui[3];
> -         border_color.ui[3] = 0;
> -         glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, border_color.ui);
> -      } else
> -         glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, state->border_color.ui);
> -   }
> +   if (memcmp(&tex->state.border_color, &state->border_color, 16) || set_all)
> +      glTexParameterIuiv(target, GL_TEXTURE_BORDER_COLOR, state->border_color.ui);
>      tex->state = *state;
>   }
>   

This seems wrong. If swizzle the texture, we need to swizzle the 
border-color as well...

Have your figured out what's actually going on?
Gert Wollny Aug. 3, 2018, 6:10 p.m.
Am Freitag, den 03.08.2018, 19:35 +0200 schrieb Erik Faye-Lund:
> On 03. aug. 2018 18:10, Elie Tournier wrote:
> > This reverts commit 6a4ef6d8a284d163236d99f30bc5e1480d009544.
> > 
> > Fix a bunch of dEQP-GLES31.functional.texture.border_clamp.*
> > failures when
> > running on GLES
> > 
> > 
> 
> This seems wrong. If swizzle the texture, we need to swizzle the 
> border-color as well...

Border color swizzling seems kind of like a mystic thing, I tried for
two hours to get all related piglits to pass on r600, and there was no
definite answer. It also seems that the spec is not very clear about
this. 

To me it would make sense if the driver would apply the same swizzling
to the border colour like it does to the texels, which would mean that
no manual swizzling should be applied. However, I know that e.g. r600
doesn't do this, although that seems to be more of a question of
everybody who tried has given up (me included). 

best, 
Gert
Erik Faye-Lund Aug. 3, 2018, 6:30 p.m.
On 03. aug. 2018 20:10, Gert Wollny wrote:
> Am Freitag, den 03.08.2018, 19:35 +0200 schrieb Erik Faye-Lund:
>> On 03. aug. 2018 18:10, Elie Tournier wrote:
>>> This reverts commit 6a4ef6d8a284d163236d99f30bc5e1480d009544.
>>>
>>> Fix a bunch of dEQP-GLES31.functional.texture.border_clamp.*
>>> failures when
>>> running on GLES
>>>
>>>
>> This seems wrong. If swizzle the texture, we need to swizzle the
>> border-color as well...
> Border color swizzling seems kind of like a mystic thing, I tried for
> two hours to get all related piglits to pass on r600, and there was no
> definite answer. It also seems that the spec is not very clear about
> this.
>
> To me it would make sense if the driver would apply the same swizzling
> to the border colour like it does to the texels, which would mean that
> no manual swizzling should be applied. However, I know that e.g. r600
> doesn't do this, although that seems to be more of a question of
> everybody who tried has given up (me included).

Sounds like you're encountered PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK.

It really shouldn't be that hard from the API perspective. Colors are 
always specified in RGBA order to OpenGL. If the hardware has extra 
requirements, the driver needs to swizzle this. This is what 
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK is about. This is dealt with at the 
state-tracker level, st_convert_sampler().

Maybe there's some case where the driver doesn't swizzle it as it should?