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...)
Roland
> Marek
>
> On Wed, Dec 16, 2015 at 5:37 AM, <srol...@vmware.com> wrote:
>> From: Roland Scheidegger <srol...@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@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
