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
Support spirv with capability linkage #1110
Conversation
execModelMDs.push_back(ConstantAsMetadata::get(ConstantInt::get(builder->getInt32Ty(), ExecutionModelGLCompute))); | ||
auto execModelMdNode = MDNode::get(*m_context, execModelMDs); | ||
func->addMetadata(gSPIRVMD::ExecutionModel, *execModelMdNode); | ||
func->setDLLStorageClass(GlobalValue::DLLExportStorageClass); |
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.
IIRC @trenouf once said that dllexport
is used to mark shader entry points (i.e. functions that are called by hardware in contrast to functions called by software), so I think this should not be marked as dllexport
(but let’s wait for him to confirm).
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.
spirv with capability linkage is library spirv, hence it can not be the module with hardware entry function.
however we need to get the module information i.e. module shader stage, from entry function.
so i mark that dummy function as DLLExportStorageClass
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, I see.
I think, it makes sense to have no entry function in that case, that would make it clear that there is no entrypoint.
lgc (middle-end) and llvm should be fine without an entrypoint, the shader stage is stored in function metadata in lgc and in the calling convention in llvm.
As far as I can see, the parts that need to be changed are
- the SPIR-V execution model: I guess we can put this onto every function instead of only on entrypoints, similar to how it is done in lgc
- lowering globals currently inserts code in the entrypoint: I think for non-entrypoint modules, this needs to be handled differently anyway. Maybe by moving the global into function arguments?
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.
our lowering pass assume the entry point a lot place in code, to rid of this assumption, i am afraid there are more than a few places to modify and adding code complexity.
It's about trade-off. to add dummy entry point , which you can argue it is a little bit hack, is simple and easy without adding a lot of technical liability.
Spirv with capability linkage does not have entry function, so it is required to create dummy entry function of compute shader stage for this spirv.
Spirv with capability linkage does not have entry function, so it is required to create
dummy entry function of compute shader stage for this spirv.