Hi Greg, cold you please take a look? Thanks.

I tried looking at this a little. I can reproduce it but I'm not seeing anything jump out immediately that is wrong. Do you know internally what chrome is trying to do when this crashes usually? Also when did this start failing? Do you have any sort of bisect.

I may be slow to really get a deep dive into this as there are numerous other things on my plate as well, so any additional debugging into the problem like what chrome is doing that eventually causes this crash would be very helpful.

Specifically I am wondering if the crash is always happening when we are trying to destroying an object on the DDL thread with the recording GrContext, or if it happens even on the main thread with the main GrContext

I remember I only found this crash happen on ddl thread when destroy a sk object. I will confirm it next Monday.

Okay so the general problem is the following. A promise SkImage gets created on a DDL recording thread, and is stored in SkiaRenderer. We then finish the DDL, and flush on the main thread. During the flush the GrTexture that is backing the promise SkImage gets instantiated and thus put in our GrResourceCache of the main GrContext. After the draw using that GrTexture we release all refs accept the one held by the SkImage.

When we start recording the next frame, we release this SkImage which ends up calling the release of the GrTexture. If this release happens at the same time as the main gpu thread is accessing the GrResourceCache we get the asserts that we're seeing.

In this specific case, the main culprit is caused by current_paint_ in SkiaRenderer. When we add a ShaderMaskFilter to it, the paint stores a ref to the SkImage for the shader. If this is the last draw of the frame, we will keep this ref on the paint till the next frame when we call reset() in DoDrawQuad.

Hacking around there may be two possible immediate fixes for the current crash. First would be to call current_paint_.reset() in FinishDrawingQuadList() where we clear the promise images. I'm guessing you're clearing the promise images here for the same reason?

The second would be to not have current_paint_ be a member variable but instead just create a local stack paint in DoDrawQuad and pass the paint to the helper Draw calls. Since you're always resetting paint in DoDrawQuad I think this is the better approach and I don't believe you're gaining any performance by having current_paint_ be a member. This approach also makes it so you don't need to make sure FinishDrawingQuadList is always called at the timing you want.

Passing this back to penghuang@ to decide on which fix to go with.

In the mean time on the Skia side we need to think about how to make this part of the system smoother. It doesn't not seem good that the client of DDLs needs to know that it should not keep SkImage refs around. Especially since the failure case is not obvious to the client that behind their back the SkImage got instantiated into our ResourceCache so that depending on when they release the SkImage ref different side effects may happen.

Resetting current_paint_ does fix the issue. Thanks.
BTW, do we have a bug for tracking the skia side issue?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e300850ab6c167dba87d3b9d138edc23d0541e60

commit e300850ab6c167dba87d3b9d138edc23d0541e60
Author: Peng Huang <penghuang@chromium.org>
Date: Mon Nov 19 20:54:38 2018

Fix SkiaRenderer + DDL related crash.

Skia has a problem to with GrResourceCache. This CL workaround the issue
by not keep a SkPaint object during frames.

Bug:  905337 
Change-Id: I0f44eb7502d41cd54015fe651a373d8bae65fda8
Reviewed-on: https://chromium-review.googlesource.com/c/1342501
Commit-Queue: Peng Huang <penghuang@chromium.org>
Reviewed-by: weiliangc <weiliangc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609426}
[modify] https://crrev.com/e300850ab6c167dba87d3b9d138edc23d0541e60/components/viz/service/display/skia_renderer.cc
[modify] https://crrev.com/e300850ab6c167dba87d3b9d138edc23d0541e60/components/viz/service/display/skia_renderer.h

 Issue 907694  has been merged into this issue.

The assert here is most likely he same since between this original bug and the dup'd in bug we added the assert in Skia to know if two threads are hitting the resource cache at the same time.

The  issue 907694  looks to be a related crash which is caused by the unrefing during clear call in FinishDrawingQuadList. Is there a chance that the list of promiseImages that gets cleared here has an Image on them that is cached somewhere that causes it to live longer than when we flush the DDL into the main GrContext?

My first look it seems like the actual promiseImage list is only built up during recording and cleared before drawing the DDL, but if one of its images is cached elsewhere as well it could cause a similar error.

Is there some instrumentation I should add? The crash in  issue 907694  reproduces almost immediately.

By instrumentation are you talk about debugging? I guess I would try to see which SkImage in the promise_image_ map is causing the problems when we call clear and then backtrace to where it was made and who holds refs to it. We need to make sure the DDL thread/context doesn't ever hold the last ref to an SkImage after that SkImage was used in a DDL that was drawn. The easiest way to do this is for the DDL context to release all SkImage before it was drawn.

Additionally this could happen if you are creating a gpu texture backed SkImage without using promise images, add that to the DDL context promise_images_, and then clear it. But I think for this case you'd have to clear that array without actually drawing that SkImage into the DDL (since the DDL itself should hold a ref), so I'm not sure why it would be in the promise_image_ array in this case.

Here's one owner, per GrSingleOwner:

#01: pc 0x4a7ddeadb84c sp 0xf0d457a1008 (libc.so,0x1684c)
#02: sk_abort_no_print() at SkMemory_new_handler.cpp:?
#03: GrSingleOwner::enter() at GrContext.cpp:?
#04: GrResourceCache::notifyCntReachedZero(GrGpuResource*, unsigned int) at GrResourceCache.cpp:?
#05: GrGpuResource::notifyRefCountIsZero() const at GrGpuResource.cpp:?
#06: sk_sp<GrTextureProxy>::~sk_sp() at SkGpuBlurUtils.cpp:?
#07: SkImage_Gpu::~SkImage_Gpu() at SkImage_Gpu.cpp:?
#08: SkRefCntBase::unref() const at paint_canvas_video_renderer.cc:?
#09: sk_sp<SkImage>::~sk_sp() at paint_canvas_video_renderer.cc:?
#10: base::internal::flat_tree<unsigned int, std::__1::pair<unsigned int, sk_sp<SkImage> >, base::internal::GetKeyFromValuePairFirst<unsigned int, sk_sp<SkImage> >, std::__1::less<void> >::clear() at skia_renderer.cc:?
#11: viz::SkiaRenderer::FinishDrawingQuadList() at skia_renderer.cc:?
#12: viz::DirectRenderer::DrawRenderPass(viz::RenderPass const*) at direct_renderer.cc:?
#13: viz::DirectRenderer::DrawRenderPassAndExecuteCopyRequests(viz::RenderPass*) at direct_renderer.cc:?
#14: viz::DirectRenderer::DrawFrame(std::__1::vector<std::__1::unique_ptr<viz::RenderPass, std::__1::default_delete<viz::RenderPass> >, std::__1::allocator<std::__1::unique_ptr<viz::RenderPass, std::__1::default_delete<viz::RenderPass> > > >*, float, gfx::Size const&) at direct_renderer.cc:?
#15: viz::Display::DrawAndSwap() at display.cc:?
#16: viz::DisplayScheduler::DrawAndSwap() at display_scheduler.cc:?
#17: viz::DisplayScheduler::OnBeginFrameDeadline() at display_scheduler.cc:?
#18: base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) at task_annotator.cc:?
#19: base::MessageLoopImpl::RunTask(base::PendingTask*) at message_loop_impl.cc:?
#20: base::MessageLoopImpl::DoWork() at message_loop_impl.cc:?
#21: base::MessagePumpDefault::Run(base::MessagePump::Delegate*) at message_pump_default.cc:?
#22: base::MessageLoopImpl::Run(bool) at message_loop_impl.cc:?
#23: base::RunLoop::Run() at run_loop.cc:?
#24: base::Thread::Run(base::RunLoop*) at thread.cc:?
#25: base::Thread::ThreadMain() at thread.cc:?
#26: base::(anonymous namespace)::ThreadFunc(void*) at platform_thread_posix.cc:?
#27: pc 0x4a7ddeadc606 sp 0xf0d457a2fd0 (libc.so,0x17606)
#28: pc 0x4a7ddeb4ba41 sp 0xf0d457a2fe0 (libc.so,0x86a41)
#29: pc 0 sp 0xf0d457a3000

Here's the other owner:

#00: base::debug::StackTrace::StackTrace(unsigned long) at stack_trace_fuchsia.cc:?                                                                                
#01: GrSingleOwner::enter() at GrContext.cpp:?                                                                                                                    
#02: GrContext::flush() at GrContext.cpp:?                                                                                                                         
#03: viz::SkiaOutputSurfaceImplOnGpu::FinishPaintCurrentFrame(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList> >, unsigned long) at
 skia_output_surface_impl_on_gpu.cc:?                                    
#04: void base::internal::FunctorTraits<void (viz::SkiaOutputSurfaceImplOnGpu::*)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList>
>, unsigned long), void>::Invoke<void (viz::SkiaOutputSurfaceImplOnGpu::*)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList> >, unsi
gned long), viz::SkiaOutputSurfaceImplOnGpu*, std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList> >, unsigned long>(void (viz::SkiaOut
putSurfaceImplOnGpu::*)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList> >, unsigned long), viz::SkiaOutputSurfaceImplOnGpu*&&, std
::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkDeferredDisplayList> >&&, unsigned long&&) at skia_output_surface_impl.cc:?
#05: void base::internal::Invoker<base::internal::BindState<void (viz::SkiaOutputSurfaceImplOnGpu::*)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<SkD
eferredDisplayList> >, unsigned long), base::internal::UnretainedWrapper<viz::SkiaOutputSurfaceImplOnGpu>, std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delet
e<SkDeferredDisplayList> >, unsigned long>, void ()>::RunImpl<void (viz::SkiaOutputSurfaceImplOnGpu::*)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1::default_delete<S
kDeferredDisplayList> >, unsigned long), std::__1::tuple<base::internal::UnretainedWrapper<viz::SkiaOutputSurfaceImplOnGpu>, std::__1::unique_ptr<SkDeferredDisplayList, std::
__1::default_delete<SkDeferredDisplayList> >, unsigned long>, 0ul, 1ul, 2ul>(void (viz::SkiaOutputSurfaceImplOnGpu::*&&)(std::__1::unique_ptr<SkDeferredDisplayList, std::__1:
:default_delete<SkDeferredDisplayList> >, unsigned long), std::__1::tuple<base::internal::UnretainedWrapper<viz::SkiaOutputSurfaceImplOnGpu>, std::__1::unique_ptr<SkDeferredD
isplayList, std::__1::default_delete<SkDeferredDisplayList> >, unsigned long>&&, std::__1::integer_sequence<unsigned long, 0ul, 1ul, 2ul>) at skia_output_surface_impl.cc:?
#06: base::OnceCallback<void ()>::Run() && at layout_test.mojom.cc:?
#07: gpu::Scheduler::RunNextTask() at scheduler.cc:?
#08: base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) at task_annotator.cc:?
#09: base::MessageLoopImpl::RunTask(base::PendingTask*) at message_loop_impl.cc:?
#10: base::MessageLoopImpl::DoWork() at message_loop_impl.cc:?
#11: base::MessagePumpFuchsia::Run(base::MessagePump::Delegate*) at message_pump_fuchsia.cc:?
#12: base::MessageLoopImpl::Run(bool) at message_loop_impl.cc:?
#13: base::RunLoop::Run() at run_loop.cc:?
#14: content::GpuMain(content::MainFunctionParams const&) at gpu_main.cc:?
#15: content::ContentMainRunnerImpl::Run(bool) at content_main_runner_impl.cc:?
#16: service_manager::Main(service_manager::MainParams const&) at main.cc:?
#17: content::ContentMain(content::ContentMainParams const&) at content_main.cc:?
#18: main at shell_main.cc:?

Can you describe how this is expected to work? We're not clearing the map until after the callback is posted, so it doesn't seem surprising that it may have already started running.

So when I say DDL thread I mean the thread that is recording the DDL. I'm not sure what chrome calls them. So there may be a bunch of DDL threads that are recording DDLs and then a single thread with the main GrContext that the DDLs are drawn into. Each thread has its own GrContext, but only the main thread has a GrContext that has a GrResourceCache (basically the cache of GPU textures). So on the DDL recording threads the SkImages are typically just backed by a GrTextureProxy that has been instantiated to hold a real GPU texture yet. When we draw the DDL into the main context/thread, we instantiate those proxies via the PromiseImage apis. Once instantiate those textures live in the GrResourceCache of the main thread.

Now if you have an SkImage that is backed by a GPU texture (which is our typical case), if that texture has been instantiated and the SkImage happens to have the last ref to the texture (would happen if all draws that use the SkImage have already been flushed), when you release the SkImage it will release the texture and we will delete it from our ResourceCache. So now the issue is that our GrResourceCache is not thread safe. So we can only have one thread access it at once. So if the SkImage gets released on a DDL thread after it has been instantiated there is a chance that it will cause the Texture to be removed from the ResourceCache. But if the main thread happens to be using the resource cache at the same time (not necessarily even for that texture), we hit the assert you are seeing.

So in the current system the general approach is that make sure you are not holding onto any SkImages in non main threads that may have been instantiated. If you are only using PromiseImages then this means creating new PromiseImages for each new DDL and then releasing the refs of those SkImages before drawing the DDL (and any objects that may be holding refs to images).

We understand that this is really annoying for the clients so we have plans to try to improve this system to alleviate some of these restrictions (specifically not being able to release images on arbitrary threads). However, I'm not sure what the time table is for improving this fully. A shorter term change may just improve this for Promise and Wrapped images.

Adding bsalomon who probably will be the person who will look into this.

Hi spang@ I uploaded a CL (https://crrev/c/1351266) to workaround the racing issue. Could you please try it? Thanks.

I'm still getting the lay of the land here (unfortunately the expert on this stuff is on leave for a while). I think the bug is that Skia should be cleaning up the GrTexture object when a DDL is flushed but for some reason that isn't happening. So the SkImage retains a (indirect) ref on it and then goes boom when the image and therefore the GrTexture is unreffed on the DLL producing thread.

@18

With https://crrev/c/1351266 it has not crashed yet, thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ce48cf76141dac6cd5de72034096cd00cd57f6fa

commit ce48cf76141dac6cd5de72034096cd00cd57f6fa
Author: Peng Huang <penghuang@chromium.org>
Date: Thu Nov 29 20:20:28 2018

Workaround skia promise image release racinqg issue

Bug:  905337 
Change-Id: I14e4188def4719f0b04151bf9d76731a46889612
Reviewed-on: https://chromium-review.googlesource.com/c/1351266
Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#612334}
[modify] https://crrev.com/ce48cf76141dac6cd5de72034096cd00cd57f6fa/components/viz/service/display/skia_renderer.cc

The problem has been workarounded in chrome. Mark it as fixed.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/577aa0fbaf67f81cd0004fa3186721cb2b60c85a

commit 577aa0fbaf67f81cd0004fa3186721cb2b60c85a
Author: Brian Salomon <bsalomon@google.com>
Date: Fri Nov 30 19:01:03 2018

Uninstantiate proxies when not explicitly allocating

Bug:  chromium:905337 
Change-Id: I1a105fa3048ead84d202f6c6225d1247c1a70258
Reviewed-on: https://skia-review.googlesource.com/c/173431
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>

[modify] https://crrev.com/577aa0fbaf67f81cd0004fa3186721cb2b60c85a/tests/ResourceAllocatorTest.cpp
[modify] https://crrev.com/577aa0fbaf67f81cd0004fa3186721cb2b60c85a/src/gpu/GrResourceAllocator.cpp
[modify] https://crrev.com/577aa0fbaf67f81cd0004fa3186721cb2b60c85a/src/gpu/GrDrawingManager.cpp
[modify] https://crrev.com/577aa0fbaf67f81cd0004fa3186721cb2b60c85a/src/gpu/GrResourceAllocator.h

It turns out that promise SkImages *should* be able to be destroyed on the producer thread. However, we had a bug in Skia (fixed by above change) that was triggered when this change landed:

https://chromium.googlesource.com/chromium/src/+/42c8a1ddda754e566139ab90c18ad2b2682f731d

That change made it so that the GrContext was no longer created with the "explicit allocation" flag which triggered the bug.

So, going forward (once this rolls into Chrome) it should be possible to keep SkImages around and reuse them across DDLs or just unref them lazily in the producer thread without worrying about doing so before the DDL is executed or destroyed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8869ba9507397f8234dfd7c6fb517f2a3bae9976

commit 8869ba9507397f8234dfd7c6fb517f2a3bae9976
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Mon Dec 03 17:08:35 2018

Roll src/third_party/skia e6305f38b584..b13658891bbd (60 commits)

https://skia.googlesource.com/skia.git/+log/e6305f38b584..b13658891bbd


git log e6305f38b584..b13658891bbd --date=short --no-merges --format='%ad %ae %s'
2018-12-03 michaelludwig@google.com Revert "Send max coverage limit for subpixel rects"
2018-12-03 egdaniel@google.com Revert "Add support for Ycbcr Conversion Samplers in vulkan."
2018-12-03 egdaniel@google.com Add support for Ycbcr Conversion Samplers in vulkan.
2018-12-03 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 4abdf74f0afc..35cd7332ab62 (1 commits)
2018-12-03 brianosman@google.com Revert "Share GP implementation between GrFillRectOp and GrTextureOp"
2018-12-03 caryclark@skia.org add breaktext doc skeleton
2018-12-03 skia-bookmaker@skia-swarming-bots.iam.gserviceaccount.com Update markdown files
2018-12-03 skia-recreate-skps@skia-swarming-bots.iam.gserviceaccount.com Update go_deps asset
2018-12-03 reed@google.com breakText on font
2018-12-02 reed@google.com start to use font for measure, not paint
2018-12-02 skia-recreate-skps@skia-swarming-bots.iam.gserviceaccount.com Update SKP version
2018-12-02 skia-bookmaker@skia-swarming-bots.iam.gserviceaccount.com Update markdown files
2018-12-02 skia-recreate-skps@skia-swarming-bots.iam.gserviceaccount.com Update go_deps asset
2018-12-01 reed@google.com don't trust convexity after a transform
2018-12-01 skia-recreate-skps@skia-swarming-bots.iam.gserviceaccount.com Update go_deps asset
2018-12-01 fmalita@chromium.org [skottie] Expose composition markers to embedders
2018-12-01 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 317a9ebdb019..4abdf74f0afc (2 commits)
2018-11-30 bsalomon@google.com Fix occurrences of "-Wextra-semi-stmt"
2018-11-30 reed@google.com experimental alternative isconvex
2018-11-30 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/swiftshader bffee5e5454c..bd49ad09c5ca (1 commits)
2018-11-30 bungeman@google.com Remove FontScalerTest sample.
2018-11-30 halcanary@google.com SkQP: doc simplify, make_apk_list to python, upload_apk tool
2018-11-30 michaelludwig@google.com Share GP implementation between GrFillRectOp and GrTextureOp
2018-11-30 michaelludwig@google.com Send max coverage limit for subpixel rects
2018-11-30 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/swiftshader d46faeb43287..bffee5e5454c (1 commits)
2018-11-30 bungeman@google.com Set mac windows to their current size.
2018-11-30 kjlubick@google.com [canvaskit] Save a copy on CPU backend by using RasterDirect
2018-11-30 bsalomon@google.com Uninstantiate proxies when not explicitly allocating
2018-11-30 herb@google.com Expand handling of empty glyphs to SDF and Path cases
2018-11-30 bungeman@google.com Fix new clang warning around shadowing.
2018-11-30 kjlubick@google.com [canvaskit] Fix conversion of large images to base64
2018-11-30 halcanary@google.com SkQP: refatctor C++ bits.
2018-11-30 herb@google.com Make SkGlyph::PathData own the path
2018-11-30 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 b51eb09fb5bb..317a9ebdb019 (1 commits)
2018-11-30 egdaniel@google.com Add blacklist for intel 405 vulkan perf bot.
2018-11-30 herb@google.com Make path position handling consistant with SDF
2018-11-30 brianosman@google.com Add SkEncodedOrigin to SkYUVASizeInfo, fix JPEG orientation in GPU decode path
2018-11-30 reed@google.com update docs around fonthinting
2018-11-30 kjlubick@google.com [canvaskit] Add gradients and clips
2018-11-30 skia-recreate-skps@skia-swarming-bots.iam.gserviceaccount.com Update go_deps asset
2018-11-30 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 8dc27f99b556..b51eb09fb5bb (5 commits)
2018-11-30 reed@google.com remove SK_SUPPORT_LEGACY_NESTED_HINTINGENUM code
2018-11-30 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/swiftshader a972758d6e10..d46faeb43287 (1 commits)
2018-11-29 brianosman@google.com Remove the lines-only "optimization" from AA convex path renderer
2018-11-29 hcm@google.com Update Skia milestone to 73
2018-11-29 csmartdalton@google.com Draw ovals with GrAAFillRRectOp
2018-11-29 brianosman@google.com In GrOpFlushState, store GrOp* rather than Unique ID
2018-11-29 recipe-roller@chromium.org Roll recipe dependencies (trivial).
2018-11-29 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 7310da33bc7a..8dc27f99b556 (5 commits)
2018-11-29 benjaminwagner@google.com Add jobs for GalaxyS9
2018-11-29 bsalomon@google.com Modify workaround to never set base or max texture level for GL_TEXTURE_EXTERNAL_OES
2018-11-29 jvanverth@google.com Check for valid normals when offsetting
2018-11-29 michaelludwig@google.com Bugfixes for corner cases in per-edge AA
2018-11-29 mtklein@google.com check decal in 32.32 where we walk decal in 32.32
2018-11-29 caryclark@skia.org Update bookmaker
2018-11-29 fmalita@chromium.org [skottie] Expose property bindings in CK
2018-11-29 bsalomon@google.com Revert "Experimentally disable GrTextureOp chaining on Intel GPUs on Mac."
2018-11-29 caryclark@skia.org fix fuzz timeout in pathops
2018-11-29 mtklein@google.com clean up SK_WALK_DECAL_IN_1616
2018-11-29 reed@google.com remove textblobbuilder guard


Created with:
  gclient setdep -r src/third_party/skia@b13658891bbd

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-blink-rel;luci.chromium.try:linux-chromeos-compile-dbg;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel

BUG=chromium:899689, chromium:905337 ,chromium:908566,chromium:906453, chromium:910097 
TBR=jcgregorio@chromium.org

Change-Id: I5cfcadca44e3a695285931eabc243b9fd0599dc9
Reviewed-on: https://chromium-review.googlesource.com/c/1358793
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#613130}
[modify] https://crrev.com/8869ba9507397f8234dfd7c6fb517f2a3bae9976/DEPS