Skip to content

Requiring mutable access to several common shared types prevents queue phase parallelization. #3548

Open
@james7132

Description

What problem does this solve or what need does it fill?

Query<&mut RenderPhase<T>>, RenderPipelineCache, SpecializedPipelines (to a lesser degree) requires mutable access to use. Each of these can limit the parallelism of the queue phase when rendering.

  • Query<&mut RenderPhase<T>> limits it to one system per phase at a time. Generally allows parallelism across mutliple phases at the same time, unless there is one system that requires access to multiple render phases.
  • RenderPipelineCache limits any dependent pipeline from parallelizing.
  • SpecializedPipelines limits parallelization across multiple phases within a single extract-prepare-queue pipeline. This is less of an issue than the other two.

What solution would you like?

  • Merge SpecializedPipelines functionality into RenderPipelines and make it generic over a SpecializedPipeline. This removes the global pipeline cache as a blocking requirement. Might also improve the ergonomics of writing those kinds of systems.
  • Switch any/all of the associated types to use internal mutability. Most notably RenderPhase<T> might benefit the most from this. Adding mutexes may be too much of a cost here. Perhaps a good place to try out lock-free data structures? Worth benchmarking.

What alternative(s) have you considered?

  • Recreate render pipelines on every executions.
  • Limit time in each queue job by aggressively batching it's inputs in the prepare phase.

Metadata

Assignees

No one assigned

    Labels

    A-RenderingDrawing game state to the screenC-PerformanceA change motivated by improving speed, memory usage or compile times

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions