On Mon, May 13, 2019 at 4:48 PM Alyssa Rosenzweig <aly...@rosenzweig.io> wrote: > > > Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA > > values are just a bunch of bits with no int/float distinction, and > > therefore you shouldn't need to know how a register is used to compile > > the instruction producing it. The only distinction between imov and > > fmov, in both NIR and the Midgard ISA, is what modifiers they support. > > What you want to do is probably what you originally did, i.e. use fmov > > for NIR fmov as well as fabs and fneg, imov for imov (and if we delete > > fmov, just using it for fabs and fneg). If this fixes any bugs, it's > > just papering over bugs in your backend, and you should fix them > > instead. Note that later GLSL versions have intBitsToFloat() and > > floatBitsToInt() which blow away any assumption that the types will be > > consistent. > > That's how my mental model was, but it doesn't look to be the case: the > blob is very consistent in emitting imov/fmov distinclty (and > icsel/fcsel), and a lot of bizarre bugs come up if you do it any other > way, even absent any modifiers. There's -some- difference, it's just not > obvious what. Although I'll admit playing with intBitsToFloat/etc allow > seemingly wrong shaders even with the blob..
This means that you're probably missing something else, and this is papering over another bug. What the blob happens to use is irrelevant, and of course you can always force it to do the "wrong" move by reinterpreting things using intBitsToFloat()/floatBitsToInt(). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
