CUDA for bare metal hardware


If I don’t want to use Linux on Jetson Tx2, instead run bare metal software on TX2, How to use CUDA on it? Is CUDA avaialble as a C/C+ source code to accelerate CV, DL software on TX2?

The GPU drivers do not have source code available. The binary driver is tied to the particular X11 ABI version (people think of X as graphics, but what it really is is an interface to GPU functions…this includes CUDA). So you’d need to port that particular ABI of X11 to run bare metal…I hate to imagine the effort required to do that. (Btw, this is the TX1 forum, but the answer would be the same on either a TX1 or TX2)

Are there some links or documentation on how to port a particular ABI of X11 to run bare metal? Where should I start reading about ABI and X11?

The X11 implementation is from This would list many things. You would want to look in the “/var/log/Xorg.0.log” of a running Jetson and note the ABI comments, then cross-reference that ABI.

There will be almost no information on porting this to bare metal. Bare metal itself is quite different than a system with support, e.g., you may end up doing memory allocation manually for things which would be automatic in a real environment (e.g., local variables). Almost every aspect of C which makes it a higher level language (at least from the convenience point of view) is a function of the operating system. Your goal would be to take existing code and simply make it work on bare metal…but imagine all of the support X gets in Linux…if you need to link to some function in libc, then you need to statically port that libc function to your app in bare metal as well.

An example to consider: On my desktop PC the real Xorg executable is in “/usr/libexec/Xorg”. I can see what is linked dynamically via “ldd /usr/libexec/Xorg”. I see these libraries are provided by the linker, and expect all of them would need to be ported to get X running on bare metal without linker support:

> ldd Xorg (0x00007fffa8fcf000) => /lib64/ (0x00007faa35b4a000) => /lib64/ (0x00007faa35b27000) => /lib64/ (0x00007faa358ff000) => /lib64/ (0x00007faa35474000) => /lib64/ (0x00007faa35270000) => /lib64/ (0x00007faa35054000) => /lib64/ (0x00007faa34e4b000) => /lib64/ (0x00007faa34c3a000) => /lib64/ (0x00007faa34995000) => /lib64/ (0x00007faa34766000) => /lib64/ (0x00007faa34562000) => /lib64/ (0x00007faa344d5000) => /lib64/ (0x00007faa342d3000) => /lib64/ (0x00007faa340cd000) => /lib64/ (0x00007faa33ea5000) => /lib64/ (0x00007faa33b8f000) => /lib64/ (0x00007faa33970000) => /lib64/ (0x00007faa3359d000) => /lib64/ (0x00007faa33384000) => /lib64/ (0x00007faa3317f000) => /lib64/ (0x00007faa32f77000) => /lib64/ (0x00007faa32d60000)
        /lib64/ (0x000056208610a000) => /lib64/ (0x00007faa32aee000) => /lib64/ (0x00007faa328d5000) => /lib64/ (0x00007faa326ce000) => /lib64/ (0x00007faa3241e000) => /lib64/ (0x00007faa321f8000) => /lib64/ (0x00007faa31fe4000) => /lib64/ (0x00007faa31cd6000) => /lib64/ (0x00007faa31ac0000) => /lib64/ (0x00007faa318bb000) => /lib64/ (0x00007faa316ab000) => /lib64/ (0x00007faa31478000)

That’s a lot! Now consider that if you run ldd on each of those libraries, it is probable that these too will have dependencies which need to be brought into an environment not supporting a linker.

If you have a use-case scenario leading to wanting this, then someone may have another idea. If going bare metal porting it is going to be a long project.