dx12: NumWorkgroups builtin

[ForestCSharp]

Short info header:

• GFX version: master-branch
• OS: Windows
• GPU: GTX 1070 (Notebook)

When attempting to compile a compute shader that uses gl_NumWorkGroups on DX12 backend, it fails with this message:

'failed to create compute pipeline: Shader(CompilationFailed("NumWorkgroups builtin is used, but remap_num_workgroups_builtin() was not called. Cannot emit code for this builtin."))'

https://github.com/ForestCSharp/gfx_gltf_anim

[msiglreith]

Thanks for reporting, I shortened the title a bit 😊 We have a few spare root constants for these in our pipeline layouts, which need to be hooked up and the spirv-cross codegen adjusted a bit.

[ForestCSharp]

@msiglreith I'd be happy to give this a shot, as its affecting my little test-project at the moment. Could you point me in the right direction?

[msiglreith]

@ForestCSharp Gladly!

• Allocate a root constant (3xu32) in the pipeline layout on creation to store the builtin values
• Adjust the spirv-cross compiler to specify the correct register and space (https://github.com/KhronosGroup/SPIRV-Cross/blob/master/spirv_hlsl.hpp#L133). Might need to expose it in our rust spirv cross wrapper.
• When submitting the compute workload on dispatch, set the root constants by hand, which are passed on call.

VkPI: For indirect dispatches we can't do this reasonable I guess. Reading the buffer back would involve such a huge stall it doesnt make much sense IMO. Similar to https://github.com/gfx-rs/gfx/issues/2589 cc @kvark

[kvark]

@msiglreith maybe it shouldn't be a push constant then, and instead be an internally managed buffer that we fill and re-bind to the shader (with a particular offset)? This way we'd be able to handle the indirect dispatches by copying out the buffer data, at the cost of slightly increased complexity on our side.

[msiglreith]

good point, definitely an option which can be pursueded (root descriptor). Managing an internal heap would give some freedom at other parts of the implementation but at the cost of possible violation the 4096 allocation limit, even though not that big of an deal. I suspect this will involve a bit more work overall. In the end we will probably need to the the copy/push lazily as we have to make it for all action commands then. In the end it might be the better option actually due to the size restrictions we have on the root signature, but so far I'm not aware if we need further builtins on either graphic or compute side.

[Yamakaky]

Any way to work around this? I use wgpu-rs and my program works fine on vulkan, but crashes with renderdoc since it forces dx12. Bonus point if there is a way to force the wgpu backend that I don't know of ;)

[grovesNL]

@Yamakaky you can specify which backends to allow in wgpu-rs using BackendBit (during Adapter::request)

[Yamakaky]

OMG I brainfarted at read PRIMARY as primary GPU, not backend. Thanks!

[kvark]

Sorry, no workarounds on DX12. It needs to be implemented. Help is welcome!

[Danielmelody]

Any progress?

[kvark]

Unless somebody steps in, my long-term plan was to address this as soon as we start compiling the shaders with Naga (as opposed to SPIRV-Cross). Currently, the HLSL backend is only getting started. If somebody wants to get this going on SPIRV-Cross, we'll happily accept that.