Vulkan is a lower level API than Gallium so they've had to create new abstractions at the Vulkan level. This is why the ANV (Intel) driver is what everyone copy/pasted from, there was no shared code at the Vulkan level at that point. Over time they've taken the parts people were copy/pasting and turned them into generic things all the Vulkan drivers can call instead.
Gallium is still the way everything else is implemented (OpenGL, Direct3D 9, video decoding, OpenCL) for drivers. One of those drivers is Zink which implements the Gallium OpenGL state tracker on top of Vulkan and another is D3D12 which does the same on top of Direct3D 12 (for WSL2). Not every driver supports every state tracker, in general all you can count on is some version of OpenGL to be supported (4.6 for Zink, 3.3 for D3D12).
At least 4.1 for D3D12 nowadays. Also got a sizeable perf bump.
Gallium is not used in Vulkan drivers. But Zink (OpenGL on top of Vulkan) does use Gallium, so with NVK, if you want OpenGL you can use Zink which uses Gallium.
Edit: Gallium is not only not deprecated, but it's also used by basically every GL driver withing Mesa these days.
I'm curious, how are you running SD on podman? I'm looking to build an ML rig, preferably linux, and AMD cards looked... like a hassle compared to Nvidia in my cloud GPU instance testing.
The trick is to use the PyTorch ROCm docker image (rocm/rocm-terminal) and then run with
podman run -it --rm --device=/dev/kfd --device=/dev/dri --ipc=host --group-add keep-groups --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -p 127.0.0.1:7860:7860 $(cat .sd-image.iid)
It has other wrinkles - i.e. your memory use is functionally doubled because you can't use float16's for whatever reason (seems to NaN bomb but I've not found an answer).
So it does work, but yeah, it's a hassle compared to Nvidia where you can just run things...although, I did not need to install anything special into my host environment which I believe isn't quite as true with NV.
Dockerfile I've been using lately is https://pastebin.com/BSYN8062 but I think I need to update it to incorporate the AUTOMATIC111 repo at some point.
Yeah, give it four or five years and I expect Nvidia to be as well-supported as AMD and Intel.
It took much longer than that for the AMD driver's to get to where they are today. Newer drivers get to piggyback off the work done for others (yay open source) but I think it will likely take longer than 5 years before NVK and friends are competitive with the proprietary driver.
I would love to be proven wrong though.
NVIDIA probably has north of 70% of the discrete graph card market share, so a lot more developers and users use NVIDIA cards than AMD. Probably will be much faster to reach the same state as AMD.
> Hopefully this will replace the blob in the future for Nvidia users.
Seems deeply unlikely, having read the article. quote:
> There are a few things which have changed recently to make the technical landscape a bit more friendly. The first change actually happened a few years ago when NVIDIA launched their Turing class of hardware. Turing GPUs use a new unified firmware blob. The GSP firmware contains everything needed for bringing up the GPU, and once the GSP firmware is loaded, it loads all the other firmwares needed by various pieces of the GPU. If we can get GSP working, this will allow us to use the same firmware as the proprietary NVIDIA drivers and should solve many of the mystery bugs. Dave Airlie gave a very good talk at LPC about this.
I'm not aware of any efforts to replace the firmware blob. This work is based off of a complete blob finally actually possibly being semi useful, and not some stripped-down ultra-minimal open-source blob that barely sets up anything.
It replaces the proprietary driver. People don't care about firmware.
The firmware blob is signed, so replacing it is very unlikely unless there is a security issue in the signing, but exploiting it and telling others how to exploit it would be a DMCA violation.
I mean the Vulkan implementation, not the firmware.
It will probably exist as a parallel implementation much like amdvlk-pro & radv for Radeon devices on Linux.
The AMD situation is even more complicated than that: you have both AMDGPU/AMDVLK and AMDGPU-Pro/AMDVLK-Pro. This exists in parallel to Mesa's RADV, so there are three Vulkan drivers for AMD for Linux.
I do believe that AMD actively supports the radeonsi Gallium driver in Mesa, so I don't think that AMDGPU ships with a custom OpenGL driver, but I'm not too sure on that.
AMD supports readeonsi, but they also have a proprietary OpenGL stack that's not based on llvm. I think their plan is to eventually get rid of the latter and just have a unified and open OpenGL implementation in Mesa.
The pro variant of the vulkan driver is the same as the open one, just packaged by AMD and sometimes slightly newer than what they've open sourced.
It might, but I mean for all practical purposes. Practically no one uses amdvlk / pro for Linux desktop and gaming.
The problem here is that this is just the user space driver and it's on top of nouveau, which is the not-so-ideal open source implementation based on reverse-engineering. We really need some kind of Kernel solution from Nvidia here. Maybe at some point in the near future Nvidia is going to announce a real Kernel driver and then Jason is going to magically announce he also had that as a backend for NVK which he couldn't share before :)
I also want a Pony.
I think the post mentions they are planning to refactor kernel portion.
For graphics users I think it'll happen surprisingly quick. These days I think you can get away with Docker for the userspace SDK bits like CUDA, so once there's a reasonable open source graphics stack, you'll be able to just shove everything into a container or virtual machine or whatever, I think.
Some features like vGPU/SR-IOV are segregated by product line and it's unclear how that will impact the driver/userspace stack. But that's a smaller set of users.