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

Reorder render sets #8062

Closed
wants to merge 8 commits into from
Closed

Conversation

superdump
Copy link
Contributor

Objective

NOTE: This is a draft because bevy_sprites needs porting over to the new ordering and the batching there needs to be reworked to fit the new ordering. I have done this pre-schedule v3 but need to redo it now after. It will come soon.

  • Reorder render schedule sets to allow data preparation when phase item order is known to support improved batching
  • Part of the batching/instancing etc plan from here: GPU Instancing #89 (comment)
  • The original idea came from @inodentry and proved to be a good one. Thanks!

Solution

  • Move Prepare and PrepareFlush after PhaseSortFlush
  • Add a PrepareAssets set that runs in parallel with other systems and sets in the render schedule.
    • Put prepare_assets systems in the PrepareAssets set
    • If explicit dependencies are needed on Mesh or Material RenderAssets then depend on the appropriate system.
  • Add ManageViews and ManageViewsFlush sets between ExtractCommands and Queue
  • Move queue_mesh*_bind_group to the Prepare stage
    • Rename them to prepare_
    • Put systems that prepare uniform data into a PrepareUniforms set
    • Run the prepare_..._bind_group systems after PrepareUniforms so that all buffers are ready before creating bind groups from them
  • Move prepare_lights to the ManageViews set
    • prepare_lights creates views and this must happen before Queue
    • This system needs refactoring to stop handling all responsibilities
      • Gather lights, sort, and create shadow map views. Store sorted light entities in a resource
      • Prepare buffer data in prepare set

Changelog

Changed:

  • Reordered and reworked render app schedule sets. The main change is that data is extracted, queued, sorted, and then prepared when the order of data is known.

Migration Guide

  • Queue things to phases in the Queue set, prepare data and bind groups in the Prepare set

@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Mar 12, 2023
@superdump superdump added the C-Performance A change motivated by improving speed, memory usage or compile times label Mar 14, 2023
@superdump superdump mentioned this pull request Jul 21, 2023
github-merge-queue bot pushed a commit that referenced this pull request Aug 27, 2023
This is a continuation of this PR: #8062 

# Objective

- Reorder render schedule sets to allow data preparation when phase item
order is known to support improved batching
- Part of the batching/instancing etc plan from here:
#89 (comment)
- The original idea came from @inodentry and proved to be a good one.
Thanks!
- Refactor `bevy_sprite` and `bevy_ui` to take advantage of the new
ordering

## Solution
- Move `Prepare` and `PrepareFlush` after `PhaseSortFlush` 
- Add a `PrepareAssets` set that runs in parallel with other systems and
sets in the render schedule.
  - Put prepare_assets systems in the `PrepareAssets` set
- If explicit dependencies are needed on Mesh or Material RenderAssets
then depend on the appropriate system.
- Add `ManageViews` and `ManageViewsFlush` sets between
`ExtractCommands` and Queue
- Move `queue_mesh*_bind_group` to the Prepare stage
  - Rename them to `prepare_`
- Put systems that prepare resources (buffers, textures, etc.) into a
`PrepareResources` set inside `Prepare`
- Put the `prepare_..._bind_group` systems into a `PrepareBindGroup` set
after `PrepareResources`
- Move `prepare_lights` to the `ManageViews` set
  - `prepare_lights` creates views and this must happen before `Queue`
  - This system needs refactoring to stop handling all responsibilities
- Gather lights, sort, and create shadow map views. Store sorted light
entities in a resource

- Remove `BatchedPhaseItem`
- Replace `batch_range` with `batch_size` representing how many items to
skip after rendering the item or to skip the item entirely if
`batch_size` is 0.
- `queue_sprites` has been split into `queue_sprites` for queueing phase
items and `prepare_sprites` for batching after the `PhaseSort`
  - `PhaseItem`s are still inserted in `queue_sprites`
- After sorting adjacent compatible sprite phase items are accumulated
into `SpriteBatch` components on the first entity of each batch,
containing a range of vertex indices. The associated `PhaseItem`'s
`batch_size` is updated appropriately.
- `SpriteBatch` items are then drawn skipping over the other items in
the batch based on the value in `batch_size`
- A very similar refactor was performed on `bevy_ui`
---

## Changelog

Changed:
- Reordered and reworked render app schedule sets. The main change is
that data is extracted, queued, sorted, and then prepared when the order
of data is known.
- Refactor `bevy_sprite` and `bevy_ui` to take advantage of the
reordering.

## Migration Guide
- Assets such as materials and meshes should now be created in
`PrepareAssets` e.g. `prepare_assets<Mesh>`
- Queueing entities to `RenderPhase`s continues to be done in `Queue`
e.g. `queue_sprites`
- Preparing resources (textures, buffers, etc.) should now be done in
`PrepareResources`, e.g. `prepare_prepass_textures`,
`prepare_mesh_uniforms`
- Prepare bind groups should now be done in `PrepareBindGroups` e.g.
`prepare_mesh_bind_group`
- Any batching or instancing can now be done in `Prepare` where the
order of the phase items is known e.g. `prepare_sprites`

 
## Next Steps
- Introduce some generic mechanism to ensure items that can be batched
are grouped in the phase item order, currently you could easily have
`[sprite at z 0, mesh at z 0, sprite at z 0]` preventing batching.
 - Investigate improved orderings for building the MeshUniform buffer
 - Implementing batching across the rest of bevy

---------

Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
@superdump superdump closed this Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change C-Performance A change motivated by improving speed, memory usage or compile times C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants