Tracking Issue: GPU type refactor and bevy_gpu split #7157
Labels
A-Rendering
Drawing game state to the screen
C-Code-Quality
A section of code that is hard to understand or change
X-Controversial
There is active debate or serious implications around merging this PR
There have been discussions about splitting up the
bevy_render
module.As a first and pretty straightforward step, we can refactor our wgpu GPU abstraction into its own crate.
The idea is to pull the entire
render_resources
module with all the wgpu and encase reexports, as well as most of the code of therender
module into the newbevy_gpu
crate.This raises two major design questions:
Naming
The refactor opens up the possibility for more precise and consistent type and variable names.
Currently, we use no prefix for some types (e.g.
Buffer
,ComputePipeline
) or theRender
prefix for the remaining ones (e.g.RenderDevice
,RenderQueue
).I propose three alternatives:
1. Gpu Prefix
Gpu
prefix (e.g.GpuDevice
,GpuBuffer
, etc.)gpu_
prefix for variable names (e.g.gpu_device
,gpu_buffer
, etc.)2. Prefixless
device
,buffer
)3. Hybrid
A quick poll on discord showed that many people are in favor of this change.
Exporting
Additionally, since this refactor is a major breaking change we can reconsider our GPU type reexporting strategy (which was marked with a todo comment: TODO: decide where re-exports should go).
We have got two options:
A. Root Export
bevy::gpu::TypeName
)B. Module Export
render_resource
module and simply rename it togpu_resource
(e.g.bevy::gpu::gpu_resource::TypeName
)Device
,Queue
, etc. to the root levelSolution
Both decisions are unrelated, so we can mix and match.
I think this refactor will take place in two phases.
First, the rename to either one of these three options described above.
Second, the split of all GPU-related types into the bevy_gpu crate and the reconsidered exporting strategy.
We could further subdivide these changes into smaller PRs, but this would break bevy main multiple times, and would probably confuse a lot of our users.
I prototyped phase one for both the
Gpu Prefix
in #6968 and thePrefixless
alternative in #7109.Based on that, phase two is implemented in PRs #7000 (
Gpu Prefix
&Module Export
) and #7111 (Prefixless
&Root Export
).Let me know which propositions you like the most, or which alternatives I have not considered yet.
Please vote for your preferred strategy in this GitHub poll: #7169.
The text was updated successfully, but these errors were encountered: