[Mesa-dev] TGSI conventions (Was: gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition)

[Jose Fonseca]

I don't really care much about modifiers vs no-modifiers, or ABS/SUB opcodes vs no opcodes.  It is merely a convention, and as long as we consistently follow it we're good IMO.

I am, however, worried about this growing trend of long threads about TGSI with little more than nitpicking.  I think that this indecision and back'n'forth is an evil in itself, more than making any decision could be: all sides have to spend substantial time putting their argument forth, at the end of the day some decision will have to be made, compromises unavoidable, and by then somebody is bound to be unhappy and frustrated (more unhappy and frustrated the bigger the investment in the discussion).

This is not a critique aimed to anybody in particular, but to us all as a community.  And I think that the fact that we are all smart and passionate about this stuff actually goes against us.

So I think we should have some stronger rules of thumb of where we want TGSI to go, so that we can all make progress without less overhead from everybody.

I also believe that there is benefit in gallium mimicking more closely the standards out there, instead of trying to find our own solution for every little gallium design decision.  Khronos has not specified an GLSL bytecode till date, and in my knowledge ARB/NV_fragment_programs is too old to be a good model.  So for tokenized shader, D3D10/11 bytecode is the best model we have out there.  Furthermore, Gallium drew a lot of inspiration from D3D10 API, so it is only natural we do the same for tokenized shaders.

Therefore, I think we should just aim to have TGSI match D3D10/11 tokenized shaders more closely, at very least on matters of mere convention, so that we can all go spend more time on more interesting problems.

Jose


----- Original Message -----
> Am 08.05.2013 12:47, schrieb Marek Olšák:
> > Modifiers are actually very useful with MOV. However I don't think the
> > modifiers really care what the type is. They just change the sign bit
> > of float (which is a bitwise operation). Also, UCMP doesn't do
> > anything with the 2nd and 3rd argument, so their types don't matter.
> Well, they do matter for the input modifiers.
> They might just change the most significant bit on your hardware but
> that's not how they are defined in tgsi.
> I don't really care that much if the 2nd and 3rd argument to ucmp are
> ints or floats (it's true for d3d10 movc translation floats are the
> natural choice but we can easily translate that to several ops instead,
> e.g. mov's with modifiers followed by ucmp). I do care however that all
> drivers treat them the same, not like now where softpipe will do two's
> complement negation on src input modifiers whereas llvmpipe will flip
> the sign bit.
> 
> > 
> > I think the ABS and SUB opcodes should be removed in favor of the
> > modifiers.
> Those are in very widespread use and at least for SUB it definitely
> avoids additional effort for drivers which can't do input modifiers
> natively.
> 
> Roland
> 
> 
> > 
> > Marek
> > 
> > On Wed, May 8, 2013 at 12:14 PM, Christoph Bumiller
> > <e0425955 at student.tuwien.ac.at> wrote:
> >> On 08.05.2013 03:48, sroland at vmware.com wrote:
> >>> From: Roland Scheidegger <sroland at vmware.com>
> >>>
> >>> UCMP while an integer opcode isn't really consistently implemented as
> >>> having all integer arguments. softpipe will assume all arguments are
> >>> ints, whereas gallivm has the arguments defined as untyped which
> >>> means they'll get treated as floats. This means input modifiers will
> >>> not work the same. Fix this by saying only first arg is an integer,
> >>> which seems more useful than making all arguments integers - this would
> >>> be similar to d3d10 movc opcode.
> >>> ---
> >>>  src/gallium/docs/source/tgsi.rst |    5 +++++
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/src/gallium/docs/source/tgsi.rst
> >>> b/src/gallium/docs/source/tgsi.rst
> >>> index 3af1fb7..852f8a0 100644
> >>> --- a/src/gallium/docs/source/tgsi.rst
> >>> +++ b/src/gallium/docs/source/tgsi.rst
> >>> @@ -1291,6 +1291,11 @@ Support for these opcodes indicated by
> >>> PIPE_SHADER_CAP_INTEGERS (all of them?)
> >>>
> >>>  .. opcode:: UCMP - Integer Conditional Move
> >>>
> >>> +.. note::
> >>> +
> >>> +   Only the first source arg is an integer, the 2nd and 3rd ones are
> >>> +   considered floats (for input modifier purposes).
> >>> +
> >>
> >> As long as you patch up all the occurrences of
> >> tgsi_opcode_infer_src_type and make it take an argument to identify the
> >> source ...
> >>
> >> I'd rather just forbid modifiers on moves, i.e. MOV and UCMP, since at
> >> least MOV returns TGSI_TYPE_UNTYPED and untyped values can't be operated
> >> on.
> >> For the ordinary MOV we have NEG and ABS, and for UCMP the backend
> >> optimizer can take care of merging modifiers into the instruction
> >> (nvc0's UCMP (slct u32) doesn't support modifiers)
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>