ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh
!^^^^^!
That's... a bit unorthodox. FreeBSD has a `fetch`[1] utility for this, I wasn't aware NetBSD puts that in `ftp`[2].Interesting choice. I wonder what led to it.
> Build goal only: This targets compilation and linkage of the Vulkan stack. Runtime GPU acceleration is not available under VirtualBox; the software driver (Lavapipe) is the target.
I don't understand why this would ever be a problem, even without LLM assistance it's something that sounds like a weekend project?
looks inside:
> What this is NOT (yet): Running Vulkan programs
This machine is so slow that it takes a lot of time to generate ssh keys etc. We talking here hours hehe
NetBSD is known to support like 60 architectures - many of them low end embedded systems: so ftp AS A CHOICE (you have other options!) is very smart and easy
An effort to bring the Vulkan software stack (Mesa / Lavapipe) to NetBSD, and to document and automate the process so it can be reproduced and maintained.
Status: beta β Lavapipe Vulkan driver builds, installs, and registers on NetBSD
Milestone reached: Mesa configures, compiles, links, installs, and registers the Lavapipe software Vulkan driver on NetBSD 10.1 amd64, against LLVM 19.1.7. The driver (
libvulkan_lvp.so, ~17 MB) installs into/usr/pkg/lib, and its ICD manifest (advertising Vulkan API 1.4) installs into/usr/pkg/share/vulkan/icd.d/, so a Vulkan loader on the system can discover it.lddresolves every dependency cleanly. The entire process β environment setup, dependency builds, the Mesa build, and installation β is automated end to end and reproducible on a fresh install.Prebuilt binaries are coming. The tooling to build, fingerprint, and publish prebuilt artifacts is in place, and the build scripts already know how to fetch and install a matching prebuilt instead of building from source. Once a build machine is publishing releases, installing the driver will be a download rather than a multi-hour build. That's the near-term direction.
What this is NOT (yet):
- Running Vulkan programs needs the loader. This project builds and installs the Vulkan driver (the Lavapipe ICD). Actually executing a Vulkan application also requires the Vulkan loader (
libvulkan.so.1), which is the next component to bring up. Runtime execution is therefore not yet verified.- One workaround is still in place. The build applies
-Wno-error=formatto sidestep GCC rejecting Mesa's%mformat specifier on NetBSD. A proper upstreamable fix (usingstrerror(errno)) is pending.Steps, scripts, and documents will continue to change as the loader and the release pipeline come together.
NetBSD is currently the only major BSD without Vulkan support. The aim of this project is to:
vulkan-netbsd/
βββ docs/
β βββ 01-environment-setup.md Base system + pkgsrc + build deps
β βββ 02-source-dependencies.md Dependencies not in pkgsrc (built from source)
β βββ 03-mesa-build.md Configure + compile Mesa (Lavapipe); port notes
β βββ 04-prebuilt-artifacts.md Build-once / reuse prebuilt binaries
βββ scripts/
βββ setup-env.sh Automates the environment setup
βββ build-glslang.sh Builds glslang (required by Mesa; not in pkgsrc)
βββ build-mesa.sh Clones + configures + compiles Mesa (Lavapipe)
βββ install-mesa.sh Installs the built driver + ICD manifest
βββ lib-artifacts.sh Shared: fingerprint + prebuilt fetch helpers
βββ package-artifacts.sh Packages built binaries into release tarballs
On a fresh, minimal NetBSD 10.1 (amd64) install, as root:
cd /root
ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh
sh setup-env.sh
. /root/.profile
ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/build-glslang.sh
sh build-glslang.sh
ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/build-mesa.sh
sh build-mesa.sh --build
ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/install-mesa.sh
sh install-mesa.sh
build-mesa.sh --build clones, configures, and compiles Mesa, producing the
Lavapipe Vulkan driver (libvulkan_lvp.so). install-mesa.sh then installs
that driver and its ICD manifest into /usr/pkg and verifies the registration.
If a build is interrupted or the machine crashes, re-run the same command β the build scripts detect the existing build and resume automatically.
Together, these scripts take a fresh minimal install all the way to an installed, registered Vulkan software driver.
See docs/01-environment-setup.md for the full, commented walkthrough and
notes on running over SSH.
This is a personal work-in-progress. Expect churn. The documentation is written as a running record of what actually worked (and what didn't), so it doubles as field notes for anyone attempting the same port.
The original work in this repository β the scripts, documentation, and any
patches authored here β is released under the MIT License (see LICENSE).
This project builds, installs, and (optionally) redistributes third-party software that is not covered by that license and retains its own:
Prebuilt artifacts produced by scripts/package-artifacts.sh bundle the
relevant upstream license texts (under share/licenses/) so that binary
redistribution preserves each project's attribution. If you publish artifacts,
keep those files intact.
I hate to imagine what a 780 running NetBSD would be like, too.
I tried netbooting NetBSD on my MicroVAX 3400, which is about 2.5x the performance of the 780. It did, literally, take 6+ hours to slog through making RSA keys.
Exactly - I even suspected for a second that `ftp` on NetBSD is something else entirely, not an actual FTP client with HTTP/HTTPS URLs bolted on. It's not - it still accepts a host as an argument and opens a CLI if there's an FTP server to talk to.