On Thu, Jun 9, 2016 at 2:07 PM, Ian Romanick <[email protected]> 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. > > 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 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]. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
