GitLab

Lazy reset state tracking

Saves 0.4 ms out of 9.4 ms on thread_GPU_cpu_time_per_frame on
thread_times.key_silk_cases running on N5 with OOP-R enabled.

This CL does a couple of things.

(1) dirties GrContext when we make GL calls directly (via api() in
    RasterDecoderImpl or in helpers like TextureManager)

(2) does a hard RestoreState(nullptr) just before we service another
    decoder using virtual contexts.

The correctness/performance of this CL relies on two facts:

- RasterDecoder functions don't rely on ContextState persistence between
  calls (it uses Scoped*Binder and helpers call Restore* on exit). This
  means we can ignore how GrContext changes state during RasterDecoder
  execution.

- GetContextState is called if and only if we switch virtual contexts
  (https://cs.chromium.org/chromium/src/ui/gl/gl_context.cc?rcl=7665435ec16705f26cf15259d28b89d24ec80699&l=328)

This CL avoids most state resetting in the common case where we OOP-R a
bunch of tiles all at once (e.g. page load). Note our resetting is still
pessimistic. In particular, I would expect scenarios like this where we
still unnecessarily reset/restore state.

- client A receives GetContextState

- client B made current, but immediately descheduled to wait on a
SyncToken provided by A

- client A made current again

Bug: 836916
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I9eecef94a5429861ae4b70acdd3aba0450bded4b
Reviewed-on: https://chromium-review.googlesource.com/1047445Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Jonathan Backer <backer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557689}