Hi all,

I have started looking into this bug in more detail. I will describe my current understanding below to ensure I am not misunderstanding something.

In the process of drawing a frame, the direct renderer tries to use overlays for some of the draw quads in the root render pass. This can lead to three scenarios:

1. No quads are replaced with overlays, and thus only the primary plane is scheduled.

2. Some quads are replaced with overlays, but the root render pass still needs to render the remaining quads.

3. Quads are replaced with overlays, and no render pass quads require rendering (i.e., the render pass damage rect is empty).

For case (1) we currently schedule the primary plane (for the root render pass) with a fence to ensuring all rendering to it has been committed.

For case (2) we currently schedule the primary plane with a fence and other overlays without a fence. This is not strictly correct, but because overlays are committed atomically with KMS (and thus all fences are waited on) and due to the position of the primary plane fence in the command stream, things should work.

For case (3) we currently schedule just the overlays without fences.

The question is whether in case (3) (and (2) to some extent) we are synchronizing display of overlays correctly, i.e., if we are ensuring that the contents of the overlays are ready before we send them for display.

When not using fences this isn't a problem since we do a sync on the service side, for example, with an egl fence for Ozone-DRM. However, when using explicit fences the service side sync is not used, so for (3) no synchronization is happening at all. My assumption here is that the resources backing DrawQuads are not guaranteed to be ready without some extra synchronization. Is this correct?

In a fully explicit fence world, each resource backing a DrawQuad would carry a completion fence which could be used when scheduling that quad as an overlay.

For now, though, we can just provide a fence the same way we do for the primary plane. A simple fix would be to just use the same fence (the one provided by the output surface) for all scheduled overlay planes. This is functionally correct due to the current position of that fence in the command stream, but could be semantically confusing since we would be using the output surface fence on overlays not using the output surface contents. If we don't like this, an alternative would be to create a separate rendering fence for the non-primary overlay planes.

Thoughts?

Thanks,
Alexandros

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

commit 009fdad3f42adefbad6911ce7bf98b2b216a90c3
Author: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Date: Fri Jun 22 16:12:47 2018

viz: Use gpu fences for all GLRenderer overlay planes

Use the output surface gpu fence when scheduling any and all overlay
planes, to ensure the planes are correctly synchronized for display even
if the root render pass is skipped.

Bug: 840805
Test: viz_unittests and chrome --use-gpu-fences-for-overlay-planes on Ozone-DRM
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I4939c36a8b7d334ccef5ab2bad2eee90ffeb07d8
Reviewed-on: https://chromium-review.googlesource.com/1104695
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569647}
[modify] https://crrev.com/009fdad3f42adefbad6911ce7bf98b2b216a90c3/components/viz/service/display/direct_renderer.cc
[modify] https://crrev.com/009fdad3f42adefbad6911ce7bf98b2b216a90c3/components/viz/service/display/gl_renderer_unittest.cc
[modify] https://crrev.com/009fdad3f42adefbad6911ce7bf98b2b216a90c3/components/viz/test/fake_output_surface.cc
[modify] https://crrev.com/009fdad3f42adefbad6911ce7bf98b2b216a90c3/components/viz/test/fake_output_surface.h