[Mesa-dev] [PATCH] mesa/st: add support for dynamic sampler offsets

[Ilia Mirkin]

So... can I get a review on this? It's the last bit needed for ARB_gs5
(well, except for the actual setting of the extension bit to 1)

The only additional change I have in my local version is that instead of

+      inst->sampler_array_size =
+         ir->sampler->as_dereference_array()
+            ->array->variable_referenced()->type->length;

I use ir->sampler->as_dereference_array()->array->type->array_size()

I sent out a few piglits and they pass with the nvc0 driver on both
fermi and kepler hw (which do textures a little differently from one
another).

  -ilia


On Wed, Aug 6, 2014 at 12:02 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Wed, Aug 6, 2014 at 5:53 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>       pc->MaxAddressRegs     = pc->MaxNativeAddressRegs     =
>>          _min(screen->get_shader_param(screen, sh, PIPE_SHADER_CAP_MAX_ADDRS),
>>               MAX_PROGRAM_ADDRESS_REGS);
>>
>> Not really sure what that's referring to... ARB_vp/fp or something?
>
> Yes, ARB_vp needs 1, ARB_fp doesn't support indirect addresing (expects 0).
>
>>
>> Anyways, this is definitely a bit of a violation of that. OTOH, so is
>> the indirect UBO indexing and indirect GS input access (assuming
>> that's allowed), since those would use ADDR[1] and every driver
>> (except nv30) returns 1, and sometimes 0 -- including
>> nv50/nvc0/r600/radeonsi.
>>
>> So... dunno what the proper way to proceed is. Fix drivers to claim
>> higher numbers? Continue the tradition of ignoring it and relying on
>> the fact that GPU's that don't support it also won't support the
>> features that cause it to get used?
>
> You don't have to worry about that for now. We can clean it up later.
>
> Marek