> Tell me a little more about what your hardware supports. Both integers and floats are first-class; they are each natively 32-bit, with 16-bit versions to be supported down the line. There's support for int8 and float64, but I haven't seen these used with GLSL, so I don't know how they work.
From what I can tell, booleans are NIR-style: ~0 for true, 0 for false. There are no opcodes for b2f or f2b; instead, bitwise ops (iand, etc) are used for the conversion. > Interpret the source as an integer, negate it, and convert to a float. I don't believe this can done with a move, although it may be possible to accomplish this with a source modifier to the dedicated i2f instruction. I'll need to test this at some point, although I'm not convinced it's any faster on this architecture. > We did both of these things in our backend when translating NIR's b2f > into our backend IR. Why is it better for you to do that in NIR? Hmm, that's a good point. I'm not too familiar with i965's architecture, but at the moment, my compiler uses only a thin backend IR. That is, its "IR" is essentially unpacked hardware instructions, with placeholders instead of registers, and metadata. Given that the ISA is a good match for NIR, normally this simplifies the backend tremendously, as the only optimisation passes I need to implement are highly specialised to the hardware. By contrast, I would not want to implement constant folding, for instance, on the backend IR. I was hoping that NIR, by design, would eliminate this code duplication between backends. Accordingly, I try to keep code in NIR as late as possible, reusing standard lowering and optimisation passes. Theoretically, a patch like this would enable the lowered iand (or type conversion) to benefit from further NIR optimisations and allow code to be shared with other backends, but I'm admittedly grasping for straws here. The backend design is still early, and I haven't figured out what the ideal split of responsibilities between common code and the backend should be. I'm open to further input -- if major changes are needed, it's better for that to happen now than when I send the patches in for the compiler itself! _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
