[Mesa-dev] [PATCH] r600g: Implement GL_ARB_texture_gather

[Glenn Kennard]

On Mon, 14 Jul 2014 20:33:08 +0200, Ilia Mirkin <imirkin at alum.mit.edu>  
wrote:

> On Mon, Jul 14, 2014 at 2:20 PM, Glenn Kennard <glenn.kennard at gmail.com>  
> wrote:
>> diff --git a/src/gallium/drivers/r600/r600_pipe.c  
>> b/src/gallium/drivers/r600/r600_pipe.c
>> index ca6399f..d967f0f 100644
>> --- a/src/gallium/drivers/r600/r600_pipe.c
>> +++ b/src/gallium/drivers/r600/r600_pipe.c
>> @@ -303,6 +303,9 @@ static int r600_get_param(struct pipe_screen*  
>> pscreen, enum pipe_cap param)
>>         case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
>>         case PIPE_CAP_CUBE_MAP_ARRAY:
>>         case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
>> +       case PIPE_CAP_TEXTURE_GATHER_SM5:
>> +               return family >= CHIP_CEDAR ? 1 : 0;
>
> No clue what the hardware supports, and this CAP is actually not used
> by the state tracker. However I believe it is meant to imply that you
> can support the ARB_gs5 texture gather, including shadow comparisons
> and non-constant offsets. This is not yet turned on by core mesa, but
> do the textureGather tests still pass if you add
> MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5? (You can do a piglit-run
> with -t gather.) I'm not 100% sure, but I _think_ it also implies that
> you can deal with selecting any component from a 4-component
> texture... the ARB_gs5 spec says:
>
>     Since this extension requires support for gathering from  
> multi-component
>     textures, the minimum value of  
> MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB
>     is increased to 4.
>
> My understanding is that the hardware is meant to be able to support
> GL4 one way or aonther, but sounds like more work needs to be done in
> order to claim the SM5 compatibility cap...

Good catch, i missed that. It should return 0 for  
PIPE_CAP_TEXTURE_GATHER_SM5, and 1 for number
of components, which lets it expose the ARB_texture_gather extension for  
now, leaving SM5 support for
a later patch - the hardware apparently doesn't support texture sampler  
swizzling natively for the GATHER4
instruction so some logic is required to compile shader variants whenever  
the swizzle changes.

>
> Also, have you looked at Dave Airlie's impl? Not sure what's been
> going on there...
> http://cgit.freedesktop.org/~airlied/mesa/log/?h=r600g-texture-gather
> . He seemed to enable 4 components for >= CEDAR.
>

No, didn't pop up when i searched the archives for any prior work on this.  
Interesting! It looks like the GL_ARB_texture_gather portion in that  
branch is almost exactly equivalent to my patch.

It also has some of the additional parts needed for GL_ARB_gpu_shader5  
such as non-constant offsets, but i don't see where it would trigger  
shader recompiles if texture sampler swizzle changes? Does it pass piglit?


David, any opinions on how to move forward with this feature?