[Mesa-dev] Mesa (master): r600g: Use default mul/mad function for tgsi-to-llvm

[Alex Deucher]

On Thu, Dec 6, 2012 at 2:37 PM, Michel Dänzer <michel at daenzer.net> wrote:
> On Don, 2012-12-06 at 10:52 -0800, Tom Stellard wrote:
>> On Thu, Dec 06, 2012 at 07:25:55PM +0100, Michel Dänzer wrote:
>> > On Don, 2012-12-06 at 09:05 -0800, Tom Stellard wrote:
>> > > On Thu, Dec 06, 2012 at 05:08:07PM +0100, Michel Dänzer wrote:
>> > > > On Mit, 2012-12-05 at 09:32 -0800, Vincent Lejeune wrote:
>> > > >
>> > > > I suspect the problem is a (non-)IEEE semantics mismatch between TGSI
>> > > > and LLVM introduced by this change.
>> > >
>> > > What are the semantics of TGSI opcodes?  For MUL and MAD, tgsi_exec uses IEEE
>> > > operations, but it seems like the glsl frontend thinks they are non-IEEE.
>> >
>> > Not sure... FWIW, the tests pass on llvmpipe.
>>
>> I just looked at the TGSI->LLVM code, which is shared by r600g,
>> radeonsi, and llvmpipe.  For TGSI_OPCODE_MUL, it actually uses both
>> the IEEE and non-IEEE definitions depending on what the arguments are.
>> If one of the arguments to MUL is the compile time constant zero then it
>> uses the non-IEEE definition (0 * anything) = 0, otherwise it produces
>> a fmul instruction which has IEEE semantics.  This probably deserves
>> it's own thread, because I think newer versions of GLSL require IEEE,
>> but older versions and also ARB have different semantics.
>
> Right, also, the code you described doesn't cover cases where a
> non-constant value is 0.
>
>
>> > > Should we revert this and the associated LLVM changes?
>> >
>> > I guess it depends on the answer to the above question about the
>> > expected semantics.
>> >
>> > Given that these tests seem to use indirect addressing, could it be that
>> > they just happened to pass by accident before?
>>
>> Yeah, those tests must have been passing by accident.  Are there any other
>> failing tests?
>
> No, those are the only two tests that regressed for me. So I guess this
> can be ignored for now. It would be interesting to know which tests Alex
> was referring to though, which were fixed by switching from MUL_IEEE to
> MUL. Maybe those are covered by the code you described above though.

I wasn't talking about recent changes, This was back in the early days
of r600g.  Probably the same thing Tom was talking about.

Alex