[virglrenderer-devel] [PATCH] Revert "renderer: swizzle sampler border color channel if we emulate alpha format"

[Erik Faye-Lund]

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?