5 ms·
Real-Time Procedural Generation with GPU Work Graphs [pdf]
- corysama 2y agoRelated: https://gpuopen.com/learn/work_graphs_mesh_nodes/work_graphs_mesh_nodes-intro/ https://gpuopen.com/learn/work_graphs_mesh_nodes/work_graphs...
- lainga 2y agoWork graphs are in Vulkan (pg. 3)?! Since when? Where can I learn about this? Excitement
- elabajaba 2y agoIIRC they're an AMD extension (VK_AMDX_shader_enqueue) that only works with a specific beta driver currently. I wouldn't really say they're usable in vulkan at this point.
- corysama 2y agoI think Vulkan support is still AMD-only. https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/
- brcmthrowaway 2y agoDoes this work on Metal
- dagmx 2y agoMetal’s closest equivalent is Indirect Command Buffers. https://developer.apple.com/documentation/metal/indirect_command_encoding/encoding_indirect_command_buffers_on_the_gpu https://developer.apple.com/documentation/metal/indirect_com... However, there is no direct equivalent to work graphs. This DirectX blog goes over the differences in DirectX’s equivalent to indirect calls and work graphs better https://devblogs.microsoft.com/directx/d3d12-work-graphs/ https://devblogs.microsoft.com/directx/d3d12-work-graphs/ That said, a lot of what the AMD paper talks about can be done without work graphs, just with more care required.
- doug-moen 2y agoGPUs are Turing complete computers. Why is it necessary to add a GPU programming design pattern like this as an extension to Vulkan? Can I just implement this design pattern in an existing GPU programming language right now, without waiting for Vulkan extensions to be implemented for all the relevant GPU models? If this isn't possible right now, then what's missing from existing GPU languages that prevents this kind of flexibility?
- ttoinou 2y agoI’m wondering the same. Maybe it’d be easier if we could upload our own ‘sequential program’ to a little CPU inside the GPU that would be code making calls to the real GPU. This way delays to native GPU code would be minimized and we wouldn’t need to mimick creating new features / GPU paradigms
- 01HNNWZ0MV43FF 2y agoCan't hardly wait for GPGPU wasm
- corysama 2y agoDo you mean https://google.github.io/tour-of-wgsl/ https://google.github.io/tour-of-wgsl/ ?
- GrantMoyer 2y ago> Maybe it’d be easier if we could upload our own ‘sequential program’ to a little CPU inside the GPU that would be code making calls to the real GPU. This is effectively what Command Lists/Buffers are in Direct3D 12 or Vulkan.
- zeusk 2y agoBecause every GPU on the market has a very different internal organization and instruction set. They are able to execute any shader using standardized programming constructs (Vulkan, DirectX, Metal) that both the OS and driver understand. While the API and OS manage device/app context, the driver manages the device itself and the job of compiling shaders or standard calls to their GPUs specific instructions or layout.
- zellyn 2y agoFigure 1… :slow clap: For those who don't want to click through: (a) Without our system -- (empty courtyard) (b) With our system -- (same picture but with procedural generated content added)
- CuriousCosmic 2y agoLol. Technically true. I think the intent of that graphic is to show how you can take a relatively simple map or set of assets and augment them in real time (with relatively low compute cost) to substantially improve the visuals without all of the overhead, latency, and cost that comes with storing, loading, CPU side processing, and memory transfer of those fully baked (or CPU side generated) assets.
- bloodwyn 2y agoAuthor here, yeah I know....this fig is a trade-off between having a nicely looking scene but also being scientifically clean by stating what we did and did not do with our system. Also everything the other comment said is correct :)
- zellyn 2y agoDon't get me wrong; I think it's fantastic! Also, I am 100% going to write a paper sometime with a blank rectangle on the left! :tears of joy: