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

Initial RenderState of Renderer differs from GlDevice initial state #412

Closed
flodiebold opened this issue Oct 17, 2014 · 3 comments
Closed

Initial RenderState of Renderer differs from GlDevice initial state #412

flodiebold opened this issue Oct 17, 2014 · 3 comments
Labels
difficulty: easy type: bug

Comments

@flodiebold
Copy link
Contributor

As the comment for RenderState::new says, its result should give the state the device gets put in by reset_state. But that's not currently true, since DrawState::new enables backface culling, while RESET_CB in the gl_device disables it. The result is that backface culling is not actually enabled until it is first disabled and then enabled again after a reset. Either RenderState::new or DrawState::new needs to be changed.
@flodiebold flodiebold mentioned this issue Oct 17, 2014
Closed
@kvark
Copy link
Member

kvark commented Oct 17, 2014

Thanks for the report!

@bvssvni
Copy link
Contributor

bvssvni commented Oct 31, 2014

It seems Gfx enables drawing on both sides by default now, because the piston-gfx_cube example shows both sides. Does this means this is fixed?

@bvssvni
Copy link
Contributor

bvssvni commented Oct 31, 2014

Just adding a link to see when this gets closed PistonDevelopers/gfx_graphics#82

emberian added a commit to emberian/gfx-rs that referenced this issue Nov 7, 2014
@emberian
Make initial render states agree
6b2c8bd 
Fixes gfx-rs#412
@kvark kvark mentioned this issue Nov 7, 2014
Merged
adamnemecek pushed a commit to adamnemecek/gfx that referenced this issue Apr 1, 2021
@bors @kvark
Merge gfx-rs#412
8f42ba6 
412: Another big tracking refactor r=later a=kvark

Fixes gfx-rs#409
Note: there is way more code that had to be thrown out in the process of this PR than there is in the PR itself.
Also fixes [this comment](https://github.com/gfx-rs/wgpu/blob/04e17b3f4fe44d816cebeadc0e89bf588cfefe70/wgpu-core/src/track/texture.rs#L29):
> //TODO: make this less awkward!

## Logic
Instead of having a run-time per-operation control over what state is being used for stitching (with `Stitch` enum), we are now deriving this automatically on a per-subresource level. Whenever we are detecting a transition for a sub-resource, and we know there wasn't any "first" state associated with it in the current tracker, we are saving this "first" state. Unlike previous code, where it was confusing what of `Unit` fields (`init`, `last`) are valid, now `first` is `Option<>`, so we know we should be using it if it's there.

This allows us to have this hybrid tracking state of a render pass, where all resources are immutable (and their usage is extended), except for the output attachments. This, together with a whole lot of refactoring, gets us gfx-rs#409.

I'm actually quite happy with the tracking code now. It's finally taking shape we aren't afraid to tell others about :)

Note: this was tested on wgpu-rs examples and vange-rs.

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
difficulty: easy type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kvark @emberian @flodiebold @bvssvni