Compute Shader Integration #3970
Labels
A-Rendering
Drawing game state to the screen
C-Feature
A new feature, making something new possible
C-Usability
A targeted quality-of-life change that makes Bevy easier to use
S-Ready-For-Implementation
This issue is ready for an implementation PR. Go for it!
Comments
kurtkuehnert
added
C-Feature
superdump
added
A-Rendering
|
Agreed. I think we should heavily consider renaming RenderPipelineCache to PipelineCache and extending it to include compute pipelines. Render and Compute pipelines could (and should) both utilize the same LayoutCache and ShaderCache. It would be a pretty nasty UX reduction to break those out / force users to contend with passing them around directly. The only missing piece here is adding a higher level ComputePipelineDescriptor (that largely mirrors our RenderPipelineDescriptor) and wiring that up to the PipelineCache. |
alice-i-cecile
added
the
S-Ready-For-Implementation
|
Sounds reasonable, I will try taking a stab at it . |
Repository owner
moved this from In Review
to Done
in Rendering
Mar 23, 2022
aevyrie
pushed a commit
to aevyrie/bevy
that referenced
this issue
Jun 7, 2022
# Objective - Fixes bevyengine#3970 - To support Bevy's shader abstraction(shader defs, shader imports and hot shader reloading) for compute shaders, I have followed carts advice and change the `PipelinenCache` to accommodate both compute and render pipelines. ## Solution - renamed `RenderPipelineCache` to `PipelineCache` - Cached Pipelines are now represented by an enum (render, compute) - split the `SpecializedPipelines` into `SpecializedRenderPipelines` and `SpecializedComputePipelines` - updated the game of life example ## Open Questions - should `SpecializedRenderPipelines` and `SpecializedComputePipelines` be merged and how would we do that? - should the `get_render_pipeline` and `get_compute_pipeline` methods be merged? - is pipeline specialization for different entry points a good pattern Co-authored-by: Kurt Kühnert <51823519+Ku95@users.noreply.github.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com>
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
# Objective - Fixes bevyengine#3970 - To support Bevy's shader abstraction(shader defs, shader imports and hot shader reloading) for compute shaders, I have followed carts advice and change the `PipelinenCache` to accommodate both compute and render pipelines. ## Solution - renamed `RenderPipelineCache` to `PipelineCache` - Cached Pipelines are now represented by an enum (render, compute) - split the `SpecializedPipelines` into `SpecializedRenderPipelines` and `SpecializedComputePipelines` - updated the game of life example ## Open Questions - should `SpecializedRenderPipelines` and `SpecializedComputePipelines` be merged and how would we do that? - should the `get_render_pipeline` and `get_compute_pipeline` methods be merged? - is pipeline specialization for different entry points a good pattern Co-authored-by: Kurt Kühnert <51823519+Ku95@users.noreply.github.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
For now Bevy does not have a dedicated compute pipeline abstraction, but only exposes the raw wgpu API for this use case.
The game of life example shows how to implement your own compute pipelines.
Currently there is no way to use Bevy's shader abstraction(shader defs, shader imports and hot shader reloading) for compute, which makes writing those shaders quite cumbersome.
What solution would you like?
I would like to have a way of turning a
Handle<Shader>into aShaderModule, which can be use for creating the compute pipeline.For the render pipelines we use a
RenderPipelineCache, which intern stores aShaderCache, for processing the shaders.We probably need something similar for compute pipelines (
ComputePipelineCache), or we decouple theShaderCacheentirely from theRenderPipelineCacheto cache all shaders in a single place (resource).The text was updated successfully, but these errors were encountered: