[MarijnS95]

The HLSL mapping in the VK_EXT_ray_tracing_invocation_reorder proposal pairs the instance getters by name, which swaps them:

* HitObject::GetInstanceIndex -> OpHitObjectGetInstanceCustomIndexEXT
* HitObject::GetInstanceID -> OpHitObjectGetInstanceIdEXT

In HLSL, InstanceID()/HitObject::GetInstanceID() return the application-specified 24-bit value, which SPIR-V calls InstanceCustomIndexKHR (gl_InstanceCustomIndexEXT). InstanceIndex()/HitObject::GetInstanceIndex() return the index of the instance in the TLAS, which SPIR-V calls the InstanceId BuiltIn (gl_InstanceID). DXC already maps the non-SER intrinsics this way. GLSL_EXT_shader_invocation_reorder documents hitObjectGetInstanceIdEXT() as returning "the index of the instance", so OpHitObjectGetInstanceIdEXT corresponds to GetInstanceIndex, not GetInstanceID.

We hit this in practice: our SER wrapper, built on SPIR-V intrinsics until microsoft/DirectXShaderCompiler#8226 lands, followed this table and read the TLAS index on Vulkan where D3D12 returns the custom index. The table is also the obvious reference for the eventual DXC implementation, so it should be right before that lands.

The two corrected rows also link to the SPIR-V ops. GetInstanceID additionally links to VkAccelerationStructureInstanceKHR::instanceCustomIndex, the field it reads back.

KhronosGroup/SPIRV-Registry#459 clarifies the ambiguous OpHitObjectGetInstanceIdEXT description in the SPIR-V extension.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[MarijnS95]

Whoa, this should not have been insta-merged at all 😳 - I'm surprised I even have merge rights. @oddhack should I just revert this so that interesting parties can take a look?

[dgkoch]

Whoa, this should not have been insta-merged at all 😳 - I'm surprised I even have merge rights. @oddhack should I just revert this so that interesting parties can take a look?

Bad Claude!

[oddhack]

Yes, please revert it. I'll take another look at the repo permissions.

[oddhack]

I attempted setting up branch protection rules on main so that only Admins and Maintainers should be able to push. If you are not able to revert the PR that would be good evidence that the rule is working :-)

[MarijnS95]

@oddhack and preferably branch protection rules require at least one review approval (with a maintainer override available)?

Indeed I'm unable to push the revert to main now, and also unable to merge its revert PR #2832. It doesn't say that I'm unable to merge until approval, just that I'm disallowed to push to the branch whatsoever.