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

No compiler error thrown when a non-constant ID is passed to subgroupBroadcast #1591

Closed
gfxstrand opened this issue Nov 21, 2018 · 14 comments
Closed

Comments

@gfxstrand
Copy link
Contributor

From the GL_KHR_shader_subgroup spec:

The function subgroupBroadcast() returns the <value> from the invocation
whose <gl_SubgroupInvocationID> is equal to <id>.  <id> must be an integral
constant expression.

However, putting in a non-constant expression works fine in GLSLang. Incidentally, it also works fine in our driver so I could easily see shader authors (apparently myself included) mistaking subgroupBroadcast for subgroupShuffle and a compile error would significantly help.

@johnkslang
Copy link
Member

I did not write this area, but the tests themselves don't use a constant, and are based on gl_SubgroupInvocatioID, which is in, not const, so I wonder if really the spec. is wrong instead.

@sheredom, do you know?

@johnkslang
Copy link
Member

The fix, if it should be fixed, is shown in https://github.com/KhronosGroup/glslang/tree/subgroupBroadcast-const-id.

@sheredom
Copy link

So the way I wrote the spec it should be an integral constant expression.

Does your fix work for specialisation constants too?

@johnkslang
Copy link
Member

So the way I wrote the spec it should be an integral constant expression.

Right. But, the tests heavily rely on non-constants and would have to be rewritten, hence questioning what's appropriate, especially if the test pattern is a realistic one.

Does your fix work for specialisation constants too?

That should work as it does generally, meaning yes, where specialization constants are a subclass of constants.

@sheredom
Copy link

Honestly I can't remember now why we required it to be an integral constant expression.

For what its worth HLSL only requires their equivalent WaveReadLaneAt to be uniform https://docs.microsoft.com/en-us/windows/desktop/direct3dhlsl/wavereadlaneat

And on our implementation we only actually require it to be a uniform value.

@johnkslang
Copy link
Member

The tests are written exclusively in terms of an in, so are not uniform. The id is:

(gl_SubgroupInvocationID + gl_SubgroupSize) % 4

@sheredom
Copy link

Right, so that should never have been valid for subgroupBroadcast - that is the differentiation between subgroupBroadcast and subgroupShuffle -> shuffle allows a fully dynamic id.

@johnkslang
Copy link
Member

Okay, I will change the tests to use a constant.

@johnkslang
Copy link
Member

Can you sign off on #1592?

johnkslang added a commit that referenced this issue Nov 25, 2018
GLSL: Fix #1591: Require the id in subgroupBroadcast to be constant.
@allanmac
Copy link
Contributor

Broadcasting the last lane results in an error (using today's ToT glslang):

subgroupBroadcast(value,gl_SubgroupSize - 1)
>>> ERROR: ... : 'id' : argument must be compile-time constant

@gfxstrand
Copy link
Contributor Author

@allanmac, that's correct. You really want to use subgroupShuffle in that case or use a specialization constant that you fill in from the physical device properties.

Also, be careful doing that as you don't know that the last lane is actually active. Even in compute shaders, there is no guarantee that all lanes are active.

@johnkslang
Copy link
Member

gl_SubgroupSize is not a constant. See KhronosGroup/GLSL#19.

@allanmac
Copy link
Contributor

allanmac commented Nov 27, 2018

Not being able to broadcast the final lane is unfortunate since a "prefix sum followed by a broadcast" is a very common compute idiom.

It's creating more work for the developer to have to define what is essentially subgroupBroadcastLast().

@johnkslang
Copy link
Member

These points should be made in KhronosGroup/GLSL#19.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants