[Mesa-dev] [PATCH 3/9] glsl: Make is_16bit_constant from i965 an ir_constant method.

[Kenneth Graunke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140407/c2add627/attachment.sig>