GLES2DecoderPassthroughImpl sets up a cache for blobs (including shader binaries), but it needs to avoid using this cache for other decoders for privacy reasons. See the following transcript for details (from https://chromium-review.googlesource.com/c/chromium/src/+/1251325/3/gpu/command_buffer/service/gles2_cmd_decoder_passthrough.cc#1155):


Antoine Labour:

We should figure out what we need to do so that this gets reset when another decoder (namely, I'm thinking RasterDecoderImpl) gets made current. We wouldn't want shaders created by it to get cached with the origin of the last GLES2DecoderPassthroughImpl that was made current (it would have privacy implications). RasterDecoderImpl have their own cache mechanism (see https://cs.chromium.org/chromium/src/gpu/ipc/service/command_buffer_stub.cc?q=gpu/ipc/service/command_buffer_stub.cc&sq=package:chromium&g=0&l=535).

Currently RasterDecoderImpl doesn't work with passthrough (see crbug.com/829435) but we need to make sure we don't run into this when the dependencies are fixed. Any thought there? It may be ok to tackle as a follow-up, but we should file a bug to revisit this.


Shahbaz Youssefi:

The behavior here hasn't changed (it's passthrough instead of angle doing the caching), so perhaps this was already a problem?

Do you know if changing decoders implies destroying one and creating another? If so, there's a call to `ResetCacheProgramCallback()` on `Destroy()` which should take care of this.


Antoine Labour:

No, these various types of decoders are used concurrently. E.g. GLES2DecoderPassthroughImpl used for webgl while RasterDecoderImpl used for cc.

You're right that this is already a problem, but this is something we'll need to fix, but could be in a follow-up.

The proper way I think is to scope the global state around when commands are executed, that is around the CommandBufferService::Flush in CommandBufferStub:OnAsyncFlush (and InProcessCommandBuffer::FlushOnGpuThread), pretty much just like the raster::GrShaderCache::ScopedCacheUse.