7 ms·

This is my attempt to get Vulkan going on NetBSD

121 points by segaboy81 3mo ago

rjsw 3mo ago
There are already Vulkan components in pkgsrc and wip.
- segaboy81 3mo ago
  Which ones? I'm asking, because I wouldn't have done anything at all if this was pre-existing.
  - rjsw 3mo ago
    See graphics/MesaLib.
wbolt 3mo ago
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.
- deleted 3mo ago
  [deleted]
qiu3344 3mo ago
> Vulkan is now available looks inside: > What this is NOT (yet): Running Vulkan programs
- LoganDark 3mo ago
  Technically, it isn't wrong, if you consider Vulkan the technology rather than the service
  - NooneAtAll3 3mo ago
    isn't Vulkan the api?
    - LoganDark 3mo ago
      '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)
Tiberium 3mo ago
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?
- saidnooneever 3mo ago
  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.
  - ChocolateGod 3mo ago
    FreeBSD relies on being able to run the Linux graphics drivers though via a compat layer.
    - rjsw 3mo ago
      NetBSD uses the Linux graphics drivers too.
MBCook 3mo ago
I expected this to be official from the title but it doesn’t seem to be.
klibertp 3mo ago
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 https://man.freebsd.org/cgi/man.cgi?fetch [2] https://man.netbsd.org/ftp.1 https://man.netbsd.org/ftp.1
- iberator 3mo ago
  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
  - spijdar 3mo ago
    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.
    - kevin_thibedeau 3mo ago
      Elliptic curve key gen is much faster on slow hardware. You're waiting around on primality tests that aren't necessary with modern keys.
      - spijdar 3mo ago
        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!
iamnothere 3mo ago
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.
- Tiberium 3mo ago
  NetBSD already has relevant packages officially.
  - segaboy81 3mo ago
    Which packages? I couldn't find what I needed, and that's the whole reason for building all this.
spiral09 3mo ago
Lavapipe? So it's just Mesa software rendering stuff
- segaboy81 3mo ago
  That's the start. The idea is to get Vulkan running first. More to follow.
  - yjftsjthsd-h 3mo ago
    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.
anthk 3mo ago
Didn't modular-xorg, MESA and DRM drivers handle this?
rvz 3mo ago
This is 100% AI slop.
sylware 3mo ago
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.

121 points by segaboy81 3mo ago

rjsw 3mo ago

There are already Vulkan components in pkgsrc and wip.

segaboy81 3mo ago
Which ones? I'm asking, because I wouldn't have done anything at all if this was pre-existing.
- rjsw 3mo ago
  See graphics/MesaLib.

wbolt 3mo ago

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.

deleted 3mo ago
[deleted]

qiu3344 3mo ago

> Vulkan is now available looks inside: > What this is NOT (yet): Running Vulkan programs

LoganDark 3mo ago
Technically, it isn't wrong, if you consider Vulkan the technology rather than the service
- NooneAtAll3 3mo ago
  isn't Vulkan the api?
  - LoganDark 3mo ago
    '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)

Tiberium 3mo ago

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?

saidnooneever 3mo ago
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.
- ChocolateGod 3mo ago
  FreeBSD relies on being able to run the Linux graphics drivers though via a compat layer.
  - rjsw 3mo ago
    NetBSD uses the Linux graphics drivers too.

MBCook 3mo ago

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

klibertp 3mo ago

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 https://man.freebsd.org/cgi/man.cgi?fetch [2] https://man.netbsd.org/ftp.1 https://man.netbsd.org/ftp.1

iberator 3mo ago
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
- spijdar 3mo ago
  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.
  - kevin_thibedeau 3mo ago
    Elliptic curve key gen is much faster on slow hardware. You're waiting around on primality tests that aren't necessary with modern keys.
    - spijdar 3mo ago
      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!

iamnothere 3mo ago

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.

Tiberium 3mo ago
NetBSD already has relevant packages officially.
- segaboy81 3mo ago
  Which packages? I couldn't find what I needed, and that's the whole reason for building all this.

spiral09 3mo ago

Lavapipe? So it's just Mesa software rendering stuff

segaboy81 3mo ago
That's the start. The idea is to get Vulkan running first. More to follow.
- yjftsjthsd-h 3mo ago
  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.

anthk 3mo ago

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

rvz 3mo ago

This is 100% AI slop.

sylware 3mo ago

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.