4 ms·

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 cor

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

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