[Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium

[Dave Airlie]

On Sat, Feb 8, 2014 at 10:22 PM, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> 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.