[Test] Gate extension-requiring tests on actual device capabilities instead of a static arch table.#803
Conversation
…nd skip tests accordingly.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d382cd7918
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| return bool(caps.get(_qd_core.DeviceCapability.spirv_has_physical_storage_buffer)) and bool( | ||
| caps.get(_qd_core.DeviceCapability.spirv_has_int64) |
There was a problem hiding this comment.
Gate adstack on all SPIR-V sizer capabilities
On a Vulkan device that advertises physical-storage buffers and int64 but lacks int8 or int16, this returns True for qd.extension.adstack, so the updated test fixture will run require=qd.extension.adstack cases instead of skipping them. The actual SPIR-V adstack sizer still hard-errors unless spirv_has_physical_storage_buffer, spirv_has_int64, spirv_has_int8, and spirv_has_int16 are all present (runtime/gfx/adstack_sizer_launch.cpp:332-337), so this check needs to match that runtime gate.
Useful? React with 👍 / 👎.
Issue: #
Whether the
adstackanddata64extensions are actually usable on the SPIR-V archs (vulkan,metal) is aproperty of the initialized device, not of the arch alone: the on-device adstack size interpreter reads through raw
64-bit buffer addresses, so it needs
spirv_has_physical_storage_buffer+spirv_has_int64(the launch gate inruntime/gfx/adstack_sizer_launch.cpp), anddata64needsspirv_has_int64+spirv_has_float64. The staticarch-level extension table cannot advertise this, so
@test_utils.test(require=...)used to resolve support atcollection time against that table -- which is both too coarse (no device exists yet) and wrong on the SPIR-V archs.
This PR:
is_extension_enabledconsult the initialized device's capabilities foradstack/data64on the SPIR-Varchs, superseding the static table where the device is the authority;
require=resolution from collection time into thewanted_archfixture: the requiredextensions ride the parametrization and are checked against the actual device after
qd.init, skipping with aclear reason when the device does not support one.
No behavior change on CPU / CUDA / AMDGPU, where the arch table already matches the device.
Brief Summary
copilot:summary
Walkthrough
copilot:walkthrough