I know that JetPack installs CUDA 9.0, VisionWorks 1.6 & OpenCV 3.3.1 on the Host PC but it doesn’t install cuDNN or TensorRT. Is there a way to keep your Host PC in lockstep with what JetPack 3.3 has deployed to my TX1? I’d much rather do all development work locally on my PC than directly on the TX1.
Or are folks deploying docker containers to get around software/library version differences?
You might consider cloning your Jetson’s rootfs, and the loopback mounting it (perhaps read-only) on your PC (it’s good to have a backup reference copy anyway). See: http://elinux.org/Jetson/TX1_Cloning
There are still packages you’d need to install on the host, e.g., the cross-compiler and cross-architecture linker, but the part which is most difficult (the millions of libraries and headers) can be done via a clone and symbolic links.
On a desktop PC you will find that typically the native architecture libs will be in “/usr/lib/”, and any compatibility version (such as 32-bit) has a named subdirectory (e.g., “/usr/lib/i686/”). The same is true with any foreign architecture, so a cross-compile tool (or compatibility mode library) might install “/usr/lib/aarch64-linux-gnu/”. If you have installed all of the dev packages on your Jetson to make it possible to work natively on the Jetson, then (with some experimentation) you can loopback mount this on your host PC and add symbolic links which point to the clone directories.
If you’ve made an update to a Jetson, then a previous clone which is loopback mounted (read-write) on the host can be updated with rsync and the clone will be an exact match of the Jetson even after that update.
NOTE: Cloning provides both a “sparse” clone (".img") and a “raw” clone (".img.raw"). You can throw away the sparse image, it is the raw image which you can update or loopback mount.
Do you think there’s any value in using the created *.img.raw to create a docker image and developing locally using that image via QEMU/KVM to emulate aarch64 and then using CI/CD to update the docker image(s) on the Jetson?
I don’t use docker, so I can’t give too much useful information. If you were to use docker though, then that image would be worth its weight in gold should you get it to work and if the clone was from a Jetson loaded with all of the updates and dev packages. Changes to the actual Jetson could use rsync to update the image…or the reverse, rsync could update the Jetson from the image. On the other hand, I have no idea what issues you would run into.