[Mesa-dev] prep work for 64-bit integer support

[Ian Romanick]

On 06/09/2016 11:26 AM, Ilia Mirkin wrote:
> On Thu, Jun 9, 2016 at 2:07 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 06/08/2016 02:15 PM, Dave Airlie wrote:
>>> While writing ARB_gpu_shader_int64 I realised I needed to change
>>> a lot of existing checks for doubles to 64bit, so I decided to
>>> do that as much in advance as possible.
>>
>> I didn't know you were working on that.  I just started poking at more
>> general sized integer support too.  I wanted to add support for 8, 16,
>> and 64-bit types.
> 
> Might be worth noting that NVIDIA has some support for "SIMD"
> operations on 16- and 8-bit sized values packed in a 32-bit integer.
> You can see what operations are supported by looking up "video
> instructions" in the PTX ISA - those roughly map 1:1 with the
> hardware. However I've never seen NVIDIA blob actually generate them,
> even with NV_gpu_shader5's u8vec4 and such. I don't know how this
> changes on Pascal, which is rumored to support fp16 ALU natively.

Have you tried feeding it PTX directly?  It could just be a limitation
of the GLSL compiler.

>> What's your hardware support plan?  I think that any hardware that can
>> do uaddCarry, usubBorrow, [ui]mulExtended, and findMSB can implement
>> everything in a relatively efficient manner.  I've coded almost all of
>> the possible 64-bit operations in GLSL using ivec2 or uvec2 and these
>> primitives as a proof of concept.  Less efficient implementations of
>> everything is possible if any of those primitives are missing.
>> Technically speaking, it ought to be possible to expose 64-bit integer
>> support on *any* hardware that has true integers.
>>
>> I'm currently leaning towards implementing these as a NIR lowering pass,
>> but there are other possibilities.  There are advantages to doing the
>> lowering after most or all of the device independent optimizations.  In
>> addition, doing it completely in NIR means that we can get 64-bit
>> integer support for SPIR-V nearly for free.  I've also considered GLSL
>> IR lowering or lowering while translating GLSL IR to NIR.
> 
> While I can't speak for AMD hw, NVIDIA has some limited support for 64-bit ints:
> 
> (a) atomics
> (b) shifts (so you don't have to use a temp + bitfield manipulation to
> shift from one 32-bit val to another)
> (c) conversion between float/double and 64-bit ints

Yeah, some Intel hardware is similar.  I suspect we'd want to have a
bitfield to select which specific operations or groups of operations
actually need to be lowered.  Jason and Ken reminded me that we already
do basically the same thing for fp64.

> And things like addition can be done using things like carry bits. We
> have a pass to auto-lower 64-bit integer ops at the "end" so that
> splitting them up doesn't affect things like constant propagation and
> other optimizations. [I'm sure it'll need adjusting for a full 64-bit
> int implementation, it mostly ends up getting used with address
> calculations.] So I'd be highly in favor of (a) letting the backend
> deal with it and (b) having the requisite TGSI opcodes to express it
> all cleanly [which is what Dave has done].

We'll definitely need support in the lower-level IRs.  Current and
future GPUs have various levels of native support.  We really want to
take advantage of that.  Some drivers will also want to implement their
own lowering for some things.  For example, before Gen7, Intel GPUs
didn't have a 32x32->64 multiplier.  They have a 16x32->48 multiplier
(I'm not kidding) that can be used to simulate a 32x32->64 multiplier.
I think we can use that in a clever way to generate a 64x64->64 results
more efficiently than would come from a generic lowering pass that uses
32x32->64 multiplications.

At the same time, if implementing lowering once at a higher level means
that we can enable a feature in more places more quickly, that seems
like winning.  I think blending the two approaches will lead to the best
overall result.  I doubt Marek will spend any effort implementing 64-bit
integer support for r600.  If the real work of adding that support
happened at higher levels of Mesa, I bet he'd accept patches. :)

>   -ilia