[Mesa-dev] [PATCH] gallivm: add a horrible hack for stencil texturing with border

Jose Fonseca jfonseca at vmware.com
Mon Dec 21 11:59:35 PST 2015


On 16/12/15 16:18, Roland Scheidegger wrote:
> Am 16.12.2015 um 12:52 schrieb Marek Olšák:
>> This is not well defined in gallium, but r600g and radeonsi use these
>> default swizzles for depth and stencil surfaces and it's probably the
>> only reasonable thing to do:
>>
>> Format = Default swizzle
>> Z24X8 = XXXX (Z)
>> Z24S8 = XXXX (Z)
>> X24S8 = YYYY (S)
>> X8Z24 = YYYY (Z)
>> S8Z24 = YYYY (Z)
>> S8X24 = XXXX (S)
>> Z32_S8X24 = XXXX (Z)
>> X32_S8X24 = YYYY (S)
>
> I suppose you also get the right border color without any hacks?
> I guess in theory these formats could use replicated swizzles in the
> u_format description, instead of only the one-channel ones. That would
> give the right result without doing anything special in drivers
> following those bits. However, it can't be done consistently, since it
> obviously won't work for depthstencil formats (which are still valid in
> gallium for texturing, albeit it would be possible to change that and
> enforce D24X8 views to be used instead).
> And this wouldn't do anything for the fact you can't get the right bits
> for stencil border color automatically that way (which is more
> problematic since no matter the format swizzling or sampler state
> swizzling it will always be wrong). (FWIW d3d10 decidedly uses the "G"
> channel for stencil, and you'd supposedly get R = B = 0, G = S, A = 1 -
> albeit there's no stencil-only S8 format, and since it's not possible to
> use integer textures with ordinary sampling just ld, there's no sampler,
> no border, no problem there...)

We should do something sensible in u_format.  State trackers should set 
texture_swizzle to get behavior to match whatever the API happens to 
prescribe.

Jose

>
> Roland
>
>
>> Marek
>>
>> On Wed, Dec 16, 2015 at 5:37 AM,  <sroland at vmware.com> wrote:
>>> From: Roland Scheidegger <sroland at vmware.com>
>>>
>>> mesa/st doesn't give us a useful swizzle when stencil texturing. Moreover,
>>> it's not even obvious what the swizzle actually should be - the channel which
>>> is used for the fetch (Y) is not the same as the one which must be used for
>>> the border component (X), which is due to a mismatch between GL and gallium
>>> interface. (On top of that, I have no idea what GL expects in YZW channels in
>>> the end.)
>>> So add some special case for stencil texturing with border, to fetch the right
>>> border component. Though it seems there has to be some better solution...
>>> This fixes piglit texwrap GL_ARB_texture_stencil8 bordercolor (only the fixed
>>> version).
>>> ---
>>>   src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 28 +++++++++++++++++++++--
>>>   1 file changed, 26 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>>> index e21933f..efba5a8 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
>>> @@ -187,9 +187,33 @@ lp_build_sample_texel_soa(struct lp_build_sample_context *bld,
>>>         border_type.length = 4;
>>>         /*
>>>          * Only replace channels which are actually present. The others should
>>> -       * get optimized away eventually by sampler_view swizzle anyway but it's
>>> -       * easier too.
>>> +       * get optimized away eventually by sampler_view swizzle in most cases...
>>> +       * If not, for "ordinary" color textures, fetch will have placed the
>>> +       * correct default values there, since missing channels must use default
>>> +       * values regardless of border.
>>> +       * We do, however, some horrendous hack for stencil textures. We won't
>>> +       * get a useful swizzle, and furthermore the channel to fetch (Y) doesn't
>>> +       * match the channel for the border color (X).
>>>          */
>>> +      if (util_format_has_stencil(format_desc) &&
>>> +            !util_format_has_depth(format_desc)) {
>>> +         LLVMValueRef zero = lp_build_const_int32(bld->gallivm, 0);
>>> +         LLVMValueRef border_col;
>>> +         border_col = lp_build_extract_broadcast(bld->gallivm,
>>> +                                                 border_type,
>>> +                                                 bld->texel_type,
>>> +                                                 bld->border_color_clamped,
>>> +                                                 zero);
>>> +         /*
>>> +          * Replace first 3 chans (match what fetch did).
>>> +          */
>>> +         for (chan = 0; chan < 3; chan++) {
>>> +            texel_out[chan] = lp_build_select(&bld->texel_bld, use_border,
>>> +                                              border_col, texel_out[chan]);
>>> +         }
>>> +         return;
>>> +      }
>>> +
>>>         for (chan = 0; chan < 4; chan++) {
>>>            unsigned chan_s;
>>>            /* reverse-map channel... */
>>> --
>>> 2.1.4
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WHbHruMaOHWeTtkwxpGQBCoIG6ugN05KyIk4b9wV73U&s=qJfldc7BscCw-W68EeNcM89Y7_zRKhmnSEP1T-D_X-k&e=
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



More information about the mesa-dev mailing list