Replies: 2 comments
-
|
Some notes from other ecosystems: NixFrom what I've gleaned, NixOS puts the library for your hardware drivers under It seems like for non-NixOS systems, Nixpkgs doesn't really do anything to help out-of-the-box, so some separate tools have cropped up to help with this, like Further reading:
FlatpakFlatpak has the idea of "extensions", which I think are basically separate packages you can layer on top of a package. Then, they package the Further reading: |
Beta Was this translation helpful? Give feedback.
-
|
Maybe some examples of using system libraries would show the whole picture. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We'll need to figure out how to handle packages that use GPUs in some fashion or another, e.g. through graphics APIs like OpenGL or Vulkan, hardware-accelerated video encoding/decoding APIs like VA-API / NVENC, GPGPU APIs like CUDA/ROCm/OpenCL, and so on.
Of course, this is most important for packages at runtime, but it'd be good to understand if / how this could fit in at build time too. (Seems kinda niche, but I don't see why we shouldn't allow a (probably sandboxed) build from running a program that uses, say, CUDA).
At a high level, graphics APIs are "just" shared libraries. But I don't think we can get away with treating them like most other shared libraries. One of the most obvious points of friction is that Nvidia's official graphics driver isn't part of Mesa, unlike the drivers from Intel, AMD, and other graphics driver vendors. And realistically, even if we could just ship Mesa as-is, that would lock each installed package to a specific Mesa version, which would mean it would (probably?) need to be rebuilt e.g. to support newer hardware, or even just to get driver fixes.
So, we'll need to figure out how to handle graphics drivers in Brioche packages.
Beta Was this translation helpful? Give feedback.
All reactions