Open devshgraphicsprogramming opened 1 year ago
@dneto0 is that acceptable?
Hi. It would be better to generate a new file specific for HLSL inclusion.
@dneto0 actually if we were to make a HLSL header, would you accept something that actually declares all the SPIR-V functions and types using DXC's inline SPIR-V, like so?
We're kinda thinking of generating them from the JSONs now because its a hassle to maintain them by hand, and since they'd be generated from the Header JSONs it seems like this repo is the place to keep them.
@dneto0 actually if we were to make a HLSL header, would you accept something that actually declares all the SPIR-V functions and types using DXC's inline SPIR-V, like so?
That blob has gone missing.
We're kinda thinking of generating them from the JSONs now because its a hassle to maintain them by hand, and since they'd be generated from the Header JSONs it seems like this repo is the place to keep them.
I would say no. Use the core grammar file to generate what you want in your own repo.
This is what SPIRV-Tools does.
It's why the grammar file is in JSON.
@dneto0 actually if we were to make a HLSL header, would you accept something that actually declares all the SPIR-V functions and types using DXC's inline SPIR-V, like so? https://github.com/Devsh-Graphics-Programming/Nabla/blob/spirv_intrinsics/include/nbl/builtin/hlsl/spirv_intrinsics/core.hlsl
That blob has gone missing.
Sorry about that, here's a permalink: https://github.com/Devsh-Graphics-Programming/Nabla/blob/6253ed92aa0c979bec75235c6fa7b0d3ac33c959/include/nbl/builtin/hlsl/spirv_intrinsics/core.hlsl#L21
We're kinda thinking of generating them from the JSONs now because its a hassle to maintain them by hand, and since they'd be generated from the Header JSONs it seems like this repo is the place to keep them.
I would say no. Use the core grammar file to generate what you want in your own repo. This is what SPIRV-Tools does. It's why the grammar file is in JSON.
My original request/sugestion was to make the C++ (and 11) headers shareable with HLSL by conditionally disabling the global operator overloads (since DXC's modified Clang disabled that).
Then I realized that since you'd want a separate header for HLSL, I could provide the intrinsics to go along with it:
template<typename T>
T atomicAdd([[vk::ext_reference]] T ptr, uint32_t memoryScope, uint32_t memorySemantics, T value);
template<>
[[vk::ext_instruction(spv::OpAtomicIAdd)]]
int32_t atomicAdd([[vk::ext_reference]] int32_t ptr, uint32_t memoryScope, uint32_t memorySemantics, int32_t value);
template<>
[[vk::ext_instruction( spv::OpAtomicIAdd )]]
uint32_t atomicAdd([[vk::ext_reference]] uint32_t ptr, uint32_t memoryScope, uint32_t memorySemantics, uint32_t value);
Then this not only gives you the SPIR-V enum tokens but also actual intrinsic entry points to use in your HLSL.
P.S. This is non-invasive because DXC will not emit any capabilities or extensions if they're not in the entry point's call tree.
Hi, we're doing a slightly weird thing, which is we're including the SPIR-V Header in our HLSL code to make the writing on SPIR-V intrinsics easier (don't need to remember the opcodes)
However HLSL doesn't support global operator overloads, so we need a define similar to
SPV_ENABLE_UTILITY_CODE
(although a negative one so backwards compatibility it preserved)alternative is
#ifndef __HLSL_VERSION
which checks for the HLSL compiler.PR incoming.