5 ms·

In true Vulkan fashion, this feature which was announced for DirectX a year ago and is now shipping hasn't even been publicly acknowledged by Khronos yet :( I'

In true Vulkan fashion, this feature which was announced for DirectX a year ago and is now shipping hasn't even been publicly acknowledged by Khronos yet :( I'm sure they're working on it, but the slower pace imposed by the much bigger committee including the mobile GPU vendors is a drag for those who only care about high performance hardware, and in the end their version usually ends up mirroring the design of the DirectX version anyway.

mananaysiempre 2y ago
At the very least AMD made an extension pretty much immediately[1,2]. NVidia... well I don’t really expect graphics-programming-friendly initiatives from NVidia at this point. [1] https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/ [2] https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_AMDX_shader_enqueue.adoc https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...
- deleted 2y ago
  [deleted]
- pjmlp 2y ago
  Wrong there, as Slang is the only sane alternative to a stagnant GLSL, unless you favour using DirectX HLSL.
- creata 2y ago
  As far as I can tell, AMD's extension is supported by exactly one version of AMD's driver, and it's outdated and only on Windows. https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_AMDX_shader_enqueue&platform=all https://vulkan.gpuinfo.org/listdevicescoverage.php?extension... https://github.com/KhronosGroup/Vulkan-Docs/issues/2336 https://github.com/KhronosGroup/Vulkan-Docs/issues/2336 https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-VLK-23-10-01-43.html https://www.amd.com/en/resources/support-articles/release-no...
- my123 2y ago
  VK_NV_device_generated_commands(_compute), which is already implemented by RADV in Mesa, and is much older than VK_AMDX_shader_enqueue. The X suffix means that it's not a stable API and should not be used by shipped code.
  - creata 2y ago
    So are the concerns regarding VK_NV_generated_commmands (mainly, unnecessary latency) in the VK_AMDX_shader_enqueue proposal overstated?
    - my123 2y ago
      It comes with a lot of flexibility that the equivalent AMDX extension doesn't have, including being able to queue graphics shaders, not compute ones only. As far as I can see, unnecessary latency isn't actually a problem.
Lichtso 2y ago
It is true that Vulkan usually is behind DirectX by two to three years, but it gets there eventually. Keep in mind that Vulkan tries to cover a wider range of devices and platforms. Also, in my experience as a contributor to GPU HALs, Vulkan is far more thought-out while DirectX is usually a ship-quickly mess. Vulkan obviously benefits from hindsight here.
pjmlp 2y ago
Vulkan hasn't changed anything in way Khronos works. It is still extension spaghetti, multiple code paths working across extensions and driver bugs. "Make your own SDK" kind of approach, which isn't as bad as OpenGL, only because they at least pay LunarG to make one. But good luck with Android tooling for Vulkan on the NDK, other than a github repo full of samples. A stagnant GLSL, hence why HLSL is now the de factor extension language for most studios, not only due to DirectX, with NVidia's Slang as a close second place.
- dagmx 2y ago
  Are game studios actually using Slang? I haven’t really seen anyone at GDC or Siggraph mention it outside of a couple projects like Autodesk’s Aurora use it, which itself is very nascent.
  - pjmlp 2y ago
    Most game studios are naturally using HLSL, or variations thereof. However that isn't the only reason for Vulkan's existence, and NVidia was proposing Slang at Vulkanised 2024.
    - dagmx 2y ago
      Ah yeah, but NVIDIA have been pushing Slang as a solution for a bit. It’ll be interesting to see if there will be any takers for production use. Even within NVIDIA, they seem to have a constant battle between MDL, Slang and MaterialX.
