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. 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. > This adds a macro + interface to check if a type is 64-bit, > which currently is only true for doubles, it then uses the new > API in places where it makes sense. > > There is also a patch to st/glsl_to_tgsi to use glsl_base_type > enum for better type safety. > > Dave. > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
