[HN Gopher] Introducing NVK
___________________________________________________________________
Introducing NVK
Author : phire
Score : 90 points
Date : 2022-10-04 16:24 UTC (6 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| homarp wrote:
| NVK is a new open source Mesa Vulkan driver for NVIDIA GPUs,
| written almost entirely from scratch using the new official
| headers from NVIDIA.
| tomcam wrote:
| Ah... relief. Thank you.
| Vt71fcAqt7 wrote:
| I think the idea of using Zink instead of rewriting OpenGL
| drivers is a good idea. Semantically it makes sense because
| Vulkan is much more low level. They really shouldn't be compiling
| to the same depth. Just like how the android runtime/open JDK is
| written in c and c++. The performance of Zink has been pretty
| good, although as mentioned it requires more of the vulkan spec
| to be implemented before using it. Better to use that time
| imrpoving the vulkan driver.
| neogodless wrote:
| Off Topic: I did a double take and thought I had opened the
| article in a Private Window in Firefox. But no, that's the
| Collabora logo!
| shmerl wrote:
| Nice. Hopefully this will replace the blob in the future for
| Nvidia users.
| aseipp wrote:
| 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.
| rektide wrote:
| > _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 wrote:
| It replaces the proprietary driver. People don't care about
| firmware.
| robert_foss wrote:
| It will probably exist as a parallel implementation much like
| amdvlk-pro & radv for Radeon devices on Linux.
| shmerl wrote:
| It might, but I mean for all practical purposes. Practically
| no one uses amdvlk / pro for Linux desktop and gaming.
| ColonelPhantom wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ColonelPhantom wrote:
| 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.
| shmerl wrote:
| I think their shader compiler in amdvkl-pro is different,
| it's not using llvm unlike amdvlk (open).
| [deleted]
| pedrocr wrote:
| Is gallium now deprecated within Mesa? The way this post is
| written it seems that way but I could swear I had read a similar
| post recently about other hardware in mesa leveraging gallium to
| get to a working driver faster.
| mikessoft_gmail wrote:
| mikessoft_gmail wrote:
___________________________________________________________________
(page generated 2022-10-04 23:00 UTC)