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

[Roland Scheidegger]

On closer look, it looks to me like it wouldn't be all that difficult to
make proper sampler array dcls (as you apparently get them quite easily
from glsl) which is really my only problem with it but it's not really
all that important so
Reviewed-by: Roland Scheidegger <sroland at vmware.com>

Am 09.08.2014 07:52, schrieb 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=Xj1ezgC9gYJQCVun05Qsf2AVkWdMTWcufiVpM6QH7Mk%3D%0A&s=03cd8d1ec34661de07f9c6aa8d6efef3163477a18a55dc4a89d2eaa7d73d16f5
>