- Lavapipe is CPU rendering, it doesn't really prove much. But also, Vulkan on BSDs is totally possible and isn't something esoteric, FreeBSD has 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?
- > Vulkan is now available
looks inside:
> What this is NOT (yet): Running Vulkan programs
- Installation instructions:
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.
[1] https://man.freebsd.org/cgi/man.cgi?fetch
[2] https://man.netbsd.org/ftp.1
- This is a nice project but looks like is either AI written or AI assisted and I haven’t seen mention of that in any of the docs.
- Didn't modular-xorg, MESA and DRM drivers handle this?
- I expected this to be official from the title but it doesn’t seem to be.
- There are already Vulkan components in pkgsrc and wip.
by iamnothere
1 subcomments
- I have never had a need for NetBSD, but in case I ever do, I’m glad it’s there. Especially with Linux deprecating old platforms.
This looks like an unofficial effort but hopefully it gets refined and integrated.
- Lavapipe? So it's just Mesa software rendering stuff
- The vulkan stack is rather lean (there are still c++ though, valve removed a lot of c++ for less c++, it would have been correct with plain and simple C).
The big chunk is DRM kernel code.
AMD seems to be working on _userland_ hardware command ring buffers, which should makes userland vulkan even simpler. Dunno how they will work around the VMID stuff though.
- This is 100% AI slop.