On 04/07/2014 06:24 AM, Ian Romanick wrote: > On 04/06/2014 11:49 PM, Kenneth Graunke wrote: >> The i965 MUL instruction doesn't natively support 32-bit by 32-bit >> integer multiplication; additional instructions (MACH/MOV) are required. >> However, we can avoid those if we know one of the operands can be >> represented in 16 bits or less. The vector backend's is_16bit_constant >> static helper function checks for this. > > In IVB+ the hardware actually does 32-bit by 16-bit to give a 48-bit > result (on SNB and earlier it's 16-bit by 16-bit... yay). According to > Emil Persson, new generation consoles have similar (but different) > integer multiplication issues (see slide 35 from > http://www.humus.name/index.php?page=Comments&ID=371). Should we expose > a lesser precision integer multiply function similar to mul24()?
As, say, a GLSL built-in function? Possibly. Presumably our restrictions are different than anyone else's though, and even ours changed between generations. So I wonder if anyone would bother using what we cooked up. Plus, Broadwell just handles this properly, so this really only saves a couple of instructions on "old" hardware. Obviously, it's not really "old", but...by the time we draft a GL extension, implement it, and get people to bother using it in upcoming applications...we'll be down the road a ways. So, I doubt it's really worth doing, but I wouldn't be horribly against it if someone bothered. One big source of integer multiplication is for computing byte offsets into UBOs or other constant buffers. In that case, we're usually scaling by a small constant factor (say, 4 or 16 bytes), which is well covered by our existing optimization. --Ken
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
