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

[Ilia Mirkin]

On Sat, Aug 9, 2014 at 10:14 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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

If you can briefly outline how you think that should be done, I'd be
happy to try to do it. Right now the samplers are declared in
st_translate_program, which only has the program->samplers_used
bitfield (where program is glsl_to_tgsi_visitor).

One quick thing that occurs to me is to keep track of samplers in a
map of index -> array size (0 if it's not accessed indirectly or not
an array), and then using the map to create the declarations. Does
that seem reasonable?

Either way, this seems like a nice-to-have rather than required, so
I'm going to push this patch even if the other one isn't ready.

> 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>

Thanks!

>
> 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
>>
>