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
As I started to look into some thread/group related semantics, I noticed SV_DispatchThreadID has been implemented.
From MSDN, semantic is a uint3, each element for 1 dimension.
However, the dx_thread_id intrinsic is implemented as i32 dx_thread_id(i32), and it looks like this intrinsic is called 1 time for each dimension. Do you know why? Is that expected?
On the SPIR-V side, we gather all 3 dimensions at the same time, hence it would be convenient to have the following intrinsic prototype instead: <3 x i32> thread_id().
On the DXIL side (generated by DXC), looks like there are no builtin call, the semantic is directly linked to an <3 x i32> input parameter with the semantic.
The text was updated successfully, but these errors were encountered:
The current implementation for semantics is subject to change, as we will be working through the design generally for all signature semantics and lowering. I think it's reasonable and likely at this point that this intermediate intrinsic will be changed to the vector form which you would prefer. I'll include you on PRs for this design process to make sure you're kept in the loop.
Note: for DXIL, I suspect you tried a library target and the entry function wasn't marked with a [shader("compute")] attribute. If you compile to a cs_6_0+ target instead, you should see DXIL op calls that load one component at a time (dx.op.threadId), just like the dx_thread_id(i32) intrinsic.
Hi!
As I started to look into some thread/group related semantics, I noticed SV_DispatchThreadID has been implemented.
From MSDN, semantic is a uint3, each element for 1 dimension.
However, the dx_thread_id intrinsic is implemented as
i32 dx_thread_id(i32)
, and it looks like this intrinsic is called 1 time for each dimension. Do you know why? Is that expected?On the SPIR-V side, we gather all 3 dimensions at the same time, hence it would be convenient to have the following intrinsic prototype instead:
<3 x i32> thread_id()
.On the DXIL side (generated by DXC), looks like there are no builtin call, the semantic is directly linked to an
<3 x i32>
input parameter with the semantic.The text was updated successfully, but these errors were encountered: