On Fri, Jun 25, 2021 at 11:52 AM Nikolay Dubina wrote: > > I tried to write down my own CUDA / NVIDIA GPU driver in native Go last > weekend. To my great surprise, CUDA and pretty much all high performance > software/hardware from NVIDIA is proprietary close-source C/C++ code. > Meaning, you can't write native Go driver even if you wanted to. Forget Go, > people are trying to reverse engineer it in C/C++ with limited success. From > what I heard OpenCV is not a priority for NVIDIA either. Then I looked up > what Apple is doing with their Neural Engine in latest chips. It too is > closed-source Objective-C, Swift. I suspect situation with other powerful > hardware is the same. Moore's law seem to be about GPU lately, and everyone > is locking it in. Kind of not in the spirit open-source and Linux. That's > quite bad state of affairs for Go and computing in general. Yikes! > > Just want to see what others are thinking.
That would be a very nice thing to have. I see four basic areas where this becomes tricky or requires a lot of work. 1) Getting memory management right for sharing with the accelerator device. Shared memory buffers need to stay locked for longer than just the call to a library or to the OS kernel, but in the worse case could use something like Manish Rai Jain of Dgraph described at https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/ . A lot of Nvidia's recent CUDA programmer-productivity improvements have focused around transparent data movement, and Go's garbage collector probably breaks the assumptions for those. 2) "Friendly" source development (like CUDA C) integrates the host and target code into a single code base, with some kind of markup or compiler hint about which functions should be compiled for the accelerator, and which function calls need to be treated specially. Those "special" function calls must be translated to dispatch the call (usually with additional arguments like the grid/NDRange parameters) to the accelerator rather than as a normal function call. This is a compiler front-end problem, which is almost certainly a lot easier with Go than with C or C++, but still requires attention and perhaps considerable effort because it requires multiple back-ends to run for some functions. In the worst case, do like OpenCL and require the programmer to provide or build strings containing program text, along with verbose code to set up calls to the accelerator. 3) Generating code for the accelerator. SPIR-V is an obvious candidate for portable uses; it integrates reasonably with current OpenCL as well as Vulkan. Nvidia makes a reasonable compromise for this with their PTX assembly pseudo-language: They have good documentation about which PTX instructions are only supported on some GPU generations, they document when the translation to actual machine code varies in major ways, and they even have a decent API for compiling application-provided PTX code. This is a compiler back-end problem, conditional on not accepting the "worst case" in #2 above. 4) Integrating target libraries with the rest of an application. A large part of the value proposition for CUDA is that it has a lot of highly optimized libraries available out of the box: cuFFT, cuBLAS/NVBLAS, and more. These are a hybrid between GPU elements and host elements, and a lot of the host elements end up being black boxes with respect to other languages. The most general fix is to call out to C, which is not satisfying for portability. If I were going to spend the time on this, I would probably target SPIR-V with Vulkan or OpenCL for portability rather than Nvidia's PTX or Apple's Metal. AMD, Nvidia and Google (Android) all have good support for SPIR-V through their Vulkan stacks, and there are third-party Vulkan layers that run on MacOS. - Michael Poole -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOU-OAK3dUn0hDAvEt3ayhQO4Ryg2-bMpaKZTCxW086%2BYFFnpQ%40mail.gmail.com.