DonHopkins 2y ago
Sounds like a modern more general version of ActiveMovie aka DirectShow Filter Graphs, from 1996. https://learn.microsoft.com/en-us/windows/win32/directshow/the-filter-graph-and-its-components https://learn.microsoft.com/en-us/windows/win32/directshow/t... The whole point of filter graphs was that it would cleverly try to choose filter implementations based on their wishy-washily defined "merits", depending on what filters and codecs were currently installed, in a way that minimized copying data between the CPU and the video card (pre-modern-programmable-GPUs, mainly video cards with multimedia stream splitting/combining/compressing/decompressing/filtering/rendering and other forms of acceleration). It introduced the term "Codec Hell", an even deeper layer of "DLL Hell": https://en.wikipedia.org/wiki/DirectShow#Codec_hell https://en.wikipedia.org/wiki/DirectShow#Codec_hell >Codec hell (a term derived from DLL hell) is when multiple DirectShow filters conflict for performing the same task. A large number of companies now develop codecs in the form of DirectShow filters, resulting in the presence of several filters that can decode the same media type. This issue is further exacerbated by DirectShow's merit system, where filter implementations end up competing with one another by registering themselves with increasingly elevated priority. >Microsoft's Ted Youmans explained that "DirectShow was based on the merit system, with the idea being that, using a combination of the filter’s merit and how specific the media type/sub type is, one could reasonably pick the right codec every time. It wasn't really designed for a competing merit nuclear arms race." >A tool to help in the troubleshooting of "codec hell" issues usually referenced is the GSpot Codec Information Appliance, which can be useful in determining what codec is used to render video files in AVI and other containers. GraphEdit can also help understanding the sequence of filters that DirectShow is using to render the media file. Codec hell can be resolved by manually building filter graphs, using a media player that supports ignoring or overriding filter merits, or by using a filter manager that changes filter merits in the Windows Registry.
- ack_complete 2y ago
  It is a lot more constrained than DirectShow graph building. DirectShow has many characteristics that make its graph building fragile: - It allows for fuzzy rules to choose filters, which often overlap and require prioritization. - It runs code in the filters themselves as part of the decision process. This leads to apps breaking when filters are installed that have broken input logic and inject themselves everywhere or reject connections for obscure reasons (e.g. allocator requirements). - It often needs to build a telescope of multiple filters to complete a requested connection, such as a decompression codec followed by a Color Space Converter. This makes it vulnerable to filter loops and horribly inefficient conversion paths (like converting color spaces by compression followed by decompression). - Filters are provided by multiple third parties and installed system-wide. DirectX work graphs work with a private node/shader collection provided by the application and connect inputs to outputs by matching node IDs, so it's more like serialization/deserialization of a predefined graph than constructing one by depth-first search, and it's not pulling unknown external nodes of ambiguous quality.

mananaysiempre 2y ago

At the very least AMD made an extension pretty much immediately[1,2]. NVidia... well I don’t really expect graphics-programming-friendly initiatives from NVidia at this point. [1] https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/ [2] https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_AMDX_shader_enqueue.adoc https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...

deleted 2y ago
[deleted]
pjmlp 2y ago
Wrong there, as Slang is the only sane alternative to a stagnant GLSL, unless you favour using DirectX HLSL.
creata 2y ago
As far as I can tell, AMD's extension is supported by exactly one version of AMD's driver, and it's outdated and only on Windows. https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_AMDX_shader_enqueue&platform=all https://vulkan.gpuinfo.org/listdevicescoverage.php?extension... https://github.com/KhronosGroup/Vulkan-Docs/issues/2336 https://github.com/KhronosGroup/Vulkan-Docs/issues/2336 https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-VLK-23-10-01-43.html https://www.amd.com/en/resources/support-articles/release-no...
my123 2y ago
VK_NV_device_generated_commands(_compute), which is already implemented by RADV in Mesa, and is much older than VK_AMDX_shader_enqueue. The X suffix means that it's not a stable API and should not be used by shipped code.
- creata 2y ago
  So are the concerns regarding VK_NV_generated_commmands (mainly, unnecessary latency) in the VK_AMDX_shader_enqueue proposal overstated?
  - my123 2y ago
    It comes with a lot of flexibility that the equivalent AMDX extension doesn't have, including being able to queue graphics shaders, not compute ones only. As far as I can see, unnecessary latency isn't actually a problem.

Lichtso 2y ago

It is true that Vulkan usually is behind DirectX by two to three years, but it gets there eventually. Keep in mind that Vulkan tries to cover a wider range of devices and platforms. Also, in my experience as a contributor to GPU HALs, Vulkan is far more thought-out while DirectX is usually a ship-quickly mess. Vulkan obviously benefits from hindsight here.

