-
Notifications
You must be signed in to change notification settings - Fork 855
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
Add --no-link option to only compile (not link) individual shaders and export all functions #3319
Conversation
288f8e1
to
7e56229
Compare
FYI @jeremyg-lunarg. |
I'll update my code this morning and make sure it works. I don't anticipate this change being a problem. Thanks! |
Works for me locally! I pushed my updated VVL branch to depend on the newest commit. |
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.
Just a few minor questions and comments, but on the whole this looks good to me.
glslang/HLSL/hlslAttributes.cpp
Outdated
@@ -142,6 +142,8 @@ namespace glslang { | |||
return EatUnroll; | |||
else if (name == "loop") | |||
return EatLoop; | |||
else if (name == "export") |
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.
Should this be spv::export or something?
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.
It can. Though, wouldn't it make sense for all of the other strings in here to be constants as well then?
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.
What I meant is that you should put it under the if (nameSpace == "spv")
block so that in the HLSL, the attribute is spelled [spv::export]
.
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.
ah, yes, I should have put it there.
SPIRV/GlslangToSpv.cpp
Outdated
@@ -4329,6 +4340,15 @@ spv::Id TGlslangToSpvTraverser::convertGlslangToSpvType(const glslang::TType& ty | |||
return convertGlslangToSpvType(type, getExplicitLayout(type), type.getQualifier(), false, forwardReferenceOnly); | |||
} | |||
|
|||
spv::LinkageType TGlslangToSpvTraverser::convertGlslangToSpv(glslang::TLinkType linkType) { |
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.
Could you give this function a better name? Given we have GlslangToSpv, convertGlslangToSpv sounds very confusing. Maybe something like glslangToSpvLinkageType?
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.
Yes, my original intent was to merge this with one of the existing convertGlslangToSpvType
, but hadn't found a good way to do that and forgot to circle back. I'll rename it for now.
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.
Does convertGlslangLinkageToSpv
sound ok?
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.
Yeah, that seems like a cromulent name.
@@ -2223,6 +2245,12 @@ void Builder::enterFunction(Function const* function) | |||
defInst->addIdOperand(funcId); | |||
buildPoint->addInstruction(std::unique_ptr<Instruction>(defInst)); | |||
} | |||
|
|||
if (auto linkType = function->getLinkType(); linkType != LinkageTypeMax) { |
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.
I don't know that we have a rule against multiple statements in an if condition, but this is the only place in the codebase such a construct appears. I would prefer you hoist the linkType declaration out.
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.
I can do that if that is the preferred style. In this case, linkType
is only intended to be used within the scope of the if
block here, so using the c++17 "init-statement" went beyond just "style" here IMHO (I do realize we don't use this ubiquitously, presumably since most of the codebase is written pre-c++17).
Name 5 "a" | ||
Name 6 "b" | ||
Name 11 "foo(" | ||
Decorate 7(add(f1;f1;) Linkage Attributes 6579297 0 |
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.
That random constant in there is apparently the name of the exported symbol, unfortunate that it gets printed in such an unreadable way but I don't think it's worth fixing in this change.
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.
Yeah, this is really unreadable. The spirv-dis
output makes a lot more sense:
...
OpName %7 "add(f1;f1;"
...
OpDecorate %7 LinkageAttributes "add" Export
...
%7 = OpFunction %2 None %4
...
I'm not sure how easy this output is to fix for the tests (or the ROI for such a change).
Adds the --no-link option which outputs the compiled shader binaries without linking them. This is a first step towards allowing users to create SPIR-v binary, non-executable libraries. When using the --no-link option, all functions are decorated with the Export linkage attribute.
7e56229
to
d3806f2
Compare
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.
LGTM, thanks.
After internal discussion, we will I'm changing this slightly such that
--no-link
will export all functions, and the ability to export/import individual functions/variables with an attribute will be delayed until such an attribute is standardized.[[export]]/[[import]] attribute proposal (on hold)
This change experiments with adding a "compile-only" option to glslang as well as an `[[export]]` function attribute allowing functions to be exported and then later used by spirv-link.Proposed usage:
Where myfuncs.comp looks something like
And where "foo" and "bar" will get the "Export" linkage decoration in the resulting spir-v.
To be more "complete" this change should also:
[[import]]
attribute for importing functions from another spir-v module[[export]]
/[[import]]
attributes)However, in its current (functional) form, this change could benefit the ongoing improvements to the GPU-AV workflow in Vulkan-ValidationLayers. Before spending anymore time on this, I'm hoping to get some feedback on the overall approach here. I know
[[export]]
/[[import]]
are not official attributes and that may not be the best mechanism for achieving the end goal here (e.g., just exporting all functions when in compile-only mode would work for the purposes of GPU-AV).