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

[Roland Scheidegger]

Am 09.08.2014 16:33, schrieb 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?
> 
Well I didn't think about it that much but nothing is stopping you from
putting whatever you need into the glsl_to_tgsi_visitor to keep that
array information instead of just filling out samplers_used.

> 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.
Agreed. The address thingy is also something which should go away as
discussed but really separate issue too.
btw you get the actual sampler type from the constant in the sampler reg
right? So if you have
4: TEX TEMP[1], TEMP[1], SAMP[ADDR[2].x+1], 2D
that +1 in there says the 2nd declared sampler determines what kind of
sampler this is (2d, 3d, shadow...).

Roland


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