Skip to content
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

Merged
merged 1 commit into from Jan 15, 2021
Merged

Conversation

jiaolu
Copy link
Contributor

@jiaolu jiaolu commented Dec 25, 2020

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.

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);
Copy link
Member

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).

Copy link
Contributor Author

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

Copy link
Member

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

  1. 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
  2. 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?

Copy link
Contributor Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants