ANGLE virtualized contexts and DrDC

[Sunny Sachanandani]

Hi Geoff & Jamie,

Background: DrDC is a project to make the display compositor issue its own GL commands instead of posting to the GPU main thread.  Currently, the implementation on Android uses a real GL context on the DrDC thread that shares resources with the GPU main thread's virtualized GL contexts via EGLImages (the plain kind - not wrapping native AHB fds).

Vikas and I wanted to figure out what it would take to get this to work with --use-gl=angle and also how soon we'll need to do that.  We're also unclear about how --use-gl=angle is related to the migration to passthrough decoder.  Does passthrough imply --use-gl=angle as well?

FWICT ANGLE's GL backend uses virtualized contexts by default unless Chrome explicitly asks not to.  But we also have the option to wrap a native GL context in ANGLE which Webview seems to be using.  Since we don't want to disable virtual contexts in general (since most Chrome GL contexts can and should be virtualized) we have two options:

1) Create our own GL context and wrap it using EGL_ANGLE_external_context_and_surface.  If we want to keep our current implementation which uses EGLImages then we would need to create this GL context on the same underlying EGLDisplay as ANGLE.  Can we even do that?

2) Use a separate EGLDisplay for DrDC and share resources using native image handles (AHB fds).  This is similar to what we're planning to do for Windows where we intend to use separate instances of ANGLE's D3D renderer (and therefore separate D3D device immediate contexts) on GPU main and DrDC threads by having separate EGLDisplays for each thread.

Let us know what you all think.  Thanks!

-- Sunny

[Geoff Lang]

Hey Sunny and Vikas,

This is something I'd also like to sort out. The Passthrough command decoder does imply ANGLE and our context virtualization would break with the current architecture. The native context wrapping is an option but won't work as is; it still assumes we're operating on one thread.

Since we do support non virtualized contexts, I think we should extend that. Possibly a virtualized context per share group or some other separation of display compositor and raster contexts that ANGLE and Chrome agree on. EGLImages can be used to share between these contexts.

How about I set up a meeting to talk about details?

Geoff

[vikas soni]

Thanks for the info.

Virtualized context per share group sounds great and reasonable.

Lets discuss over a meeting.

Thanks

[Geoff Lang]

I set up a meeting for tomorrow at 4pm EST. If anyone else would like an invite, let me know.

[Sunny Sachanandani]

Thanks for setting up the meeting, Geoff.  Virtualized context per share group would work fine for DrDC, but we might not want that say for WebGL contexts which would be in different share groups if we want to maintain the current behavior.  I'd prefer an attribute that tells ANGLE that we want to use a new non-virtual underlying context when we create a new context (if it's not already in a share group).

[Zhenyao Mo]

I second this proposal. This is the minimum change to the current architecture and minimum risk to move DrDC forward.

[vikas soni]

Thanks Geoff, Peng and Sunny for meeting and discussing.

Meeting Notes :

Angle will provide a new context creation attribute which will be an id or enum representing the virtualized context group to which the context will belong to.

DrDc context will have a different id value than the rest of the chrome contexts resulting in a new virtualized context group for it.

All the existing chrome contexts do not need to provide this new id and will default to some value and hence irrespective of the shared group (whether new or same), will fall into the same virtualized contexts group as it is today.

The other solution could have been virtualized context per shared group but that will break existing webgl behaviour. Webgl contexts are part of different shared groups but we still want it to be in the same virtualized context as raster and other chrome contexts. Having an explicit attribute to tell angle to put a context in a particular virtualized context group solves this issue.

[Ken Russell]

Thanks for sending the meeting notes.

Was the option of creating a second EGLDisplay connection for DrDC discussed? There's a plan to use that mechanism for other purposes, like supporting rendering on multiple GPUs in the same system simultaneously.

Thanks,

-Ken

[Sunny Sachanandani]

We didn't discuss the second EGLDisplay approach except for saying that's the only way to do it on Windows due to the way ANGLE's D3D backend is implemented.

FWIW using a second EGLDisplay on Android would force us to use AHardwareBuffer backed shared images which we found had poorer performance compared to EGLImages when we initially prototyped DrDC.  Vikas knows more about this.

[vikas soni]

AHB allocations are generally more costly from what we have seen while exploring Vulkan raster GL Compositing on android

Hence EGLImages are preferred wherever possible.

[Ken Russell]

Thanks for the information. I was also curious whether a secondary EGLDisplay connection obtained via eglGetPlatformDisplay could take in attributes indicating to actually share resources between the underlying GL contexts (for the GL backend), to allow EGLImages to be passed between them - but it's not important given that you already have a path forward.

-Ken

[vikas soni]

I couldn't find anything in specs if a secondary EGLDisplay would work.

It seems like only EGLContext created using the same EGLDisplay object will be able to share textures directly or via EGLImage.

A secondary EGLDisplay would be a different object and might not work.

[Jamie Madill]

FWIW I think we tried two displays at once in ANGLE a while ago and it didn't work. Not sure if you're talking about a second display from ANGLE, from the native EGL, or one from each. Also it probably "should" work it's just an uncommon path.

[Zhenyao Mo]

Jamie,

Do you have a doc or draft CLs to share about the trying two displays in ANGLE effort? I am interested in exploring multi-gpu rendering and would like to hear what explorations the ANGLE team already did.

Mo

[Sunny Sachanandani]

I recall that we did get multiple EGLDisplays to work for the DrDC prototype on Windows (CL - the interesting bits are the GLSurfaceEGL changes to support per-thread EGLDisplay).

On Wed, Sep 1, 2021 at 10:58 AM Jamie Madill <jma...@chromium.org> wrote:

Sorry Mo, I don't. It was a few years ago and I don't even remember in what context we were trying it out.

[Jamie Madill]

Sorry Mo, I don't. It was a few years ago and I don't even remember in what context we were trying it out.

On Wed, Sep 1, 2021 at 1:42 PM Zhenyao Mo <z...@chromium.org> wrote:

[Ken Russell]

That's great! I wonder whether changes like that will work with ANGLE on Android. It may depend on whether ANGLE's GL backend or Vulkan backend are in use.

On a related topic, Apple uses two EGLDisplay connections to work separately with the integrated and discrete GPUs in ANGLE's Metal backend. In their browser though they're used from the same thread.

Similar kinds of multithreading issues as come up in WebView - simultaneous use of ANGLE from multiple threads - were seen during that port. The solution chosen there was not desirable - we handed off control of ANGLE between the threads using eglReleaseThread. See https://bugs.webkit.org/show_bug.cgi?id=216106 .

We'd want to do better for DrDC on Android. ANGLE's two EGLDisplay connections on different threads should use two different native EGL contexts which still share resources. EGLImages should be able to be passed between those threads then with the appropriate synchronization.

Again, if you're already set on a path forward don't worry about this input, but was hoping existing mechanisms could be used to get the same result instead of adding a new one.

-Ken