Hello
I’m working towards a demo/prototype that will give us more information about how to proceed with openGL/openCL/Vulkcan/vdapu/cuda runtimes so that snap applications can benefit from drivers that were created after the instant the snap application was made.
Currently snapd contains a bit of code for special support of the NVIDIA user space libraries provided by the host. The system is fragile and complex and only works with NVIDIA. We’d like to expand that to something more generic while making it simpler to support at the same time.
I’ve been conducting some research over the past few days and I’d like to share my straw man plans.
GPU Support Proposal
- snapd team makes two prototype snaps
snapd-nvidia-418
andsnapd-core18-mesa
for the amd64 architecture- later on: additional NVIDIA driver versions
- later on: support for
i386
architecture - later on: support for
core16
- later on: support for Wayland
- later on: support for Radeon Pro drivers via
snapd-core18-amdpro
- prototypes provide
gpu-support
slot with the following directories:-
opengl-runtime
- this shipslibGL.so
and dependencies -
opencl-runtime
- TBD -
vdapu-runtime
- TBD -
vulcan-runtime
- TBD -
cuda-runtime
(nvidia
-specific) - TBD - libraries common across this set should be placed in a dedicated directory
-
- snapd probes presence of loaded
nvidia
kernel driver- no need to handle PCI IDs or ask the store for anything
- the host system provides the kernel driver and udev rules
- snapd installs either
snapd-nvidia-418
orsnapd-core18-mesa
- cooperating application snaps provide
gpu-support
plug- snaps using classic confinement are not supported yet
- when disconnected bundled libraries are used, like today
- when disconnected NVIDIA from the host works like today
- when connected startup logic orders
LD_LIBRARY_PATH
fromgpu-support
connection ahead of$SNAP_LIBRARY_PATH
and internal bundled libraries.
Supporting research:
- CUDA: Hello World CUDA Analysis
- OpenGL: in progress