Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPIRV] Missing gl_NumWorkGroups #4217

Closed
Eichenherz opened this issue Jan 30, 2022 · 14 comments · Fixed by #6027
Closed

[SPIRV] Missing gl_NumWorkGroups #4217

Eichenherz opened this issue Jan 30, 2022 · 14 comments · Fixed by #6027
Assignees
Labels
spirv Work related to SPIR-V

Comments

@Eichenherz
Copy link

I'm currently using this to atomically count the workgroups as such:

if( ( gl_LocalInvocationID.x == 0 ) && ( workgrAtomicCounterShared == gl_NumWorkGroups.x - 1 ) )
//...... DO some work on the final value of a counter

In SPIRV gl_NumWorkGroups would be:

OpDecorate %gl_NumWorkGroups BuiltIn NumWorkgroups

How do I access the same BuiltIn in HLSL as it's not exposed through any SV ?

@pow2clk
Copy link
Member

pow2clk commented Feb 7, 2022

Hi @Eichenherz!

There is not currently an HLSL equivalent to g_NumWorkGroups. I'm inferring from the information provided that you'd like this to target SPIRV. As such, I'll leave it to the SPIRV folks @jaebaek and @sudonatalie if they plan to do something here.

In the meantime, you might consider passing the information through a constant buffer (UBO in GL speak) good luck!

@pow2clk pow2clk added the spirv Work related to SPIR-V label Feb 7, 2022
@pow2clk pow2clk changed the title Missing gl_NumWorkGroups [SPIRV] Missing gl_NumWorkGroups Feb 7, 2022
@Eichenherz
Copy link
Author

Yes, precisely for HLSL to SPIRV. I did try the vk::ext_decorate(24) as that's the NumWorkgroups ID. But it would not produce any "OpDecorate Builtin NumWorkgroups".

@jaebaek
Copy link
Collaborator

jaebaek commented Feb 8, 2022

Sorry for being late. We will take a look. Definitely, we have to consider adding some new intrinsics. We currently experience intense workloads. It can be delayed. Sorry about that in advance.

@sudonatalie
Copy link
Collaborator

[[vk::ext_decorate(/* BuiltIn */ 11, /* NumWorkGroups */ 24)]] does correctly generate the desired OpDecorate %var BuiltIn NumWorkgroups, but the problem is getting %var to be the correct type with our current implementation. If you decorate a global, then it gets wrapped in the Globals struct, and the decoration is incorrectly applied to the wrapper. If an entry point input variable is decorated, then it needs a semantic string. I think this issue should be handled along with #4195, but I'll leave it to @jaebaek to determine if it's a duplicate before closing.

@jaebaek
Copy link
Collaborator

jaebaek commented May 3, 2022

I think we can define a variable like the following example:

RWStructuredBuffer<int> A;

[numthreads(1,1,1)]
void main() {
  [[vk::ext_storage_class(1)]]
  [[vk::ext_decorate(11, 24)]]
  uint3 numWorkgroups;

  A[0] = numWorkgroups.x;
}

However, the validation layer report an error

fatal error: generated SPIR-V is invalid: Interface variable id <2> is used by entry point 'main' id <1>, but is not listed as an interface
  %numWorkgroups = OpVariable %_ptr_Input_v3uint Input

We have to check the variable storage class in this line and add it as an operand of the entry point if it is an Input storage class. Let me keep this issue open.

@forbiddencactus
Copy link

@jaebaek

Do you have any update on this issue? I'm keen to take advantage of the code snipped you posted above but I'm running into the same is not listed as an interface issue.

@s-perron
Copy link
Collaborator

s-perron commented Jun 2, 2023

This is going to be a bigger issues to fix. I don't want to just do another hack with the existing inline spir-v. I'm going to look into revamping the whole feature.

@s-perron s-perron self-assigned this Jun 13, 2023
@s-perron
Copy link
Collaborator

I opened microsoft/hlsl-specs#59. This should add a new attribute that can be used to properly define builtin input and output.

@kpentaris
Copy link

kpentaris commented Jun 30, 2023

Also looking for a similar fix regarding access to Compute Shader globals (gl_GlobalInvocationID, gl_LocalInvocationIndex etc). Please note that these need to be globally accessible from a shader file that is #included and has no access to any entry point!

#include "utils.hlsl"
// Contains the following
void initializeArr() {
  [[vk::ext_storage_class(1)]]
  [[vk::ext_decorate(11, 28)]]
  uint3 gl_GlobalInvocationID;
  arr[gl_GlobalInvocationID.x] = 0;
}
// end of utils.hlsl

void main() {
  initializeArr();
}

In complex shader implementations it's really cumbersome to pass around the gl_ globals, it'd be best to have access to them as we do in GLSL.

Thanks in advance!

@s-perron
Copy link
Collaborator

@kpentaris That is the current plan in microsoft/hlsl-specs#59.

@devshgraphicsprogramming

@kpentaris That is the current plan in microsoft/hlsl-specs#59.

and when will it land in DXC?

@s-perron
Copy link
Collaborator

s-perron commented Aug 8, 2023

No idea when it will land.

@OlesenJonas
Copy link

It seems possible to override an existing input as a workaround. Eg: im currently (ab)using SV_GroupIndex to get the SubgroupID:
[[vk::ext_decorate(11/*BuiltIn*/, 40/*SubgroupId*/)]] int waveIndex : SV_GroupIndex

cassiebeckley added a commit that referenced this issue Jan 2, 2024
…6027)

I definitely think it would look better if we allowed these attributes
on variables, ie microsoft/hlsl-specs#76. I
haven't fully investigated how involved it would be to implement, but my
intuition is that it wouldn't take that much more work.

Fixes #4217.
@devshgraphicsprogramming

@kptentaris

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spirv Work related to SPIR-V
Projects
None yet
9 participants