ShaderModule::single_entry_point() #2301
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Almost all of your userbase* will have a single glsl file, containing a single shader, generating a single
*.spv
file which contains the sole entry pointmain
. And it's loaded like this:I'm annoyed at constantly having to write that the entry point is
main
. I know there is only a single entry point in that file, so just give me that one, without me having to writemain
every time. This PR adds a function just for that, simplifying the code above to:rust-gpu, or why I actually wanted this
Rust-gpu by default compiles all shaders into a single
*.spv
with varying entry points. However yourshader!
macro does not like that, so typically users will turn on "multimodule" which generates one*.spv
per shader. But the entry point name will still be the rust module path to the shader function, eg.renderer::lodobj::vs
, and specifying that is even more annoying. I've solved it by codegening all theshader!
macro calls in the build script, where I have access to both the spv file path and entry point name, so I won't benefit from this PR anymore, but others using glsl will probably like this as well.Testing
The other entry_point() methods are only covered by unit-tests through shader cache tests. And with the shader! macro not being available in tests it seems pretty difficult to automatically test.
So I've just reverted to manually testing the
single_entry_point
method in the triangle example, but testing thesingle_entry_point_of_execution
may prove difficult as glslc will not generate an spv with multiple entry points from what I can tell.Checklist
Update documentation to reflect any user-facing changes - in this repository.
Make sure that the changes are covered by unit-tests.
See Testing
Run
cargo fmt
on the changes.Please put changelog entries in the description of this Pull Request
if knowledge of this change could be valuable to users. No need to put the
entries to the changelog directly, they will be transferred to the changelog
file by maintainers right after the Pull Request merge.
Please remove any items from the template below that are not applicable.
Describe in common words what is the purpose of this change, related
Github Issues, and highlight important implementation aspects.
Changelog: