Skip to content

Conversation

@hrydgard
Copy link
Owner

Turns out just doing a Clear doesn't work in GoW. So made the rendermanager convert to a clear if appropriate directly, instead of leaving it to the queuerunner to clean up - easier to tell what's going on. Also had to dirty some state, but I'll fix that in a better way in an upcoming commit.

hrydgard added 2 commits May 21, 2020 11:54
…ve due to the use of clear.

Also instantly convert to a clear when binding the framebuffer in cases
when we know it's the optimal thing. The QueueRunner would have later merged
anyway hopefully, but I like the simplicity of this.
@hrydgard hrydgard added this to the v1.10.0 milestone May 21, 2020
draw_->Clear(Draw::FBChannel::FB_COLOR_BIT | Draw::FBChannel::FB_STENCIL_BIT, 0, 0.0f, 0);
// We have to bind here instead of clear, since it can be that no framebuffer is bound.
// The backend can sometimes directly optimize it to a clear.
draw_->BindFramebufferAsRenderTarget(vfb->fbo, { Draw::RPAction::CLEAR, Draw::RPAction::KEEP, Draw::RPAction::CLEAR }, "ReformatFramebuffer");
Copy link
Collaborator

Choose a reason for hiding this comment

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

It was reported somewhere that there can be bugs when depthAction != stencilAction in some drivers. Not sure how worried to be.

-[Unknown]

Copy link
Owner Author

Choose a reason for hiding this comment

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

Right, but we might want to take care of that in the RenderManager instead in that case... Hm.

@unknownbrackets unknownbrackets merged commit 6ad9cb9 into master May 21, 2020
@hrydgard hrydgard deleted the vulkan-more-framebuffer-stuff branch May 21, 2020 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants