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

Expose shader source #68

Merged
merged 2 commits into from
Nov 7, 2024
Merged

Expose shader source #68

merged 2 commits into from
Nov 7, 2024

Conversation

stefnotch
Copy link
Contributor

I needed access to the shader source so that I could create the shader module with a custom label.

And I also wanted access to the source so that I can patch shader functions on the fly.

@ScanMountGoat
Copy link
Owner

I needed access to the shader source so that I could create the shader module with a custom label.

I've found adding a label to just the pipeline to be sufficient for my debugging. If you think setting the module label would be helpful, you could add a separate function that takes a label to the generated code. It should also be possible to just write your own function and avoid using wgsl_to_wgpu for creating the module itself.

And I also wanted access to the source so that I can patch shader functions on the fly.

If you're modifying the shader source at build time, you can just modify the source before passing it to wgsl_to_wgpu. If you need to modify the source at runtime, there's no longer any guarantee that the bindings generated by wgsl_to_wgpu are correct.

@stefnotch
Copy link
Contributor Author

I'm using this for an app that's compiled to WASM, so there's always a bit of "keeping the binary size down". If I use wgsl_to_wgpu, but then need to separately inject the shaders into the binary, then I believe I'd end up with two copies of the shaders.

If you need to modify the source at runtime, there's no longer any guarantee that the bindings generated by wgsl_to_wgpu are correct

There are two cases where currently I do that. One is purely for debug purposes, so it's fine if the guarantees are broken. And the other one is constrained to be "replace a single function's body", which we need for swapping out the underlying "parametric function that maps a 2D value to a 3D coordinate". Demo

Another case is for swapping out const values in a WGSL shaders in places where pipeline-overridable constants cannot be used, due to WGSL restrictions. Examples

I would be more than happy to expose the source as something that's clearly marked as "the user is responsible for the guarantees" or unsafe.

@ScanMountGoat
Copy link
Owner

That makes sense. Does it cover your use cases to just make the shader source public like in this PR?

@stefnotch
Copy link
Contributor Author

Yes, that fully covers my use-cases.

@ScanMountGoat ScanMountGoat merged commit 76ebfc0 into ScanMountGoat:main Nov 7, 2024
1 check passed
@stefnotch
Copy link
Contributor Author

Thank you! Also thank you for maintaining this excellent library!

On a completely different note: Once a WGSL imports project like naga_oil or WESL improves, I'll let you know and hopefully contribute a PR. One that keeps full compatibility with WGSL as-is, and optionally lets users do a bit more.

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.

2 participants