6 ms·

NVK is now ready for prime time

141 points by jalict 3y ago

jsheard 3y ago
It would be helpful to see a https://vulkan.gpuinfo.org https://vulkan.gpuinfo.org dump for the current version of NVK, reaching conformance with Vulkan 1.3 core is an important milestone but Vulkan has an enormous number of optional features which a conformant implementation technically doesn't have to support, and in practice Vulkan applications usually don't bother to target core as a baseline, especially on desktop where there's a massive gulf between what core requires and what the hardware can actually do.
- ChocolateGod 3y ago
  I think you can use https://mesamatrix.net/ https://mesamatrix.net/ for that information https://mesamatrix.net/#ExtensionsthatarenotpartofanyVulkanversion_Extensions https://mesamatrix.net/#ExtensionsthatarenotpartofanyVulkanv...
  - jsheard 3y ago
    Those extensions are part of it, but to get the full picture you also need to see the features and limits. E.g. an extension may gate its functionality behind feature flags, so a conformant implementation of the extension may just be a stub that says "feature not supported", or only support a subset of the extensions functionality. Yes it's convoluted, that's Vulkan in a nutshell.
    - cogman10 3y ago
      That's annoying. Sounds like vulkan stumbled into exactly the same problem opengl had. There was the core, then a maze of vendor features and extensions differently supported.
      - deleted 3y ago
        [deleted]
      - jsheard 3y ago
        The feature maze isn't too bad if you only care about running on modern-ish AMD and Nvidia hardware with their official drivers, most things you'd typically want are implemented in portable extensions supported by both, but god help you if you're writing Vulkan for mobile.
- pjmlp 3y ago
  Yeah, it is OpenGL spaghetti all over again, where it is hardly an improvement versus having a pluggable backend for specific APIs, thus the irony of having a pluggable backend for Vulkan flavours. EDIT: typo added APIs and backed
  - jsheard 3y ago
    Trying to make Vulkan a single API that covers everything from low-end mobile to high-end desktop was probably a mistake, in practice it has split into wildly distinct dialects for low-end and high-end targets anyway. Maybe one day we'll get a Vulkan 2.0 which ratchets up the mandatory baseline hardware features to something reasonably modern and removes all the API cruft needed to accommodate less capable hardware.
    - pjmlp 3y ago
      Even the way the profiles got introduced, I must think it was a joke on us. Instead of dealing with specific API settings, like in proprietary APIs, there is the expectation to generate JSON configurations, parse them, generate code calling the profile API to configure the desired profile. At Vulkanised 2024 there is a 1h long session on how to use them. Really? Who got to design that?
      - dyingkneepad 3y ago
        > Really? Who got to design that? A committee, of course :) :) :) :) :)
    - exDM69 3y ago
      In hindsight, adding the RenderPass API to in Vulkan 1.0 support mobile chips was probably a mistake. Vulkan 1.3 without render passes ("dynamic rendering") is so much easier, it reduces hundreds if not thousands of lines of code from the boilerplate code required to draw a triangle. And it gets even better in a practical project because you'd need to set up new render passes up front for every new thing you add. Mobile vendors are catching up and providing means of getting advantage of tiler GPUs without the old verbose render pass API, but it's not there yet. And it'll take a while until mobile drivers propagate to the hands of consumers. What's desperately needed is a way for compute shaders to read on-chip tile memory like Metal Tile shaders on macos/ios. That would finally bridge the gap, getting rid of the render pass mess altogether and provide a way to get the best perf on mobile chips without having to write a whole separate path for compositing/deferred lighting etc. Because currently you get the best perf on desktop with compute shaders but mobile requires you to use fragment shaders to benefit from tile memory. That said, Vulkan 1.3 is a massive improvement over 1.0. I don't see a benefit in making a version 2.0 that's incompatible with 1.x, because it's not like vendors could stop shipping 1.x due to all the content using it out there.
- gfxstrand 3y ago
  Here you go! I just uploaded results from latest mesa/main on my RTX 4060 laptop GPU. Happy comparing! https://vulkan.gpuinfo.org/displayreport.php?id=28783 https://vulkan.gpuinfo.org/displayreport.php?id=28783
FL33TW00D 3y ago
Related talk from the author: https://www.youtube.com/watch?v=Au0-HA2tm_4 https://www.youtube.com/watch?v=Au0-HA2tm_4
logicprog 3y ago
This is honestly pretty huge. I'm hoping this will seriously improve the Nvidia situation on the linux desktop in the long run! I'll probably always need the proprietary driver for cuda though
saidinesh5 3y ago
Is this work only for Desktop GPUs or would this work well for laptops too? Especially ones with optimus/whatever they have these days...
- gfxstrand 3y ago
  I'm running it on my optimus laptop now. There have been some funky bugs with mixed GPU systems but things are mostly working these days if you have a new enough kernel.
aidenn0 3y ago
> As of today NVK is now a conformant Vulkan 1.3 implementation on Turing (RTX 2000 and GTX 1600 series), Ampere (RTX 3000 series), and Ada (RTX 4000 series) GPUs Looking sadly at my Pascal GPU
shmerl 3y ago
Congrats to Mesa developers and Linux gamers who are still stuck with Nvidia hardware. That's a big milestone!
- gfxstrand 3y ago
  Thanks!
viraptor 3y ago
I fell behind on the progress here. Could someone explain: - does the nouveau driver these days allow enabling higher power/speed? - how would I switch between the OpenGL and Zink implementations when running an app today?
- bcrescimanno 3y ago
  > does the nouveau driver these days allow enabling higher power/speed? My understanding is that, yes, with the Nouveau GSP code in Kernel 6.7. https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7 https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7
- dyingkneepad 3y ago
  > - how would I switch between the OpenGL and Zink implementations when running an app today? There are environment variables to control this. Or you just install one driver. Usually Zink is cool when you don't have an OpenGL driver for a specific hardware. You write a Vulkan driver and then Zink is a GL implementation that uses Vulkan.
Animats 3y ago
Does this mean Wayland will finally work right on NVidia hardware?
- samus 3y ago
  Wayland is working fine with NVidia hardware for quite a while now, even with the proprietary driver.
doctorpangloss 3y ago
Who is the audience for a driver option for an NVIDIA GPU that isn’t the officially supported one from NVIDIA?

141 points by jalict 3y ago

It would be helpful to see a https://vulkan.gpuinfo.org https://vulkan.gpuinfo.org dump for the current version of NVK, reaching conformance with Vulkan 1.3 core is an important milestone but Vulkan has an enormous number of optional features which a conformant implementation technically doesn't have to support, and in practice Vulkan applications usually don't bother to target core as a baseline, especially on desktop where there's a massive gulf between what core requires and what the hardware can actually do.

ChocolateGod 3y ago
I think you can use https://mesamatrix.net/ https://mesamatrix.net/ for that information https://mesamatrix.net/#ExtensionsthatarenotpartofanyVulkanversion_Extensions https://mesamatrix.net/#ExtensionsthatarenotpartofanyVulkanv...
- jsheard 3y ago
  Those extensions are part of it, but to get the full picture you also need to see the features and limits. E.g. an extension may gate its functionality behind feature flags, so a conformant implementation of the extension may just be a stub that says "feature not supported", or only support a subset of the extensions functionality. Yes it's convoluted, that's Vulkan in a nutshell.
  - cogman10 3y ago
    That's annoying. Sounds like vulkan stumbled into exactly the same problem opengl had. There was the core, then a maze of vendor features and extensions differently supported.
    - deleted 3y ago
      [deleted]
    - jsheard 3y ago
      The feature maze isn't too bad if you only care about running on modern-ish AMD and Nvidia hardware with their official drivers, most things you'd typically want are implemented in portable extensions supported by both, but god help you if you're writing Vulkan for mobile.
pjmlp 3y ago
Yeah, it is OpenGL spaghetti all over again, where it is hardly an improvement versus having a pluggable backend for specific APIs, thus the irony of having a pluggable backend for Vulkan flavours. EDIT: typo added APIs and backed
- jsheard 3y ago
  Trying to make Vulkan a single API that covers everything from low-end mobile to high-end desktop was probably a mistake, in practice it has split into wildly distinct dialects for low-end and high-end targets anyway. Maybe one day we'll get a Vulkan 2.0 which ratchets up the mandatory baseline hardware features to something reasonably modern and removes all the API cruft needed to accommodate less capable hardware.
  - pjmlp 3y ago
    Even the way the profiles got introduced, I must think it was a joke on us. Instead of dealing with specific API settings, like in proprietary APIs, there is the expectation to generate JSON configurations, parse them, generate code calling the profile API to configure the desired profile. At Vulkanised 2024 there is a 1h long session on how to use them. Really? Who got to design that?
    - dyingkneepad 3y ago
      > Really? Who got to design that? A committee, of course :) :) :) :) :)
  - exDM69 3y ago
    In hindsight, adding the RenderPass API to in Vulkan 1.0 support mobile chips was probably a mistake. Vulkan 1.3 without render passes ("dynamic rendering") is so much easier, it reduces hundreds if not thousands of lines of code from the boilerplate code required to draw a triangle. And it gets even better in a practical project because you'd need to set up new render passes up front for every new thing you add. Mobile vendors are catching up and providing means of getting advantage of tiler GPUs without the old verbose render pass API, but it's not there yet. And it'll take a while until mobile drivers propagate to the hands of consumers. What's desperately needed is a way for compute shaders to read on-chip tile memory like Metal Tile shaders on macos/ios. That would finally bridge the gap, getting rid of the render pass mess altogether and provide a way to get the best perf on mobile chips without having to write a whole separate path for compositing/deferred lighting etc. Because currently you get the best perf on desktop with compute shaders but mobile requires you to use fragment shaders to benefit from tile memory. That said, Vulkan 1.3 is a massive improvement over 1.0. I don't see a benefit in making a version 2.0 that's incompatible with 1.x, because it's not like vendors could stop shipping 1.x due to all the content using it out there.
gfxstrand 3y ago
Here you go! I just uploaded results from latest mesa/main on my RTX 4060 laptop GPU. Happy comparing! https://vulkan.gpuinfo.org/displayreport.php?id=28783 https://vulkan.gpuinfo.org/displayreport.php?id=28783

FL33TW00D 3y ago

Related talk from the author: https://www.youtube.com/watch?v=Au0-HA2tm_4 https://www.youtube.com/watch?v=Au0-HA2tm_4

logicprog 3y ago

This is honestly pretty huge. I'm hoping this will seriously improve the Nvidia situation on the linux desktop in the long run! I'll probably always need the proprietary driver for cuda though

saidinesh5 3y ago

Is this work only for Desktop GPUs or would this work well for laptops too? Especially ones with optimus/whatever they have these days...

gfxstrand 3y ago
I'm running it on my optimus laptop now. There have been some funky bugs with mixed GPU systems but things are mostly working these days if you have a new enough kernel.

aidenn0 3y ago

> As of today NVK is now a conformant Vulkan 1.3 implementation on Turing (RTX 2000 and GTX 1600 series), Ampere (RTX 3000 series), and Ada (RTX 4000 series) GPUs Looking sadly at my Pascal GPU

shmerl 3y ago

Congrats to Mesa developers and Linux gamers who are still stuck with Nvidia hardware. That's a big milestone!

gfxstrand 3y ago
Thanks!

viraptor 3y ago

I fell behind on the progress here. Could someone explain: - does the nouveau driver these days allow enabling higher power/speed? - how would I switch between the OpenGL and Zink implementations when running an app today?

bcrescimanno 3y ago
> does the nouveau driver these days allow enabling higher power/speed? My understanding is that, yes, with the Nouveau GSP code in Kernel 6.7. https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7 https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7
dyingkneepad 3y ago
> - how would I switch between the OpenGL and Zink implementations when running an app today? There are environment variables to control this. Or you just install one driver. Usually Zink is cool when you don't have an OpenGL driver for a specific hardware. You write a Vulkan driver and then Zink is a GL implementation that uses Vulkan.

Animats 3y ago

Does this mean Wayland will finally work right on NVidia hardware?

samus 3y ago
Wayland is working fine with NVidia hardware for quite a while now, even with the proprietary driver.

doctorpangloss 3y ago

Who is the audience for a driver option for an NVIDIA GPU that isn’t the officially supported one from NVIDIA?