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

[Marek Olšák]

Acked-by: Marek Olšák <marek.olsak at amd.com>

Marek

On Sat, Aug 9, 2014 at 7:52 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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