You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been prototyping various technical aspects of a voxel space game I am working on. For some systems like large planets I've been experimenting with running mesh shaders in Bevy. Now that wgpu supports mesh shaders I've managed to get this working successfully, but on raw wgpu. This was an interesting experiment, but I'm missing out on several existing systems bevy provides in its rendering pipeline (async compilation, shader hot reload, etc). I would like to help add mesh shader support to bevy as a first class feature, but I need some input on the approach.
From what I can tell, the main piece that needs attention is PipelineCache. PipelineDescriptor and Pipeline enums already support multiple pipeline types. Currently start_create_render_pipeline creates a wgpu::RenderPipeline and start_create_compute_pipeline creates a wgpu::ComputePipeline. In wgpu create_mesh_pipeline returns the same wgpu::RenderPipeline, I can simply add a start_create_mesh_pipeline but I've noticed quite a bit of shared code between the start_create functions on PipelineCache. I could instead refactor to reduce duplication.
If I refactor what approach should I take? I am currently leaning towards a trait (e.g. PipelineCreator) each descriptor type implements this. Each impl declares which shaders it needs and how to build the final wgpu pipeline. Then add PipelineCache::start_create_pipeline. It does all the common work and passes that down to the trait impl which only does the type specific parts.
So to summarize my question. Should I refactor or not and if so, does my trait suggestion pass the sniff test?
Extra Context
From my research both existing start_create functions follow the same structure.
Resolve bind group layouts from the descriptor (shared)
Lock shader cache, look up shader modules (shared) (different shaders per type)
Lock layout cache, build pipeline layout (shared)
Build the raw wgpu descriptor (type-specific)
Call device.create_X_pipeline() (type-specific)
Wrap in async task (shared)
PipelineCache::start_create_pipeline:
clone caches, lock mutexes
resolve bind group layouts
call trait.shader_requests()
resolve those shaders from cache -> compiled shader modules
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I've been prototyping various technical aspects of a voxel space game I am working on. For some systems like large planets I've been experimenting with running mesh shaders in Bevy. Now that wgpu supports mesh shaders I've managed to get this working successfully, but on raw wgpu. This was an interesting experiment, but I'm missing out on several existing systems bevy provides in its rendering pipeline (async compilation, shader hot reload, etc). I would like to help add mesh shader support to bevy as a first class feature, but I need some input on the approach.
From what I can tell, the main piece that needs attention is
PipelineCache.PipelineDescriptorandPipelineenums already support multiple pipeline types. Currentlystart_create_render_pipelinecreates awgpu::RenderPipelineandstart_create_compute_pipelinecreates awgpu::ComputePipeline. In wgpucreate_mesh_pipelinereturns the samewgpu::RenderPipeline, I can simply add astart_create_mesh_pipelinebut I've noticed quite a bit of shared code between thestart_createfunctions onPipelineCache. I could instead refactor to reduce duplication.If I refactor what approach should I take? I am currently leaning towards a trait (e.g.
PipelineCreator) each descriptor type implements this. Each impl declares which shaders it needs and how to build the final wgpu pipeline. Then addPipelineCache::start_create_pipeline. It does all the common work and passes that down to the trait impl which only does the type specific parts.So to summarize my question. Should I refactor or not and if so, does my trait suggestion pass the sniff test?
Extra Context
From my research both existing
start_createfunctions follow the same structure.device.create_X_pipeline()(type-specific)PipelineCache::start_create_pipeline:trait.shader_requests()trait.create_pipeline(device, layout, resolved_shaders)All reactions