Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
On Sat, Feb 8, 2014 at 10:22 PM, Christoph Bumiller wrote: > On 07.02.2014 23:25, Dave Airlie wrote: Doh, yes because GL has ARB_texture_gather then has stuff hidden away in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should do. So I've reposted with the component selection in src1 now. >>> Hmm seems a bit excessive to use an extra reg for that (gather4 but only >>> in d3d11 form uses a src_sel on the sampler reg, but that might not work). >>> I realize this is actually more messy than I thought, since the initial >>> ARB_texture_gather had the ability to query if multi-channel formats are >>> allowed, but had no way to select the channel (somewhat relying on >>> ARB_texture_swizzle to do it, though of course you can't issue multiple >>> gathers with the same texture to get different channels that way). >>> But glsl 4.00 version could select the channel. >>> Is the ARB_texture_gather version actually all that useful or could you >>> merge the two caps? That is, if you have the ability to fetch from >>> multi-channel textures, assume you can also select the channel. The sm4 >>> version of gather4 also has the single-channel format restriction - I >>> guess though some hw really can do 4 channels without channel selection. >> Yeah I think I'll rethink this stuff, it looks like two caps, one for >> MAX_COMPONENTS for ARB_texture_gather4, and just one cap for >> TEXTURE_GATHER_SM5 support which would denote support for all the >> ARB_GPU_shader5 bits. >> >>> Other than that, what about shadow samplers? Gather4 of course can't do >>> it (because the d3d10-style opcodes have different opcodes for shadow >>> comparisons), but the GL style opcodes are usually the same if shadow >>> samplers or not are used. Maybe you don't want to handle that right now, >>> just saying that if you'd want to use the same opcode you'd be missing a >>> component in case of texture cube arrays... Since this can't be used for >>> fixed function though I'd guess nothing would stop you from using a >>> different opcode for shadow samplers. >> >> I've gotten shadow samplers to work with the current opcodes, though I >> have to see about cube arrays if we have the running out of space to >> put everything. >> >> Also the GPU_shader5 spec has a few more oddities, so you have >> textureGatherOffset which can take a non-constant set of offset values >> to apply to all 4 texels, then you have textureGatherOffsets which >> only takes constants again, but 4 of them, one per texel. Looking at >> radeon hw it appears fglrx decomposes textureGatherOffsets into >> multiple gather instructions at the hw level but using the >> non-constant hw support to do this. So I'm not sure if the gallium >> interface should just support non-constant for all offsets and just >> restrict the GL. > > Fwiw Fermi+ support 4 different non-constant offsets, since they're > passed in a register anyway. > The problem with textureGatherOffsets is that it takes 4 constant offset pairs, but it only samples for i0,j0 for each, unlike textureGather and textureGatherOffset which take a single offset and sample from the i0, j0->i1, j1. So I'd really need to know if any hw can do this effectively, if so we'd have to bake the gallium TG4 instruction as being a) no SM5 available - no component, no shadow, no non-consts, just takes a single constant texture offset. b) SM5 CAP available, shadow, component, single non-constant offset gets i0,j0->i1,j1 behaviour, and multiple non-constant offsets get i0,j0 behaviour. We could in theory lower the textureGatherOffsets into 4 textureGatherOffset just sampling the i0,j0 of each and putting it into a different channel of the dst and this is what AMD hw does anyways, so I've done it in r600g. But maybe we could/should lower this at a higher level, though to be honest I kinda suck at writing lowering passes for GLSL or TGSI. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
On 07.02.2014 23:25, Dave Airlie wrote: >>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away >>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should >>> do. >>> >>> So I've reposted with the component selection in src1 now. >> Hmm seems a bit excessive to use an extra reg for that (gather4 but only >> in d3d11 form uses a src_sel on the sampler reg, but that might not work). >> I realize this is actually more messy than I thought, since the initial >> ARB_texture_gather had the ability to query if multi-channel formats are >> allowed, but had no way to select the channel (somewhat relying on >> ARB_texture_swizzle to do it, though of course you can't issue multiple >> gathers with the same texture to get different channels that way). >> But glsl 4.00 version could select the channel. >> Is the ARB_texture_gather version actually all that useful or could you >> merge the two caps? That is, if you have the ability to fetch from >> multi-channel textures, assume you can also select the channel. The sm4 >> version of gather4 also has the single-channel format restriction - I >> guess though some hw really can do 4 channels without channel selection. > Yeah I think I'll rethink this stuff, it looks like two caps, one for > MAX_COMPONENTS for ARB_texture_gather4, and just one cap for > TEXTURE_GATHER_SM5 support which would denote support for all the > ARB_GPU_shader5 bits. > >> Other than that, what about shadow samplers? Gather4 of course can't do >> it (because the d3d10-style opcodes have different opcodes for shadow >> comparisons), but the GL style opcodes are usually the same if shadow >> samplers or not are used. Maybe you don't want to handle that right now, >> just saying that if you'd want to use the same opcode you'd be missing a >> component in case of texture cube arrays... Since this can't be used for >> fixed function though I'd guess nothing would stop you from using a >> different opcode for shadow samplers. > > I've gotten shadow samplers to work with the current opcodes, though I > have to see about cube arrays if we have the running out of space to > put everything. > > Also the GPU_shader5 spec has a few more oddities, so you have > textureGatherOffset which can take a non-constant set of offset values > to apply to all 4 texels, then you have textureGatherOffsets which > only takes constants again, but 4 of them, one per texel. Looking at > radeon hw it appears fglrx decomposes textureGatherOffsets into > multiple gather instructions at the hw level but using the > non-constant hw support to do this. So I'm not sure if the gallium > interface should just support non-constant for all offsets and just > restrict the GL. Fwiw Fermi+ support 4 different non-constant offsets, since they're passed in a register anyway. > I've reworked the state tracker code already, > > http://cgit.freedesktop.org/~airlied/mesa/commit/?h=r600g-texture-gather&id=444bc1c8118d51600a58af8a84088e94d0800b22 > > but I suspect I've a bit further down the rabbit hole to go. > > Dave. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
Am 07.02.2014 23:25, schrieb Dave Airlie: >>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away >>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should >>> do. >>> >>> So I've reposted with the component selection in src1 now. >> >> Hmm seems a bit excessive to use an extra reg for that (gather4 but only >> in d3d11 form uses a src_sel on the sampler reg, but that might not work). >> I realize this is actually more messy than I thought, since the initial >> ARB_texture_gather had the ability to query if multi-channel formats are >> allowed, but had no way to select the channel (somewhat relying on >> ARB_texture_swizzle to do it, though of course you can't issue multiple >> gathers with the same texture to get different channels that way). >> But glsl 4.00 version could select the channel. >> Is the ARB_texture_gather version actually all that useful or could you >> merge the two caps? That is, if you have the ability to fetch from >> multi-channel textures, assume you can also select the channel. The sm4 >> version of gather4 also has the single-channel format restriction - I >> guess though some hw really can do 4 channels without channel selection. > > Yeah I think I'll rethink this stuff, it looks like two caps, one for > MAX_COMPONENTS for ARB_texture_gather4, and just one cap for > TEXTURE_GATHER_SM5 support which would denote support for all the > ARB_GPU_shader5 bits. > >> Other than that, what about shadow samplers? Gather4 of course can't do >> it (because the d3d10-style opcodes have different opcodes for shadow >> comparisons), but the GL style opcodes are usually the same if shadow >> samplers or not are used. Maybe you don't want to handle that right now, >> just saying that if you'd want to use the same opcode you'd be missing a >> component in case of texture cube arrays... Since this can't be used for >> fixed function though I'd guess nothing would stop you from using a >> different opcode for shadow samplers. > > > I've gotten shadow samplers to work with the current opcodes, though I > have to see about cube arrays if we have the running out of space to > put everything. > > Also the GPU_shader5 spec has a few more oddities, so you have > textureGatherOffset which can take a non-constant set of offset values > to apply to all 4 texels, then you have textureGatherOffsets which > only takes constants again, but 4 of them, one per texel. Looking at > radeon hw it appears fglrx decomposes textureGatherOffsets into > multiple gather instructions at the hw level but using the > non-constant hw support to do this. So I'm not sure if the gallium > interface should just support non-constant for all offsets and just > restrict the GL. > > I've reworked the state tracker code already, > > https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/~airlied/mesa/commit/?h%3Dr600g-texture-gather%26id%3D444bc1c8118d51600a58af8a84088e94d0800b22&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=i2Hco%2Fvjh172WfH7eGwBq60zrN3fohKlxGyQpozcOls%3D%0A&s=2556e11e95af04d43f205d2107f51fa1d1d6d325c2cac1b5205c37ccd6605e78 > > but I suspect I've a bit further down the rabbit hole to go. > > Dave > Hmm yes it's fairly interesting there's so many different possiblities. It looks like the non-constant offsets were borrowed from d3d11, but it looks like 4 different constant offsets is a GL exclusive feature. (Though if you have to issue that as 4 individual gathers, there's not really that much left of "gather"...). Interestingly, if I see that right from the docs some hw (radeonsi) could actually support doing gathers with ordinary mipmap sampling rather than just use mip 0 :-). In any case, at least for the cap bits those could be changed rather easily even your original proposal would be ok by me and more cap bits could be added later (or some replaced). Instructions though are a bit harder to change, though I'm not sure if you'd really want one which can encode everything - maybe the non-constant offset one should have a separate encoding, might get messy otherwise. I dunno though whatever works... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
>>> >> Doh, yes because GL has ARB_texture_gather then has stuff hidden away >> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should >> do. >> >> So I've reposted with the component selection in src1 now. > > Hmm seems a bit excessive to use an extra reg for that (gather4 but only > in d3d11 form uses a src_sel on the sampler reg, but that might not work). > I realize this is actually more messy than I thought, since the initial > ARB_texture_gather had the ability to query if multi-channel formats are > allowed, but had no way to select the channel (somewhat relying on > ARB_texture_swizzle to do it, though of course you can't issue multiple > gathers with the same texture to get different channels that way). > But glsl 4.00 version could select the channel. > Is the ARB_texture_gather version actually all that useful or could you > merge the two caps? That is, if you have the ability to fetch from > multi-channel textures, assume you can also select the channel. The sm4 > version of gather4 also has the single-channel format restriction - I > guess though some hw really can do 4 channels without channel selection. Yeah I think I'll rethink this stuff, it looks like two caps, one for MAX_COMPONENTS for ARB_texture_gather4, and just one cap for TEXTURE_GATHER_SM5 support which would denote support for all the ARB_GPU_shader5 bits. > Other than that, what about shadow samplers? Gather4 of course can't do > it (because the d3d10-style opcodes have different opcodes for shadow > comparisons), but the GL style opcodes are usually the same if shadow > samplers or not are used. Maybe you don't want to handle that right now, > just saying that if you'd want to use the same opcode you'd be missing a > component in case of texture cube arrays... Since this can't be used for > fixed function though I'd guess nothing would stop you from using a > different opcode for shadow samplers. I've gotten shadow samplers to work with the current opcodes, though I have to see about cube arrays if we have the running out of space to put everything. Also the GPU_shader5 spec has a few more oddities, so you have textureGatherOffset which can take a non-constant set of offset values to apply to all 4 texels, then you have textureGatherOffsets which only takes constants again, but 4 of them, one per texel. Looking at radeon hw it appears fglrx decomposes textureGatherOffsets into multiple gather instructions at the hw level but using the non-constant hw support to do this. So I'm not sure if the gallium interface should just support non-constant for all offsets and just restrict the GL. I've reworked the state tracker code already, http://cgit.freedesktop.org/~airlied/mesa/commit/?h=r600g-texture-gather&id=444bc1c8118d51600a58af8a84088e94d0800b22 but I suspect I've a bit further down the rabbit hole to go. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
Am 07.02.2014 04:37, schrieb Dave Airlie: > On Fri, Feb 7, 2014 at 12:36 PM, Roland Scheidegger > wrote: >> Am 07.02.2014 02:56, schrieb Ilia Mirkin: >>> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote: From: Dave Airlie This just adds the TG4 opcode, and a CAP for the max texture gather components. >>> >>> Is this different from GATHER4? If it is, should probably be >>> documented in docs/source/tgsi.rst... >> I'm pretty sure this is the OGL-equivalent of gather4 (as gather4 is >> d3d10-style, that is separate sampler and resource reg). >> You are quite right though this is definitely missing documentation >> (looking at it I have no idea for instance how the component selection >> is going to work). >> > Doh, yes because GL has ARB_texture_gather then has stuff hidden away > in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should > do. > > So I've reposted with the component selection in src1 now. Hmm seems a bit excessive to use an extra reg for that (gather4 but only in d3d11 form uses a src_sel on the sampler reg, but that might not work). I realize this is actually more messy than I thought, since the initial ARB_texture_gather had the ability to query if multi-channel formats are allowed, but had no way to select the channel (somewhat relying on ARB_texture_swizzle to do it, though of course you can't issue multiple gathers with the same texture to get different channels that way). But glsl 4.00 version could select the channel. Is the ARB_texture_gather version actually all that useful or could you merge the two caps? That is, if you have the ability to fetch from multi-channel textures, assume you can also select the channel. The sm4 version of gather4 also has the single-channel format restriction - I guess though some hw really can do 4 channels without channel selection. Other than that, what about shadow samplers? Gather4 of course can't do it (because the d3d10-style opcodes have different opcodes for shadow comparisons), but the GL style opcodes are usually the same if shadow samplers or not are used. Maybe you don't want to handle that right now, just saying that if you'd want to use the same opcode you'd be missing a component in case of texture cube arrays... Since this can't be used for fixed function though I'd guess nothing would stop you from using a different opcode for shadow samplers. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
From: Dave Airlie
This just adds the TG4 opcode, and a CAP for the
max texture gather components.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 1 +
src/gallium/include/pipe/p_defines.h | 3 ++-
src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index f993600..0fa1338 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -221,6 +221,7 @@ static const struct tgsi_opcode_info
opcode_info[TGSI_OPCODE_LAST] =
{ 1, 3, 1, 0, 0, 0, OTHR, "TXL2", TGSI_OPCODE_TXL2 },
{ 1, 2, 0, 0, 0, 0, COMP, "IMUL_HI", TGSI_OPCODE_IMUL_HI },
{ 1, 2, 0, 0, 0, 0, COMP, "UMUL_HI", TGSI_OPCODE_UMUL_HI },
+ { 1, 2, 1, 0, 0, 0, OTHR, "TG4", TGSI_OPCODE_TG4 },
};
const struct tgsi_opcode_info *
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index dbedd87..316aa8b 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -520,7 +520,8 @@ enum pipe_cap {
PIPE_CAP_MAX_VIEWPORTS = 84,
PIPE_CAP_ENDIANNESS = 85,
PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
- PIPE_CAP_TGSI_VS_LAYER = 87
+ PIPE_CAP_TGSI_VS_LAYER = 87,
+ PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS = 88
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 8750bd2..8fa6a0a 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -453,7 +453,9 @@ struct tgsi_property_data {
#define TGSI_OPCODE_IMUL_HI 180
#define TGSI_OPCODE_UMUL_HI 181
-#define TGSI_OPCODE_LAST182
+#define TGSI_OPCODE_TG4 182
+
+#define TGSI_OPCODE_LAST183
#define TGSI_SAT_NONE0 /* do not saturate */
#define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
Am 07.02.2014 02:56, schrieb Ilia Mirkin:
> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This just adds the TG4 opcode, and a CAP for the
>> max texture gather components.
>
> Is this different from GATHER4? If it is, should probably be
> documented in docs/source/tgsi.rst...
I'm pretty sure this is the OGL-equivalent of gather4 (as gather4 is
d3d10-style, that is separate sampler and resource reg).
You are quite right though this is definitely missing documentation
(looking at it I have no idea for instance how the component selection
is going to work).
>
>>
>> Signed-off-by: Dave Airlie
>> ---
>> src/gallium/auxiliary/tgsi/tgsi_info.c | 1 +
>> src/gallium/include/pipe/p_defines.h | 3 ++-
>> src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
>> 3 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
>> b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> index f993600..0fa1338 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
>> @@ -221,6 +221,7 @@ static const struct tgsi_opcode_info
>> opcode_info[TGSI_OPCODE_LAST] =
>> { 1, 3, 1, 0, 0, 0, OTHR, "TXL2", TGSI_OPCODE_TXL2 },
>> { 1, 2, 0, 0, 0, 0, COMP, "IMUL_HI", TGSI_OPCODE_IMUL_HI },
>> { 1, 2, 0, 0, 0, 0, COMP, "UMUL_HI", TGSI_OPCODE_UMUL_HI },
>> + { 1, 2, 1, 0, 0, 0, OTHR, "TG4", TGSI_OPCODE_TG4 },
>> };
>>
>> const struct tgsi_opcode_info *
>> diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> index dbedd87..316aa8b 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -520,7 +520,8 @@ enum pipe_cap {
>> PIPE_CAP_MAX_VIEWPORTS = 84,
>> PIPE_CAP_ENDIANNESS = 85,
>> PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
>> - PIPE_CAP_TGSI_VS_LAYER = 87
>> + PIPE_CAP_TGSI_VS_LAYER = 87,
>> + PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS = 88
>> };
>>
>> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>> diff --git a/src/gallium/include/pipe/p_shader_tokens.h
>> b/src/gallium/include/pipe/p_shader_tokens.h
>> index 8750bd2..8fa6a0a 100644
>> --- a/src/gallium/include/pipe/p_shader_tokens.h
>> +++ b/src/gallium/include/pipe/p_shader_tokens.h
>> @@ -453,7 +453,9 @@ struct tgsi_property_data {
>> #define TGSI_OPCODE_IMUL_HI 180
>> #define TGSI_OPCODE_UMUL_HI 181
>>
>> -#define TGSI_OPCODE_LAST182
>> +#define TGSI_OPCODE_TG4 182
>> +
>> +#define TGSI_OPCODE_LAST183
>>
>> #define TGSI_SAT_NONE0 /* do not saturate */
>> #define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
>> --
>> 1.8.3.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=Y5GSMx5Dfya7evTxKvtT1FyqThgxuTDd4EpfBojeULw%3D%0A&s=484efa75618e456da6277866ffba19281f78b9a9f71cb4aafde69f1d2ab19701
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=Y5GSMx5Dfya7evTxKvtT1FyqThgxuTDd4EpfBojeULw%3D%0A&s=484efa75618e456da6277866ffba19281f78b9a9f71cb4aafde69f1d2ab19701
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
On Fri, Feb 7, 2014 at 12:36 PM, Roland Scheidegger wrote: > Am 07.02.2014 02:56, schrieb Ilia Mirkin: >> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote: >>> From: Dave Airlie >>> >>> This just adds the TG4 opcode, and a CAP for the >>> max texture gather components. >> >> Is this different from GATHER4? If it is, should probably be >> documented in docs/source/tgsi.rst... > I'm pretty sure this is the OGL-equivalent of gather4 (as gather4 is > d3d10-style, that is separate sampler and resource reg). > You are quite right though this is definitely missing documentation > (looking at it I have no idea for instance how the component selection > is going to work). > Doh, yes because GL has ARB_texture_gather then has stuff hidden away in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should do. So I've reposted with the component selection in src1 now. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium (v2)
From: Dave Airlie
This just adds the TG4 opcode, and a CAP for the
max texture gather components.
v2: add component selection src and a cap to say
hw can do it. (st can use to help control
GL_ARB_gpu_shader5/GLSL 4.00). Add docs.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 1 +
src/gallium/docs/source/tgsi.rst | 23 +++
src/gallium/include/pipe/p_defines.h | 4 +++-
src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
4 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index f993600..565f274 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -221,6 +221,7 @@ static const struct tgsi_opcode_info
opcode_info[TGSI_OPCODE_LAST] =
{ 1, 3, 1, 0, 0, 0, OTHR, "TXL2", TGSI_OPCODE_TXL2 },
{ 1, 2, 0, 0, 0, 0, COMP, "IMUL_HI", TGSI_OPCODE_IMUL_HI },
{ 1, 2, 0, 0, 0, 0, COMP, "UMUL_HI", TGSI_OPCODE_UMUL_HI },
+ { 1, 3, 1, 0, 0, 0, OTHR, "TG4", TGSI_OPCODE_TG4 },
};
const struct tgsi_opcode_info *
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 0501aca..5f54a6f 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -986,6 +986,29 @@ XXX doesn't look like most of the opcodes really belong
here.
dst.z = texture_depth(unit, lod)
+.. opcode:: TG4 - Texture Gather (as per ARB_texture_gather)
+ Gathers the four texels to be used in a bi-linear
+ filtering operation and packs them into a single register.
+ Only works with 2D, 2D array, cubemaps, and cubemaps arrays.
+ For 2D textures, only the addressing modes of the sampler and
+ the top level of any mip pyramid are used. Set W to zero.
+ It behaves like the TEX instruction, but a filtered
+ sample is not generated. The four samples that contribute
+ to filtering are placed into xyzw in clockwise order,
+ starting with the (u,v) texture coordinate delta at the
+ following locations (-, +), (+, +), (+, -), (-, -), where
+ the magnitude of the deltas are half a texel.
+
+ some can handle components - check the capability
+ PIPE_CAP_TEXTURE_GATHER_COMPONENT_SELECT
+
+.. math::
+
+ coord = src0
+
+ component = src1
+
+ dst = texture_gather4 (unit, coord, component)
Integer ISA
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index dbedd87..bd5e434 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -520,7 +520,9 @@ enum pipe_cap {
PIPE_CAP_MAX_VIEWPORTS = 84,
PIPE_CAP_ENDIANNESS = 85,
PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
- PIPE_CAP_TGSI_VS_LAYER = 87
+ PIPE_CAP_TGSI_VS_LAYER = 87,
+ PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS = 88,
+ PIPE_CAP_TEXTURE_GATHER_COMPONENT_SELECT = 89
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 8750bd2..8fa6a0a 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -453,7 +453,9 @@ struct tgsi_property_data {
#define TGSI_OPCODE_IMUL_HI 180
#define TGSI_OPCODE_UMUL_HI 181
-#define TGSI_OPCODE_LAST182
+#define TGSI_OPCODE_TG4 182
+
+#define TGSI_OPCODE_LAST183
#define TGSI_SAT_NONE0 /* do not saturate */
#define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium
On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This just adds the TG4 opcode, and a CAP for the
> max texture gather components.
Is this different from GATHER4? If it is, should probably be
documented in docs/source/tgsi.rst...
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/auxiliary/tgsi/tgsi_info.c | 1 +
> src/gallium/include/pipe/p_defines.h | 3 ++-
> src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
> b/src/gallium/auxiliary/tgsi/tgsi_info.c
> index f993600..0fa1338 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
> @@ -221,6 +221,7 @@ static const struct tgsi_opcode_info
> opcode_info[TGSI_OPCODE_LAST] =
> { 1, 3, 1, 0, 0, 0, OTHR, "TXL2", TGSI_OPCODE_TXL2 },
> { 1, 2, 0, 0, 0, 0, COMP, "IMUL_HI", TGSI_OPCODE_IMUL_HI },
> { 1, 2, 0, 0, 0, 0, COMP, "UMUL_HI", TGSI_OPCODE_UMUL_HI },
> + { 1, 2, 1, 0, 0, 0, OTHR, "TG4", TGSI_OPCODE_TG4 },
> };
>
> const struct tgsi_opcode_info *
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index dbedd87..316aa8b 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -520,7 +520,8 @@ enum pipe_cap {
> PIPE_CAP_MAX_VIEWPORTS = 84,
> PIPE_CAP_ENDIANNESS = 85,
> PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
> - PIPE_CAP_TGSI_VS_LAYER = 87
> + PIPE_CAP_TGSI_VS_LAYER = 87,
> + PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS = 88
> };
>
> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
> diff --git a/src/gallium/include/pipe/p_shader_tokens.h
> b/src/gallium/include/pipe/p_shader_tokens.h
> index 8750bd2..8fa6a0a 100644
> --- a/src/gallium/include/pipe/p_shader_tokens.h
> +++ b/src/gallium/include/pipe/p_shader_tokens.h
> @@ -453,7 +453,9 @@ struct tgsi_property_data {
> #define TGSI_OPCODE_IMUL_HI 180
> #define TGSI_OPCODE_UMUL_HI 181
>
> -#define TGSI_OPCODE_LAST182
> +#define TGSI_OPCODE_TG4 182
> +
> +#define TGSI_OPCODE_LAST183
>
> #define TGSI_SAT_NONE0 /* do not saturate */
> #define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
> --
> 1.8.3.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
