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

Explicit interface of entry points #35

Closed
kvark opened this issue Mar 19, 2020 · 2 comments · Fixed by #37
Closed

Explicit interface of entry points #35

kvark opened this issue Mar 19, 2020 · 2 comments · Fixed by #37
Labels
area: middle Intermediate representation kind: question Further information is requested

Comments

@kvark
Copy link
Member

kvark commented Mar 19, 2020

SPIR-V lists all the inputs and outputs for each entry point. The question is whether it's a good idea to represent this somehow in the IR. See gpuweb/gpuweb#592 for WGSL discussion.

Pros for specifying:

  • match SPIR-V
  • easier to translate from IR to anything, since we know the interface

Cons for specifying:

  • more verbose and redundant
  • incomplete - stuff like uniform or storage buffers are also technically the interface, so we still need to go and scan the uses of the globals

Another thought I had is that it doesn't make sense to specify that interface per entry point. It seems like it would make more sense to have for the function.

@kvark kvark added kind: question Further information is requested area: middle Intermediate representation labels Mar 19, 2020
@kvark
Copy link
Member Author

kvark commented Mar 19, 2020

Saying that, it sounds like having the interface in the IR would be useful (i.e. to avoid deriving that over and over each time a module is used). We just need to tweak it a bit. First, by moving it into the Function. Second, instead of listing inputs and outputs, we'd have a Map<Token<GlobalVariable>, GlobalUse>, where:

enum GlobalUse {
  Input,
  Output,
  Constant,
  Storage,
}

@Napokue
Copy link
Collaborator

Napokue commented Mar 20, 2020

I think this is a good idea. Because now, we have to iterate the Globals for far more than necessary. If I understand your proposal correctly, that means that we in theory have to iterate once to know what Globals are used for what purpose. I think that is a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: middle Intermediate representation kind: question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants