You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the initial PR (#59) builtins were added as functions:
[[vk::ext_builtin_input(/* BuilIn ID */1234)]]
uintmyBuiltin();
[[vk::ext_builtin_output(/* BuilIn ID */5678)]]
voidmyOtherBuiltin(uint output);
A later PR changed those to be variables, to better reflect the underlying SPIR-V (#129).
[[vk::ext_builtin_input(/* BuilIn ID */1234)]]
staticconstuint myBuiltin;
[[vk::ext_builtin_output(/* BuilIn ID */5678)]]
staticuint myOtherBuiltin;
static was used here because since builtin have either the Input or Output storage class, those are only visible to the current invocation.
Issue is: on the LLVM side, static means private to the module, and since we compile the whole module, many optimizations are allowed. For example, all loads can be removed, and the input bits can be considered to be invalid, and all stores to the output variable can be removed as long as no load is done after (which should not happen in a shader).
The simple alternative I'd suggest is to use extern:
we explicitly tell the compiler "something is going on, the value is set elsewhere, you cannot optimize".
by not marking it volatile, we allow the compiler to load/store once.
The drawback is this doesn't carry the info the variable is locale to the invocation. Adding a thread_local storage class could be a solution, but this keyword is not available in HLSL.
Suggested syntax:
[[vk::ext_builtin_input(/* BuilIn ID */1234)]]
externconstuint myBuiltin;
[[vk::ext_builtin_output(/* BuilIn ID */5678)]]
externuint myOtherBuiltin;
The alternative is to fallback on a function style builtin.
For loads, I think as long as we mark the builtin function as readnone, compiler might be able to load once. For store however, the compiler won't be able to optimize away 2 subsequent store, unless we hack around and delay the function call to the end of the function.
The text was updated successfully, but these errors were encountered:
maybe its time to actually expose Storage Spaces properly (workgroup/shared, private and function could have the same name since that depends solely on declaration site, device) ?
Which document does this relate to?
https://github.com/microsoft/hlsl-specs/blob/main/proposals/0011-inline-spirv.md
Describe the issue you see with the spec
In the initial PR (#59) builtins were added as functions:
A later PR changed those to be variables, to better reflect the underlying SPIR-V (#129).
static
was used here because since builtin have either theInput
orOutput
storage class, those are only visible to the current invocation.Issue is: on the LLVM side, static means private to the module, and since we compile the whole module, many optimizations are allowed. For example, all loads can be removed, and the input bits can be considered to be invalid, and all stores to the output variable can be removed as long as no load is done after (which should not happen in a shader).
The simple alternative I'd suggest is to use
extern
:The drawback is this doesn't carry the info the variable is locale to the invocation. Adding a
thread_local
storage class could be a solution, but this keyword is not available in HLSL.Suggested syntax:
The alternative is to fallback on a function style builtin.
For loads, I think as long as we mark the builtin function as
readnone
, compiler might be able to load once. For store however, the compiler won't be able to optimize away 2 subsequent store, unless we hack around and delay the function call to the end of the function.The text was updated successfully, but these errors were encountered: