alt.hn

7/2/2026 at 6:36:09 PM

This is my attempt to get Vulkan going on NetBSD

 https://github.com/segaboy/vulkan-netbsd

by segaboy81

7/2/2026 at 8:19:25 PM

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?

by Tiberium

7/3/2026 at 6:56:29 AM

this is what i would recommend. hoist it over from freebsd. it works well vulkan is fully usable, mesa works nicely. Even seen people playing with CUDA tho i didnt get that workin myself yey.

by saidnooneever

7/3/2026 at 8:36:28 AM

FreeBSD relies on being able to run the Linux graphics drivers though via a compat layer.

by ChocolateGod

7/3/2026 at 11:16:13 AM

NetBSD uses the Linux graphics drivers too.

by rjsw

7/2/2026 at 8:18:08 PM

> Vulkan is now available

looks inside:

> What this is NOT (yet): Running Vulkan programs

by qiu3344

7/2/2026 at 9:16:40 PM

Technically, it isn't wrong, if you consider Vulkan the technology rather than the service

by LoganDark

7/3/2026 at 8:27:17 AM

isn't Vulkan the api?

by NooneAtAll3

7/3/2026 at 9:19:11 AM

'Vulkan' can refer to at least:

- Vulkan as a runtime service: 'the ability' for programs to do Vulkan things

- Vulkan as an API / specification: how programs interact with the service to do those things, or how the service interacts with programs

- Vulkan as a technology: how the API calls are implemented

Generally Vulkan refers to the specification much like how Linux refers to the kernel, but there is still Linux (kernel) vs Linux (syscall ABI) vs Linux (runtime service)

by LoganDark

7/2/2026 at 8:28:41 PM

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

by klibertp

7/3/2026 at 11:02:39 AM

Actually, it's orthodox; and it's fetch that isn't. FreeBSD is actually the odd one out, for having an extra tool for doing the same thing. The ftp tool in all of the BSDs, including FreeBSD, speaks HTTP, and has done since Luke Mewburn did lukemftp (later to be named tnftp) and Theo de Raadt did likewise, both based on the original 4.2BSD ftp, back in the middle 1990s.

* https://cgit.freebsd.org/src/tree/contrib/tnftp/ChangeLog#n1...

* https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ftp/main.c?...

* https://cvsweb.openbsd.org/log/src/usr.bin/ftp/main.c,v?sort...

by JdeBP

7/3/2026 at 12:38:46 PM

Nice! Thank you, that explains it. FreeBSD was my first *BSD and the only one I had long-term contact with, so I unconsciously use it as my "BSD standard". My bad on that :)

by klibertp

7/2/2026 at 10:07:03 PM

I dunno, that feels very BSD to me. Presumably, they had a ftp utility first, and then when somebody wanted to download files over http they looked around and decided that the obvious thing to do was to add it to the existing file transfer/download program. Same as continuing to add functions to ifconfig rather than inventing a new ip tool.

by yjftsjthsd-h

7/3/2026 at 9:18:30 AM

Sure, if those functions added were related to configuring network interfaces, but it would be odd if someone added functions for configuring storage controllers.

by dessimus

7/3/2026 at 12:47:11 PM

Imagine using an ftp program to transfer files.

by lmm

7/3/2026 at 6:15:41 PM

BitTorrent transfers files, so should a BT client be bolted on too? Typically the Unix philosophy has been do one thing well, not do all the things.

by dessimus

7/2/2026 at 8:37:09 PM

Oldest supported machine for NetBSD is VAX 780 from 1978(!!!). One of the first system supporting mmu, 32 bit cpu, virtual memory etc etc

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

by iberator

7/2/2026 at 9:03:27 PM

I think GP is confused why the ftp command also handles http(s) :)

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.

by spijdar

7/2/2026 at 9:14:33 PM

> I think GP is confused why the ftp command also handles http(s) :)

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.

by klibertp

7/3/2026 at 6:58:49 AM

maybe rather than protocol its program. then it all makes sense no. File Transfer Program. voila.

by saidnooneever

7/3/2026 at 12:59:35 AM

Elliptic curve key gen is much faster on slow hardware. You're waiting around on primality tests that aren't necessary with modern keys.

by kevin_thibedeau

7/3/2026 at 4:33:09 AM

Yep, it's a loooot faster. But then, when you decide to boot NetBSD on these boxes, you're not really doing it for practical reasons anyway, so part of the experience is waiting a few hours for /etc/rc.d/sshd to do its thing.

Probably more relevant on more "borderline" hosts. My SPARCstation 2 can just barely run NetBSD 10 at what I'd call "tolerable speeds" for some concept of "real work", and it's something like 50x the speed of the 780!

by spijdar

7/3/2026 at 6:48:52 AM

Easier with SIMH.

by anthk

7/2/2026 at 8:17:12 PM

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.

by wbolt

7/2/2026 at 8:26:30 PM

I expected this to be official from the title but it doesn’t seem to be.

by MBCook

7/2/2026 at 7:39:27 PM

There are already Vulkan components in pkgsrc and wip.

by rjsw

7/3/2026 at 1:11:31 AM

Which ones? I'm asking, because I wouldn't have done anything at all if this was pre-existing.

by segaboy81

7/3/2026 at 11:16:58 AM

See graphics/MesaLib.

by rjsw

7/2/2026 at 8:44:48 PM

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.

by iamnothere

7/2/2026 at 8:54:12 PM

NetBSD already has relevant packages officially.

by Tiberium

7/3/2026 at 1:12:18 AM

Which packages? I couldn't find what I needed, and that's the whole reason for building all this.

by segaboy81

7/2/2026 at 9:17:04 PM

Lavapipe? So it's just Mesa software rendering stuff

by spiral09

7/3/2026 at 1:12:56 AM

That's the start. The idea is to get Vulkan running first. More to follow.

by segaboy81

7/3/2026 at 7:09:03 AM

I think both points are valid; that is the sensible way to start, but it's worth noting that the work is early so people don't misunderstand the current state of things.

by yjftsjthsd-h

7/3/2026 at 6:50:25 AM

Didn't modular-xorg, MESA and DRM drivers handle this?

by anthk

7/3/2026 at 12:49:35 PM

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.

by sylware

7/3/2026 at 8:10:32 AM

This is 100% AI slop.

by rvz