Add SPV_AMDX_shader_enqueue version 2 support #5838
Conversation
|
Could you please rebase on main and update the spirv-headers hash in DEPS to point to at least the merged headers for this extension? |
* Update SPIRV-Headers Co-authored-by: Dan Brown <daniel.brown@amd.com> Co-authored-by: Maciej Jesionowski <maciej.jesionowski@amd.com>
yavn
force-pushed
the
SPV_AMDX_shader_enqueue_v2
branch
from
6e411f5
to
bef6468
Compare
|
Hi @alan-baker , done and done. |
There was a problem hiding this comment.
Overall there seem to be a lack of tests for this functionality. Please add some tests for the new validation.
Separately, when reading the spec for this extension you seem to be validating things that are missing from the spec. I'd suggest double checking and updating the extension text to match this validation.
| case spv::Decoration::NodeSharesPayloadLimitsWithAMDX: | ||
| case spv::Decoration::PayloadNodeArraySizeAMDX: | ||
| case spv::Decoration::PayloadNodeNameAMDX: | ||
| case spv::Decoration::PayloadNodeBaseIndexAMDX: |
There was a problem hiding this comment.
These could all do with a simple test that OpDecoration is disallowed, but OpDecorationId is allowed.
| @@ -302,6 +304,7 @@ spv_result_t ValidateFunctionCall(ValidationState_t& _, | |||
| case spv::StorageClass::Private: | |||
| case spv::StorageClass::Workgroup: | |||
| case spv::StorageClass::AtomicCounter: | |||
| case spv::StorageClass::NodePayloadAMDX: | |||
There was a problem hiding this comment.
The spec seems to be missing this validation relaxation. Presuming this is intended, I'd suggest updating the extension spec.
| @@ -1594,7 +1596,8 @@ spv_result_t ValidateAccessChain(ValidationState_t& _, | |||
| case spv::Op::OpTypeCooperativeMatrixNV: | |||
| case spv::Op::OpTypeCooperativeMatrixKHR: | |||
| case spv::Op::OpTypeArray: | |||
| case spv::Op::OpTypeRuntimeArray: { | |||
| case spv::Op::OpTypeRuntimeArray: | |||
| case spv::Op::OpTypeNodePayloadArrayAMDX: { | |||
There was a problem hiding this comment.
This would be good to cover in memory test that access chain into a payload array is validated correctly.
| case spv::ExecutionMode::MaxNumWorkgroupsAMDX: | ||
| case spv::ExecutionMode::ShaderIndexAMDX: | ||
| case spv::ExecutionMode::SharesInputWithAMDX: | ||
| case spv::ExecutionMode::StaticNumWorkgroupsAMDX: |
There was a problem hiding this comment.
Again simple tests for the new execution modes being accepted or not by the appropriate version of OpExecutionMode.
| @@ -35,6 +37,7 @@ spv_result_t ValidateUniqueness(ValidationState_t& _, const Instruction* inst) { | |||
|
|
|||
| const auto opcode = inst->opcode(); | |||
| if (opcode != spv::Op::OpTypeArray && opcode != spv::Op::OpTypeRuntimeArray && | |||
| opcode != spv::Op::OpTypeNodePayloadArrayAMDX && | |||
There was a problem hiding this comment.
This would be useful to test.
| } | ||
|
|
||
| std::string NodePayloadArrayAMDX::str() const { | ||
| std::ostringstream oss; |
There was a problem hiding this comment.
Is there a specific reason to use a ossringstream object? Given it's a basic routine which might be frequently called I suppose a str concat should be equivalent and more efficient. More so for smaller string values.
If we do have a need to use the ostringstream class obj perhaps consider reusing it by making it part of the class and clear/reset per use.
|
|
||
| std::string NodePayloadArrayAMDX::str() const { | ||
| std::ostringstream oss; | ||
| oss << "[" << element_type_->str() << "]"; |
There was a problem hiding this comment.
With larger sized strings perhaps using string_view (C++17) is better if a basic str concat is not an option.
The relevant SPIR-V changes are posted in the following PRs: