renderdoc VS DirectXShaderCompiler

heh https://github.com/baldurk/renderdoc#readme is all "RenderDoc is intended for debugging your own programs only. Any discussion of capturing programs that you did not create will not be allowed in any official public RenderDoc setting, including the issue tracker, discord, or via email" but the 3 of the 4 screenshots are of dota2 :-D

Still, that looks handy for sure

He's pretty clear about it every time it's asked. Tracing copyrighted games is legally questionable, and tools like RenderDoc are often abused by people to do illegal asset ripping/reselling.

Baldur explains why he won't implement bindless texture support in this issue: https://github.com/baldurk/renderdoc/issues/850

Unfortunately the main developer for Renderdoc is against adding ray tracing support : https://github.com/baldurk/renderdoc/issues/2317

RenderDoc bug report: https://github.com/baldurk/renderdoc/issues/2800

Remember that Renderdoc is open source: https://github.com/baldurk/renderdoc/. This means you can build it with symbols and attach a debugger.

Renderdoc works by inserting itself as a Vulkan layer, which means it can change the output of functions if it so chooses. As you can see in the RenderDoc version of vkEnumeratePhysicalDevices it changes how devices are returned, and this likely is the reason the order changes.

> We may support DXBC generation in Clang in the future (we mentioned that in the original proposal to LLVM). That work is unlikely to begin for a few years as our focus will be on supporting DXIL and SPIR-V generation first.

I appreciate this quote[0] from the microsoft camp. Setting clear expectations that something will not be done is a nice bit of fresh air.

[0] https://github.com/microsoft/DirectXShaderCompiler/issues/57...

There's no need for transpilers these days, you can just compile HLSL to SPIR-V bytecode with dxc.

https://github.com/microsoft/DirectXShaderCompiler

Use DXC and only HLSL for your main shader editing.

You can see libdxilconv in there, DXIL is the DirectX Intermediate Representation, documented in the open source shader compiler from Microsoft.

BTW, this problem can be reproduced as described below: - clone https://github.com/SaschaWillems/Vulkan.git - build the project and run it with arguments : -v - s hlsl to enable the validation layer and to use hlsl code - run ComputeShader project. The following validation error "Type mismatch on descriptor slot ..." will be shown in the console. - to fix it, as suggested above, you can replace the 3rd line of emboss.comp, sharpen.comp, and edgedetect.comp from: Texture2D inputImage : register(t0); //Creates validation errors to RWTexture2D inputImage : register(u0); //no validation errors (you'll then need to recompile the shaders to spv with a proper hlsl compiler such as Microsoft dxc)

EDIT: There is also naga but it does not take HLSL as input: https://github.com/gfx-rs/naga but you can use DirectXShaderCompiler to compile to SpirV, then use naga to compile to Metal.

🤨 For a "refusal to acknowledge it", they do appear to have a rather sizeable document mapping between HLSL and SPIR-V? https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/SPIR-V.rst

I am starting work on a compute-driven rendering engine, and it seems that the best way to go around it will be to write code in HSSL, and then use DirectXShaderCompiler to generate SPIR-V, and SPIRV-Cross to then generate MSL. And while DXSC's repo has a page on incompatibilities, no such resource seems to exist for SPIRV-Cross targeting Metal.

DirectX Shader Compiler