4 ms·

Nice. Hopefully this will replace the blob in the future for Nvidia users.

by shmerl 4y ago

robert_foss 4y ago
It will probably exist as a parallel implementation much like amdvlk-pro & radv for Radeon devices on Linux.
- ColonelPhantom 4y ago
  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.
  - shmerl 4y ago
    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.
  - TingPing 4y ago
    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.
    - shmerl 4y ago
      I think their shader compiler in amdvkl-pro is different, it's not using llvm unlike amdvlk (open).
    - ColonelPhantom 4y ago
      That's not quite true, the other commenter already mentioned LLVM vs. AMD's proprietary shader compiler, and I think ray-tracing support has also been present in the AMDGPU-PRO driver for quite a while but is only just now starting to appear in the open AMDVLK.
      - my123 4y ago
        Note also some sizeable perf differences between AMDGPU-PRO and AMDVLK. The raytracing impl for example is just not the same. https://www.phoronix.net/image.php?id=2022&image=radv_rt_performance https://www.phoronix.net/image.php?id=2022&image=radv_rt_per...
- shmerl 4y ago
  It might, but I mean for all practical purposes. Practically no one uses amdvlk / pro for Linux desktop and gaming.
rektide 4y ago
> 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.
- wmf 4y ago
  It replaces the proprietary driver. People don't care about firmware.
- pabs3 4y ago
  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.
- shmerl 4y ago
  I mean the Vulkan implementation, not the firmware.
aseipp 4y ago
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.
dyingkneepad 4y ago
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.
- shmerl 4y ago
  I think the post mentions they are planning to refactor kernel portion.

Nice. Hopefully this will replace the blob in the future for Nvidia users.

by shmerl 4y ago

Nice. Hopefully this will replace the blob in the future for Nvidia users.

robert_foss 4y ago

It will probably exist as a parallel implementation much like amdvlk-pro & radv for Radeon devices on Linux.

ColonelPhantom 4y ago
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.
- shmerl 4y ago
  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.
- TingPing 4y ago
  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.
  - shmerl 4y ago
    I think their shader compiler in amdvkl-pro is different, it's not using llvm unlike amdvlk (open).
  - ColonelPhantom 4y ago
    That's not quite true, the other commenter already mentioned LLVM vs. AMD's proprietary shader compiler, and I think ray-tracing support has also been present in the AMDGPU-PRO driver for quite a while but is only just now starting to appear in the open AMDVLK.
    - my123 4y ago
      Note also some sizeable perf differences between AMDGPU-PRO and AMDVLK. The raytracing impl for example is just not the same. https://www.phoronix.net/image.php?id=2022&image=radv_rt_performance https://www.phoronix.net/image.php?id=2022&image=radv_rt_per...
shmerl 4y ago
It might, but I mean for all practical purposes. Practically no one uses amdvlk / pro for Linux desktop and gaming.

rektide 4y ago

> 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.

wmf 4y ago
It replaces the proprietary driver. People don't care about firmware.
pabs3 4y ago
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.
shmerl 4y ago
I mean the Vulkan implementation, not the firmware.

aseipp 4y ago

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.

dyingkneepad 4y ago

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.

shmerl 4y ago
I think the post mentions they are planning to refactor kernel portion.