Am 08.05.2013 17:17, schrieb Marek Olšák: > The SUB opcode is not emitted by GLSL, however this may change in the > future. I don't think using specialized opcodes instead of the > modifiers will make anyone's life easier (the modifiers must be > implemented anyway). > > If you really want people to follow the TGSI documentation, there > should be a utility function which validates TGSI and st/mesa should > reject shaders which are invalid. Right now, GLSL-to-TGSI generates > UCMP with the first operand negated. This looks like a simple bug (negating integers isn't going to change the outcome of the logic test the input is used for...). I don't know what the glsl translation is trying ot do there, seems like it wants to set ~0 or 0 but the UCMP looks not only very bogus but completely unnecessary too (the preceding USNE will already set ~0 or 0 and if it wants the opposite it should use USEQ instead). There's some other somewhat bogus code with comments saying UCMP should be used instead of some poor emulation with i2f instructions. But in any case this is really independent from clarifying what these opcodes are supposed to do.
Roland > > Marek > > > > On Wed, May 8, 2013 at 3:51 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> 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 >>> <e0425...@student.tuwien.ac.at> wrote: >>>> On 08.05.2013 03:48, srol...@vmware.com wrote: >>>>> From: Roland Scheidegger <srol...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
