Conversation
| "operand": [ | ||
| { | ||
| "class": "Atomic", | ||
| "operandList": [ | ||
| "*" | ||
| ] | ||
| }, | ||
| { | ||
| "class": "Conversion", | ||
| "operandList": [ | ||
| "OpBitcast" | ||
| ] | ||
| }, | ||
| { | ||
| "class": "Bit", | ||
| "operandList": [ | ||
| "OpBitFieldUExtract", | ||
| "OpBitFieldSExtract" | ||
| ] | ||
| } | ||
| ], | ||
| "builtins": [ | ||
| { | ||
| "name": "HelperInvocation", | ||
| "type": "bool" | ||
| }, | ||
| { | ||
| "name": "Position", | ||
| "type": "float32_t4", | ||
| "const": false | ||
| }, | ||
| { | ||
| "name": "VertexIndex" | ||
| }, | ||
| { | ||
| "name": "InstanceIndex" | ||
| }, | ||
| { | ||
| "name": "NumWorkgroups" | ||
| }, | ||
| { | ||
| "name": "WorkgroupId" | ||
| }, | ||
| { | ||
| "name": "LocalInvocationId" | ||
| }, | ||
| { | ||
| "name": "GlobalInvocationId" | ||
| }, | ||
| { | ||
| "name": "LocalInvocationIndex" | ||
| } | ||
| ] |
There was a problem hiding this comment.
we should export everything, and just add type and const fields to the grammar json in this repo
There was a problem hiding this comment.
ok I get the point of this... somewhat (it limits what we export)
but I think type and const should be added directly to the json enties in spirv.core.grammar.json, basically the builtins section shouldn't exist, unless you want to just list (allow/block) the builtin names you wish to export
There was a problem hiding this comment.
There are benefits to keeping type mapping in a separate file.
The biggest one i can think of is that by modifying the grammar file, any subseqent updates pulled from Khronos Group might result in having to solve merge conflicts.
What might also happen is the c++ code generator stops working once the JSON schema changes, but surely its just me being paranoid.
There was a problem hiding this comment.
first one is moot
What might also happen is the c++ code generator stops working once the JSON schema changes, but surely its just me being paranoid.
test this, but we'll only ever add extra fields
| { | ||
| "kind": "IdResult", | ||
| "type": "T" | ||
| }, |
There was a problem hiding this comment.
we should probably call type, cpp_type or hlsl_type instead
and apply it to IdResultType
There was a problem hiding this comment.
hmm actually, you should have hlsl_type e.g. const T& -> this means constant, ext_reference
but also list generics separately (once for the whole function).
The reason is that sometimes you might end up with 4 template dependant parameters (if vk::SpirvType<> gets involved), and only 2 template args
There was a problem hiding this comment.
I might add an optional field that allows the user to list generic typenames that dont fit in the standard "single alphabetic char, uppercase" , and then merge attributes, const and type into hlsl_type field.
| "attributes": [ | ||
| "vk::ext_reference" | ||
| ] |
There was a problem hiding this comment.
vk::ext_reference is actually the only attribute we can apply.
Btw we need to modify how we codegen, the reason is that [vk::ext_reference] P doesnt work in all cases, so we need BOTH
template<typename T>
[[vk::ext_instruction(spv::OpAtomicLoad)]]
T AtomicLoad([[vk::ext_reference]] T pointer, uint32_t memory, uint32_t semantics);
template<typename T, typename Ptr_T>
[[vk::ext_instruction(spv::OpAtomicLoad)]]
T AtomicLoad(Ptr_T pointer, uint32_t memory, uint32_t semantics);imho instead of listing the attributes separately, we could deduce it from the type containing & (being a T& in this case)
There was a problem hiding this comment.
obviously if you have a lot of & this turns into combinatorial explosion of overloads 2^parameters_with_overloads but thats the fault of microsoft/DirectXShaderCompiler#6578
| "type": "float32_t4", | ||
| "const": false |
There was a problem hiding this comment.
hmm I'd definitely take the const from the type
tools/nblIntrinicGenerator/example output/exampleIntrisincsCore.hlsl
Outdated
Show resolved
Hide resolved
2 participants
I added a readme to the tool to explain the two additional json files
A few of the things are hard coded such as the
#includeandnamespacestatements in the generated as its meant to be a replacement for files in nbl/builtin/hlsl/spirv_intrinsics,Those might need to be manually adjusted in the generated HLSL file.