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

[Jose Fonseca]

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?

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

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.

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

Jose