On Thu, Dec 6, 2012 at 2:37 PM, Michel Dänzer <mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
