On Fri, Apr 20, 2018 at 5:16 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 20.04.2018 10:21, Iago Toral wrote: > >> Hi, >> >> while developing support for Vulkan shaderInt16 on Anvil I came across >> a feature of NIR that was a bit inconvenient: bools are always 32-bit >> by design, but the Intel hardware produces 16-bit bool results for 16- >> bit comparisons, so that creates a problem that manifests like this: >> >> vec1 32 ssa_21 = fge ssa_20, ssa_16 >> vec1 16 ssa_22 = b2f ssa_21 >> > I was thinking about this a bit this morning and it gets even more sticky. What happens if you have bool e = (a < b) && (c < d); where a and b are 16-bit and c and d are 32-bit? In this case, one comprison has a 32-bit value and one has a 16-bit value and you have to pick one for the &&. > Our CMP instruction will produce a 16-bit boolean result for the first >> NIR instruction (where NIR expects it to be 32-bit), so by the time we >> emit the second instruction in the driver the bit-size for the operand >> of b2f provided by NIR no longer matches the reality and we emit >> incorrect code. >> >> This seems to have been a consicious design choice in NIR, and while >> discussing this with Jason he was unsure how much we wanted to change >> this or how to do it, given how thoroughly 32-bit bools are baked into >> NIR and the complexities that modifying this would also bring to our >> bit-size validation code. >> >> I have been considering alternatives that didn't involve changing NIR >> to support multiple bit-sizes for booleans: >> >> 1) Drivers that need to emit smaller booleans could try to fix the >> generated NIR by correcting the expected bit-sizes for CMP >> instructions. This would be rather trivial to implement in drivers (and >> maybe we could even make a generic pass for other drivers to use if >> they need it) but this will make the validator complain because it >> won't recognize comparisons with 16-bit bool outputs as valid NIR >> opcodes. I also found instances where nir_search would complain about >> mismatching bit-sizes. I haven't looked any further into it yet though, >> so maybe we can reasonably work around these issues. >> >> 2) Drivers could handle this specially when they emit code from NIR. >> Specifically, when they see a 32-bit boolean source in an instruction, >> they would have to search for the instruction that produced that source >> value and check whether it is a 16-bit or a 32-bit boolean to emit >> proper code for the instruction. >> >> 3) Drivers can just convert the 16-bit bool result they generate for >> 16-bit cmp to the 32-bit bool that NIR expects, and then possibly run >> an optimization pass to eliminate these extra conversions and fix up >> the code accordingly. >> > > radeonsi(NIR) and radv already use option 3, since GCN hardware really > wants to treat bools as 1-bit value, so that's what I'd suggest. The > optimizations that cleanup the conversions happen in LLVM for us. > Is this a GCN thing or an LLVM thing? It would be neat if your hardware had 1-bit registers. :-) We sort-of do but they're special flag registers and we have very few of them. --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
