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

[Roland Scheidegger]

Am 04.06.2015 um 21:36 schrieb Rob Clark:
> 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. ;-)
>>
>>>
>>> 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.
>>
>> 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..
> 

I'll have to agree with Jose here, having this both in instructions and
decls just seems wrong. And it looks to me like it would be more natural
to have it in decls as well.

Well at some point IIRC we had the idea to just drop the old style tex
opcodes and convert everything to use sample ones, since they can easily
express everything both d3d10 and gl needs (though obviously they are
more powerful than what gl needs). That would make things a lot more
consistent (it would have helped here as you'd get the return type of
the sampler view already), but it's probably too much work now, though
from a theoretical point of view it imho still would make a lot of sense.
I guess if you add it to the sampler decl that's quite awkward as well
(since these are used for d3d10 sample opcodes too, thus for sample
instructions the information from the sview decl would be used even
though it would be theoretically also be encoded in the sampler).

Roland