Intel(R) Iris(R) Xe Graphics (RPL-P) Vulkan reports incorrect subgroup size

[zheyuan]

Hello Intel Team,
I believe I’ve encountered a potential bug regarding gl_SubgroupSize reporting on the Intel Iris Xe GPU.

Summary:

• When querying gl_SubgroupSize in GLSL, the reported size is 32, which aligns with the value reported by vulkaninfo.

• However, only invocations 0 through 15 seem to be actually active. All subgroup invocations beyond 15 are inactive and fail conditional checks involving gl_SubgroupInvocationID. This behavior persists even under uniform control flow, where all threads take the same execution path.

Reproducible Observations:

Test 1

#version 460
#extension GL_KHR_shader_subgroup_basic : enable
#extension GL_KHR_memory_scope_semantics : enable
layout(set = 0, binding = 0) buffer Buf {
uint buf;
};
layout(local_size_x = 128, local_size_y = 1, local_size_z = 1) in;
void main()
{
 if (gl_SubgroupSize == 32) {
  atomicStore(buf, uint(2), 4, 64, 4);
}
 barrier();
}

Initial value of buf: 0
Result: buf == 2 after shader execution
Interpretation: gl_SubgroupSize reports 32 as expected

Test 2

#version 460
#extension GL_KHR_shader_subgroup_basic : enable
#extension GL_KHR_memory_scope_semantics : enable
layout(set = 0, binding = 0) buffer Buf {
uint buf;
};
layout(local_size_x = 128, local_size_y = 1, local_size_z = 1) in;
void main()
{
if (gl_SubgroupInvocationID == 31) {
atomicStore(buf, uint(2), 4, 64, 4);
}
barrier();
}

Initial value of buf: 0

Result: buf == 0 after execution — this also holds for gl_SubgroupInvocationID == [16, 32)

However, using values in the range [0, 16) does result in buf == 2

Test 3

#version 460
#extension GL_KHR_shader_subgroup_basic : enable
#extension GL_KHR_memory_scope_semantics : enable
#extension GL_KHR_shader_subgroup_arithmetic : enable
layout(set = 0, binding = 0) buffer Buf {
uint buf;
};
layout(local_size_x = 128, local_size_y = 1, local_size_z = 1) in;
void main()
{

buf = subgroupAdd(1);
barrier();
}

Initial value of buf: 0

Result: buf == 16 after execution

Interpretation: Only 16 threads participate in the subgroupAdd, indicating the actual subgroup size is 16, despite gl_SubgroupSize reporting 32.

This suggests that even though the reported subgroup size is 32, only 16 threads per subgroup are actually active, implying that the real subgroup size should be 16 in practice.

I've attached my test programs (All tests use a workgroup size of 128, with 1 workgroup, run through the Amber framework. you can easily extract the glsl compute shader from it) and the vulkaninfo output in forms of zip file.

[Earl_Intel]

Hi zheyuan,

Thank you for posting in the communities!

Thank you for providing all of this information and your conclusions on the problem you raised. But for me to better assist you and determine the best resolution towards the issue, could you please provide the needed details listed below:

• May I know if you're a developer or an end user?
• Are you trying to develop an application? if yes, may I know the name of the application?

Best regards,

Earl E.

Intel Customer Support Technician

[zheyuan]

Hi sorry for the late reply.

I’m a developer, but I’m not currently developing an application. I’m just trying to run some tests on an Intel device.

[Earl_Intel]

Hello zheyuan,

Thank you for the confirmation.

Since you're a developer, we have a dedicated developing applications/games (Developing Games on Intel Graphics - Intel Community) forum that can help you with your concern.

I'll be routing you to our other team so that they can further assist you with your inquiries.

Best regards,

Earl E.

Intel Customer Support Technician

[zheyuan]

Hi Earl,

Thanks for the help! Do I need to repost this again on the developer forum?

Best,

Zheyuan