[Mesa-dev] [PATCH 1/2] tgsi: add texture-type info to texture instructions

[Rob Clark]

On Thu, Jun 4, 2015 at 3:55 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 04/06/15 20:36, Rob Clark wrote:
>>
>> On Thu, Jun 4, 2015 at 3:22 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>
>>> On Thu, Jun 4, 2015 at 3:11 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>>
>>>> On 04/06/15 19:50, Rob Clark wrote:
>>>>>
>>>>>
>>>>> On Thu, Jun 4, 2015 at 2:14 PM, Jose Fonseca <jfonseca at vmware.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> I think we had a discussion about this on mesa3d-dev a while ago.  I
>>>>>> don't
>>>>>> recall the conclusions but I wish I did.
>>>>>>
>>>>>> We have tgsi_return_type.  Why isn't this enough?  Or better, why
>>>>>> isn't
>>>>>> being used for this?
>>>>>
>>>>>
>>>>>
>>>>> mostly arbitrary reasons.. the unorm/snorm values don't really make
>>>>> sense here, so it didn't quite seem to fit (plus would have needed
>>>>> another bit, although I guess that isn't really an issue)
>>>>>
>>>>> Or if the question was, why not include the type information in the
>>>>> decl rather than the instr?  Well.. that at least is more awkward for
>>>>> the implementation, since the information is part of the instruction
>>>>> for both GLSL IR and NIR (and at the end of the day, that is also
>>>>> where I need the info in my compiler)
>>>>
>>>>
>>>>
>>>> IIUC, GLSL also has this information readily available in the sampler
>>>> declaration:
>>>>
>>>>    uniform  sampler2D ftex;
>>>>    uniform isampler2D itex;
>>>>    uniform usampler2D utex;
>>>>
>>>> So isn't this a double standard?  After all, if the argument here is
>>>>
>>>>    "GLSL IR / NIR has this info readily available, so let's pass it to
>>>> the
>>>> TGSI",
>>>>
>>>> then the same rationale should apply to
>>>>
>>>>    "GLSL has this info readily available on the sampler declaration, so
>>>> lets'
>>>> pass it to GLSL IR/NIR 's declarations."
>>>>
>>>
>>> ok, possibly GLSL IR has this info also in the decl.. tbh I'm not a
>>> GLSL IR expert.  I just figured out my way around since I know where I
>>> want the info in NIR, and then looked at where it came from in
>>> glsl_to_nir.
>>>
>>> But at any rate, NIR only has it on the tex instruction.  So my point
>>> about having it in the decl making it more akward for tgsi-to-nir and
>>> my compiler still stands. ;-)
>
>
> So does my counter-point: if it's OK to add readily available upstream
> information to TGSI for downstream convenience, it should also be OK to add
> readily available upstream information to NIR for downstream convenience.
>
> In short, why not add this info to NIR's declarations?

well, I mean NIR doesn't even have an equivalent to decl's for samplers..

>
>>>>
>>>> I want to avoid having two places for this info in TGSI: in decl and in
>>>> instruction, as that's a recipe for bugs and complexity.  _Specially_
>>>> when
>>>> the decl is imposed for D3D10 support, while the inst is mere a matter
>>>> of
>>>> internal Mesa convention...
>>>>
>>>
>>> having the information duplicated (or at least in the instruction) is
>>> more convenient for the consumer of tgsi.  If you are worried about
>>> bugs/inconsistencies then something similar to nir_validate_shader()
>>> for tgsi would have seemed like a better direction.
>
>
> Not really, as the sort bugs I'm worried is driver's TGSI translation, not
> TGSI internal inconsistency.  In particular, drivers like llvmpipe, that
> need support both cases, having bugs due to that.
>
> It's also bad for new drivers developers -- it's not clear if/which parts of
> TGSI to support.

if it is guaranteed for the driver writer that it is same information
in both places, then driver writer can just pick whichever is more
convenient for how their hw works..

that said, maybe it is a bit late to start talking about making tgsi
user-friendly..

> Take also drivers that want to spew D3D10 shaders / GLSL on the other side
> -- they too could benefit of having this info in the shader decls.
>
>
>>>
>>> BR,
>>> -R
>>>
>>>>
>>>> In short, I'm fine in in principle with piping this info through, but
>>>> lets
>>>> come up a decent generalization.  In particular, lets try get this in
>>>> the
>>>> decls so it's consistent.
>>
>>
>> oh, hmm, the sampler-view thing looks like a rather longer path to get
>> what I need.. since it isn't even used currently..
>
>
> If you don't want to add SVIEW decls fine. Let's add the type to the TEX
> declaration then.  It's a least a steap in that direction.

ok, I'll have a look at making it part of tex decl..  at least by the
time it goes through tgsi-to-nir the information is back where I want
it for my driver..

BR,
-R

> But I'm afraid can't really endorse having two places in TGSI for this..
>
> Jose
>