[HN Gopher] A quick introduction to DirectX workgraphs
___________________________________________________________________
A quick introduction to DirectX workgraphs
Author : PaulHoule
Score : 37 points
Date : 2024-07-02 19:49 UTC (5 days ago)
(HTM) web link (interplayoflight.wordpress.com)
(TXT) w3m dump (interplayoflight.wordpress.com)
| jsheard wrote:
| 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 wrote:
| 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/
|
| [2] https://github.com/KhronosGroup/Vulkan-
| Docs/blob/main/propos...
| pjmlp wrote:
| Wrong there, as Slang is the only sane alternative to a
| stagnant GLSL, unless you favour using DirectX HLSL.
| creata wrote:
| 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.
| ..
|
| https://github.com/KhronosGroup/Vulkan-Docs/issues/2336
|
| https://www.amd.com/en/resources/support-articles/release-
| no...
| my123 wrote:
| 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 wrote:
| So are the concerns regarding VK_NV_generated_commmands
| (mainly, unnecessary latency) in the VK_AMDX_shader_enqueue
| proposal overstated?
| my123 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| DonHopkins wrote:
| Sounds like a modern more general version of ActiveMovie aka
| DirectShow Filter Graphs, from 1996.
|
| 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/combi
| ning/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
|
| >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 wrote:
| 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.
| CooCooCaCha wrote:
| I'm curious what the endgame is for GPUs. It seems like over-time
| they've been going down the road of generally-programmable
| parallel processors.
|
| Will there come a time where, like CPUs, we land on a more
| general programming model and we don't need graphics apis to
| introduce new features? Instead, if there's a new graphics
| technique we don't have to wait for a new DirectX feature, we can
| just code it ourselves?
___________________________________________________________________
(page generated 2024-07-07 23:02 UTC)