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

[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,
 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.