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.

Sign up for GitHub

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

Jump to bottom

[Merged by Bors] - fix ambiguities in render schedule #7725

Closed
wants to merge 1 commit into from
Closed

[Merged by Bors] - fix ambiguities in render schedule #7725

wants to merge 1 commit into from

Conversation

jakobhellermann
Copy link
Contributor

Objective

  • ambiguities bad

Solution

  • solve ambiguities
    • by either ignoring (e.g. on queue_mesh_view_bind_groups since LightMeta access is different)
    • by introducing a dependency (prepare_windows -> prepare_* because the latter use the fallback Msaa)
  • make prepare_assets public so that we can do a proper .after

@jakobhellermann jakobhellermann added C-Bug An unexpected or incorrect behavior A-Rendering Drawing game state to the screen labels Feb 17, 2023
@jakobhellermann
Copy link
Contributor Author

comment from @superdump on discord:

view targets and assets are unrelated, windows/prepass/depth on msaa should be unrelated as they should all use the same msaa value - the one that was extracted. Did just merge the fallback to 4x if 2x or 8x are not supported though and that fallback behaviour needs to be consistent across them so the same number of MSAA samples are used everywhere else it will break. Meshes and sprites on transparent 2D is fine - they just queue up sprites or meshes to the phase. Doesn’t matter which come first as they will anyway be sorted. Mesh and shadow view bind groups, hmm, I would think they’re reading common data or modifying disjoint data but I’d have to check

msaa should be unrelated

The fallback only writes the fallback in prepare_windows and just reads Res<Msaa> in the other prepare systems, so I think the ordering here is needed.

superdump
superdump approved these changes Feb 20, 2023
View reviewed changes
Copy link
Contributor

@superdump superdump left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors r+

bors bot pushed a commit that referenced this pull request Feb 20, 2023
@jakobhellermann
fix ambiguities in render schedule (#7725)
1936844 
# Objective

- ambiguities bad

## Solution

- solve ambiguities
  - by either ignoring (e.g. on `queue_mesh_view_bind_groups` since `LightMeta` access is different)
  - by introducing a dependency (`prepare_windows -> prepare_*` because the latter use the fallback Msaa)
- make `prepare_assets` public so that we can do a proper `.after`
@bors
Copy link
Contributor

bors bot commented Feb 20, 2023

Pull request successfully merged into main.

Build succeeded:

@bors bors bot changed the title fix ambiguities in render schedule [Merged by Bors] - fix ambiguities in render schedule Feb 20, 2023
@bors bors bot closed this Feb 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@superdump superdump superdump approved these changes

Assignees
No one assigned
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@jakobhellermann @superdump