Don't assert mips actually need resolve during texResolveRenderTask
Too many exceptions can arise during flush in which the mips won't
actually be marked dirty: Failed to flush GL state, Ops that don't
actually issue any draws, etc. Since the DAG can't and shouldn't
predict these rare exceptions, we just remove the assert.
Bug: skia:
Change-Id: I41cd802f226388fca3762736f15b529efb69a3a1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/238166
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
diff --git a/src/gpu/GrOpsTask.h b/src/gpu/GrOpsTask.h
index b9398b8..d346f1f 100644
--- a/src/gpu/GrOpsTask.h
+++ b/src/gpu/GrOpsTask.h
@@ -101,17 +101,12 @@
private:
bool isNoOp() const {
- // TODO: GrLoadOp::kDiscard -> [empty OpsTask] -> GrStoreOp::kStore should also be a no-op.
- // We don't count it as a no-op right now because of Vulkan. There are real cases where we
- // store a discard, and if we skip that render pass, then the next time we load the render
- // target, Vulkan detects loading of uninitialized memory and complains. If we don't skip
- // storing the discard, then we trick Vulkan and it doesn't notice us doing anything wrong.
- // We should definitely address this issue properly.
+ // TODO: GrLoadOp::kDiscard (i.e., storing a discard) should also be grounds for skipping
+ // execution. We currently don't because of Vulkan. See http://skbug.com/9373.
//
// TODO: We should also consider stencil load/store here. We get away with it for now
// because we never discard stencil buffers.
- return fOpChains.empty() && GrLoadOp::kClear != fColorLoadOp &&
- GrLoadOp::kDiscard != fColorLoadOp;
+ return fOpChains.empty() && GrLoadOp::kLoad == fColorLoadOp;
}
void deleteOps();