pjmlp 2y ago

Vulkan hasn't changed anything in way Khronos works. It is still extension spaghetti, multiple code paths working across extensions and driver bugs. "Make your own SDK" kind of approach, which isn't as bad as OpenGL, only because they at least pay LunarG to make one. But good luck with Android tooling for Vulkan on the NDK, other than a github repo full of samples. A stagnant GLSL, hence why HLSL is now the de factor extension language for most studios, not only due to DirectX, with NVidia's Slang as a close second place.

dagmx 2y ago
Are game studios actually using Slang? I haven’t really seen anyone at GDC or Siggraph mention it outside of a couple projects like Autodesk’s Aurora use it, which itself is very nascent.
- pjmlp 2y ago
  Most game studios are naturally using HLSL, or variations thereof. However that isn't the only reason for Vulkan's existence, and NVidia was proposing Slang at Vulkanised 2024.
  - dagmx 2y ago
    Ah yeah, but NVIDIA have been pushing Slang as a solution for a bit. It’ll be interesting to see if there will be any takers for production use. Even within NVIDIA, they seem to have a constant battle between MDL, Slang and MaterialX.

DonHopkins 2y ago

Sounds like a modern more general version of ActiveMovie aka DirectShow Filter Graphs, from 1996. https://learn.microsoft.com/en-us/windows/win32/directshow/the-filter-graph-and-its-components https://learn.microsoft.com/en-us/windows/win32/directshow/t... The whole point of filter graphs was that it would cleverly try to choose filter implementations based on their wishy-washily defined "merits", depending on what filters and codecs were currently installed, in a way that minimized copying data between the CPU and the video card (pre-modern-programmable-GPUs, mainly video cards with multimedia stream splitting/combining/compressing/decompressing/filtering/rendering and other forms of acceleration). It introduced the term "Codec Hell", an even deeper layer of "DLL Hell": https://en.wikipedia.org/wiki/DirectShow#Codec_hell https://en.wikipedia.org/wiki/DirectShow#Codec_hell >Codec hell (a term derived from DLL hell) is when multiple DirectShow filters conflict for performing the same task. A large number of companies now develop codecs in the form of DirectShow filters, resulting in the presence of several filters that can decode the same media type. This issue is further exacerbated by DirectShow's merit system, where filter implementations end up competing with one another by registering themselves with increasingly elevated priority. >Microsoft's Ted Youmans explained that "DirectShow was based on the merit system, with the idea being that, using a combination of the filter’s merit and how specific the media type/sub type is, one could reasonably pick the right codec every time. It wasn't really designed for a competing merit nuclear arms race." >A tool to help in the troubleshooting of "codec hell" issues usually referenced is the GSpot Codec Information Appliance, which can be useful in determining what codec is used to render video files in AVI and other containers. GraphEdit can also help understanding the sequence of filters that DirectShow is using to render the media file. Codec hell can be resolved by manually building filter graphs, using a media player that supports ignoring or overriding filter merits, or by using a filter manager that changes filter merits in the Windows Registry.

ack_complete 2y ago
It is a lot more constrained than DirectShow graph building. DirectShow has many characteristics that make its graph building fragile: - It allows for fuzzy rules to choose filters, which often overlap and require prioritization. - It runs code in the filters themselves as part of the decision process. This leads to apps breaking when filters are installed that have broken input logic and inject themselves everywhere or reject connections for obscure reasons (e.g. allocator requirements). - It often needs to build a telescope of multiple filters to complete a requested connection, such as a decompression codec followed by a Color Space Converter. This makes it vulnerable to filter loops and horribly inefficient conversion paths (like converting color spaces by compression followed by decompression). - Filters are provided by multiple third parties and installed system-wide. DirectX work graphs work with a private node/shader collection provided by the application and connect inputs to outputs by matching node IDs, so it's more like serialization/deserialization of a predefined graph than constructing one by depth-first search, and it's not pulling unknown external nodes of ambiguous quality.