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

Don't treat StrcturedBuffer<IFoo> as a specializable param. #5645

Merged
merged 3 commits into from
Nov 22, 2024

Conversation

csyonghe
Copy link
Collaborator

@csyonghe csyonghe commented Nov 22, 2024

Fixes #5629.

When we have a StructuredBuffer<IFoo> parameter, we shouldn't treat it as a statically specializable parameter because we never want to directly replace IFoo with any concrete type. Instead we want to always rely on the dynamic dispatch handling logic to insert proper header to maintain data layout consistency.

@csyonghe csyonghe requested a review from a team as a code owner November 22, 2024 18:12
@csyonghe csyonghe added the pr: non-breaking PRs without breaking changes label Nov 22, 2024
Copy link
Collaborator

@jkwak-work jkwak-work left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

I think I have seen it some place before but what does _ST stands for?

@csyonghe
Copy link
Collaborator Author

"_S" is the start of any mangled name.
"T" means the thing being mangled is a type.

@csyonghe csyonghe merged commit 43728fb into shader-slang:master Nov 22, 2024
15 checks passed
@jkwak-work
Copy link
Collaborator

"_S" is the start of any mangled name. "T" means the thing being mangled is a type.

Aha. Thanks for the explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: non-breaking PRs without breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Always add vtable to struct?
2 participants