As others have said, lots of secret sauce which includes the instruction set for the function blocks in silicon. Thus there is no assembler for the compiler that generates the code. Other chunks of the necessary tool chain are also absent or homegrown (no document other than source).
The best advice is to look at the installation scripts that bind secret sauce to the exposed API wrapper. Look at wrappers and install scripts for the same GPU on multiple systems if you can. Decades ago I had to be careful when debugging customer problems because depending on the graphics engine you could walk down customer code to GL library and system C and ASM code to a off the shelf digital signal processor code and then custrom processors in VHDL. The C&ASM->hardware transition was almost seamless to a reader with a good tag file and the full source. Functional symbols inside the graphics library drivers were not intended to be used except by the GL but some were too tempting and those symbols had to be edited out of shipped binary objects to clarify the ABI and keep the system stable. Ask nicely for help from the vendor. I would assert() that GO could be more useful in large clusters of GPU rich systems if facilitated. Beware bogus asserts(). On Fri, Jun 25, 2021 at 8:52 AM Nikolay Dubina <nikolay.dubina....@gmail.com> 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. > > -- > 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/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- T o m M i t c h e l l ( o n N i f t y E g g ) -- 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/CAAMy4URdwaqo-AF5-qZAS6GFEod8AF54X5uDBVAX%2BaeeTYCJBQ%40mail.gmail.com.
