From 33630fc012070ef3f4697bda93acd43cb729629a Mon Sep 17 00:00:00 2001 From: Jim Van Verth Date: Wed, 22 Apr 2020 17:21:49 -0400 Subject: [PATCH] Implement GrMtlOpsRenderPass::onClear. In certain corner cases the RenderTargetContext can end up injecting a clear op into the op stream, so we need to handle that. Bug: skia:10163 Change-Id: I57722d335bbc59bb9f0a767f774a4620dfde3f39 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/284878 Commit-Queue: Jim Van Verth Reviewed-by: Chinmay Garde Reviewed-by: Michael Ludwig --- src/gpu/mtl/GrMtlOpsRenderPass.mm | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/gpu/mtl/GrMtlOpsRenderPass.mm b/src/gpu/mtl/GrMtlOpsRenderPass.mm index 80980e51e0..576a1349c3 100644 --- a/src/gpu/mtl/GrMtlOpsRenderPass.mm +++ b/src/gpu/mtl/GrMtlOpsRenderPass.mm @@ -124,10 +124,15 @@ bool GrMtlOpsRenderPass::onBindTextures(const GrPrimitiveProcessor& primProc, } void GrMtlOpsRenderPass::onClear(const GrFixedClip& clip, const SkPMColor4f& color) { - // We should never end up here since all clears should either be done as draws or load ops in - // metal. If we hit this assert then we missed a chance to set a load op on the - // GrRenderTargetContext level. - SkASSERT(false); + // Ideally we should never end up here since all clears should either be done as draws or + // load ops in metal. However, if a client inserts a wait op we need to handle it. + fRenderPassDesc.colorAttachments[0].clearColor = + MTLClearColorMake(color[0], color[1], color[2], color[3]); + fRenderPassDesc.colorAttachments[0].loadAction = MTLLoadActionClear; + this->precreateCmdEncoder(); + fRenderPassDesc.colorAttachments[0].loadAction = MTLLoadActionLoad; + fActiveRenderCmdEncoder = + fGpu->commandBuffer()->getRenderCommandEncoder(fRenderPassDesc, nullptr, this); } void GrMtlOpsRenderPass::onClearStencilClip(const GrFixedClip& clip, bool insideStencilMask) {