Gmaps WebGL + UI freeze with VulkanFromANGLE

[Damien Mfaransa]

Hello Angle team,

Trying to break down some behavior i've been experiencing using Google Maps (WebGL) on Chromium, which produces noticeable UI freezes.

To trigger this behavior :

- launch Chrome/ium with features : Vulkan,DefaultANGLEVulkan,VulkanFromANGLE
- navigate to Google Maps
- switch to "Satellite view" + 3D View / Globe view (advanced Web GL ?)
- start dragging map + release while still moving pointer
=> maps starts scrolling animation
- switch to other chromium tab before scrolling animation ends

=> when (invisible) animation ends in background, Google Maps engine is obviously doing something wrong :

- a storm of 500K to 1.5M WebGL calls is issued, probably as much as CPU can produce before some timeout
- occurs only when animation ends while visibilityState = hidden
- at the end no visible change on Maps display despite high number of GL calls issued

=> if VulkanFromANGLE is active, while (bogus?) WebGL calls are processed, the UI shows severe responsiveness issues if not total freeze for up to several seconds.
=> if VulkanFromANGLE is omitted, no such UI lag is noticeable
Interesting fact, the more CPU available, the more severe the effect is.

Regarding the described issue, it is likely some kind of bug in google maps engine. 

However, it shows that navigation to a non-optimal WebGL site can affect the entire Chromium/ANGLE context.

What is your position on such matter ? Maybe some kind of "throttling" or priority inside ANGLE would help to mitigate such problem ?

Do not hesitate if more information needed or further tests required.

 Regards,

[Shahbaz Youssefi]

Hello,

Thank you for the report. Could you please provide the contents of chrome://gpu?

[Damien Mfaransa]

Please find attached,

Regards.

[Damien Mfaransa]

Additional notes :

- happen the same with any recent build of chromium (~1 year from now), did not test with older releases

- same with any mesa vulkan driver release

- happens with both i915 and xe driver, did not test on AMD gpu

Again, severeness of freezes seems directly related to the amount of available CPU,

- on entry level 10th gen, effect is barely noticeable

- on Core Ultra 5, freeze can occur for several seconds

Any action throttling WebGL (chromium debug output, chrome tracing, JS profiler, ...) would mitigate the effect (or even no freezes at all)

[Shahbaz Youssefi]

Thanks. Some other things to try could be to use x11 instead of wayland, see if it makes a difference. Using a different GPU would also definitely be helpful. Unfortunately neither Vulkan nor DefaultANGLEVulkan are being looked at for Linux. With other changes planned for Chromium, some of the issues (and flags) here will be obsolete.

That said, I can reproduce some lag on RADV with the above combination of flags and the repro steps. It looks like after the rotation ends, maps starts loading more details and that is the cause of the lag (early on in rotation I can switch tabs quickly, but it "hangs" for a second around the time the rotation ends).

Could you please open an issue at crbug.com/new for further investigation? Please include the repro steps, chrome://gpu and the conversation here.

[Damien Mfaransa]

Hello,

Thanks for the follow-up, 

It seems you managed to reproduce the issue exactly. If you have possibility to monitor GL calls produced when animation ends, you will see very high number, much much higher compared to same operation when maps not hidden.

Tried Ozone X11 platform : same effects
i'm aware X11 + Wayland currently have disadvantage of submitting frames on main thread, which can bring UI lag under heavy navigation work.
i've opened a WIP CL to address that issue : http://crrev.com/c/7112980
But anyway here it doesn't seem to be related.

 Regarding DRM drivers

• Intel I915 : complete graphic freeze when invisible animation ends (compositor unresponsive)
• Intel XE : graphics freeze only affect Chromium session
• AMD : not tried yet, will do when possible

However there's no lag using :

• use-gl=egl (no Angle, need to re-allow validating cmd decoder in chromium code )
• Angle GLES backed (not Vulkan)
• Angle Vulkan without VulkanFromANGLE

Do you still trust a CRBUG is relevant here ? If so i will open a ticket as instructed.

Btw Vulkan / DefaultANGLEVulkan not looked at for Linux, you mean it is not officially supported ?

[Shahbaz Youssefi]

Thanks for all the tests. First off, no unfortunately neither Vulkan nor DefaultANGLEVulkan is officially supported on Linux. I personally use the same three flags combined, but I'm aware it's not without issues.

Regarding opening a bug, yes it'd always be better to have it logged in the issue tracker. VulkanFromANGLE is supposed to reduce the work by allowing chrome to not go through external memory for webgl interaction (like with dmabufs). This huge number of GL calls... are they there without this flag too and they just run faster / are non-blocking? I'd imagine yes, because the number of GL calls coming from webgl should have nothing to do with how they are translated to Vulkan, right?

I'm admittedly not familiar with all of Chromium's interactions with ANGLE. One thing I can think of about VulkanFromANGLE is that since the VkQueue is shared, there's a mutex shared between ANGLE and Chromium which is locked around queue operations (like vkQueueSubmit). I doubt that'd be the issue though, it might not be used without "Direct Rendering Display Compositor" which is disabled on Linux.

[Damien Mfaransa]

Yes, number of GL calls only depends on CPU capacity. Probably some kind of loop in Gmaps engine, until some timeout.
Can reach 1,5M on Core Ultra 5 under AC power, less on battery, much less on older laptop.
Effect is then moderate or non noticeable.

Some further testing :

• playing with ANGLE build flags 
  angle_enable_context_mutex , angle_enable_share_context_lock , ...
• force enable DRDC (despite total non supported on linux)

=> No change, exact same effect

 

I can think of following interaction when VulkanFromANGLE is activated :

- chromium using FN pointers from Angle :

https://source.chromium.org/chromium/chromium/src/+/main:gpu/vulkan/vulkan_instance.cc;l=94

- dedicated image backing instead of regular Ozone one

https://source.chromium.org/chromium/chromium/src/+/main:gpu/command_buffer/service/shared_image/shared_image_factory.cc;l=251

last one might be needed to benefit from shared context, but with limitations eg. WebGL video does not work

 

I am no expert, but i tend to believe there might be a superfluous lock/barrier/syncObj involved somewhere in ANGLE / Mesa / DRM which locks normal display operations until all queued GL/vulkan rendering work is done. Thoughts about different queues / priorities...

Btw you mentionned RADV when you reproduce similar behavior, does it mean AMD is affected the same ?

 

[Shahbaz Youssefi]

> Btw you mentionned RADV when you reproduce similar behavior, does it mean AMD is affected the same ?

It looks like it yes.

Not sure if you managed to check this:

> This huge number of GL calls... are they there without this flag too and they just run faster / are non-blocking?

Are you able to check if VulkanFromANGLE leads to high number of calls, or there's always a high number of calls, it's just slower with VulkanFromANGLE?

[Damien Mfaransa]

Tools like chrome tracing / console profiling or so... they reduce the amount of CPU available, so cannot be used reliably in that case.

I managed to collect (the dirty way) a log of GL calls using std::string concatenation written by chunks of 10000 to a tmp file 
by "tapping" into :

https://source.chromium.org/chromium/chromium/src/+/main:gpu/command_buffer/service/gles2_cmd_decoder.cc;l=4716

for direct EGL

or :

https://source.chromium.org/chromium/chromium/src/+/main:gpu/command_buffer/service/gles2_cmd_decoder_passthrough.cc;l=718

for Angle

It doesn't show any significant difference with either :

- direct EGL

- Angle EGL backend

- Angle Vulkan with or without VulkanFromANGLE

I wouldn't say VulkanFromANGLE is slower, but it is actually blocking all GPU operations until GL work is done.

Omitting that flag enables operations unrelated to Gmaps (rasterization, shared images, rendering other tab) to operate concurrently.

[Shahbaz Youssefi]

Great, I'd need help from experts in the chromium codebase, would you please open an issue at crbug.com/new?

[Damien Mfaransa]

Opened issue :

https://issues.chromium.org/issues/466109757

Thanks.

[Damien Mfaransa]

Some more testing, not sure about Vulkan anymore.
Reproduced issue with all Vulkan disabled, ie use-gl=angle + use-angle=gl/gles (default)

To summarize best I can :

- use-gl=egl

(need to re-enable allowed impl + validating cmd decoder)

ie WebGL direct EGL / Skia direct EGL

=> OK

- use-gl=angle

ie WebGL + Skia through ANGLE (EGL)

=> Gmap lag

- use-gl=angle + Vulkan + DefaultANGLEVulkan

ie WebGL through ANGLE Vulkan / Skia direct Vulkan

=> OK

- use-gl=angle + Vuklan + DefaultANGLEVulkan + VulkanFromANGLE

ie WebGL through ANGLE Vulkan + Skia sharing ANGLE Vulkan context

=> Gmap lag

Common denominator seems to be WebGL and Skia sharing same ANGLE context.

Apologies if i am missing something here, guess expertise in Chromium ANGLE interact really needed..