-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[TVM] Fixed SPIR-V codegen incorrectly not declaring the interface for the entry point #1400
Conversation
Thanks for the fix! Here is a possibly better way to do so:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comments
src/codegen/spirv/ir_builder.cc
Outdated
} | ||
|
||
void IRBuilder::CommitKernelFunction(const Value& func_id, const std::string& name) { | ||
//if (uses_workgroup_id) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, noticed those just after committing. They are removed from the latest commit
…r the entry point (apache#1400)
…r the entry point (apache#1400)
The SPIR-V codegen was not generating code compliant with the spec, which was manifesting in all of the vulkan unit tests failing on Windows 10 with a GTX 960 GPU. Specifically, whenever a vulkan kernel was invoked, it would only ever succeed in updating the first element of the input tensor.
This turned out to be due to the codegen not generating the
interface
list ofOpEntryPoint
. For the code that TVM generates, theinterface
list should contain both the workgroup id and the local invocation id. See https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpEntryPoint for details.SPIRV-Tools has recently been updated to detect this situation (see KhronosGroup/SPIRV-Tools#1589), so one way to verify that TVM is generating correct code is to take the output of
get_source
, usespirv-as
to generate a binary SPIR-V file, and then run a recent release ofspirv-val
on the binary file.The fix in this PR does solve the problem, but I'm not sure if it's the best way of addressing this, so I'm definitely open to suggestions on how this could be done better (99% of this PR was tracking down the bug in the first place!)