On Mon, May 18, 2015 at 3:28 PM, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On Monday, May 18, 2015 11:26:05 AM Matt Turner wrote:
>> On Fri, May 8, 2015 at 3:36 AM, Kenneth Graunke <kenn...@whitecape.org>
>> wrote:
>> > According to Glenn, shifts on R600 have 5x the throughput as multiplies.
>> >
>> > Intel GPUs have strange integer multiplication restrictions - on most
>> > hardware, MUL actually only does a 32-bit x 16-bit multiply. This
>> > means the arguments aren't commutative, which can limit our constant
>> > propagation options. SHL has no such restrictions.
>> >
>> > Shifting is probably reasonable on most people's hardware, so let's just
>> > do that.
>> >
>> > i965 shader-db results (using NIR for VS):
>> > total instructions in shared programs: 7432587 -> 7388982 (-0.59%)
>> > instructions in affected programs: 1360411 -> 1316806 (-3.21%)
>> > helped: 5772
>> > HURT: 0
>>
>> Just to close the loop, I ran shader-db with this patch on top of my
>> integer multiplication series, and it doesn't change any instruction
>> counts on i965. (I also tried with all other power-of-two
>> multiplications for shift values < 31.)
>>
>> We may want to do it for other reasons though.
>
> If we're going to do it because shifts are faster/nicer than multiplies,
> then we should probably just do it for powers-of-two in general.
> Unfortunately, opt_algebraic doesn't really lend itself to that without
> adding some sort of "power of two" infrastructure.
>
> I guess we could optimize things like:
> a * 2^n => a << n
> a % 2^n => a & (n-1)
> a / 2^n => a >> n (possibly only for unsigned? (*))
> ...others?
>
> The first is a clear win on r600, and the latter are clear wins on i965,
> though they may be rather rare...
>
> We could add a custom NIR pass. Or, we could just or just have backends
> check for an immediate second operand and do this sort of stuff. Or
> optimize it themselves. *shrug*
Or we could just do
for i in range(32):
optimizations.append(('imul', a, (1 << i)), ('ishl', a, i)))
--Jason
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
