Performance problem on Safari, Chrome with ANGLE/Metal

[Kari Lavikka]

Hi all,

I stumbled upon a severe performance problem on Safari and Mac Chrome with the Metal ANGLE backend enabled. My app runs 60 FPS without Metal, but depending on the case, something like a few seconds per frame with Metal. Happens on both Intel and M1/M2 Macs. However, I'm unable to track down the culprit and would appreciate some tips on how to proceed.

All examples here are very sluggish with Metal: https://genomespy.app/

Because many of them are quite complex, I made an as-simple-as-possible example for debugging: https://karilavikka.fi/slow-on-metal/

According to Chrome's performance recorder, there's barely any GPU utilization on my Intel MacBook Pro (2018) with the OpenGL backend, but around 50% is utilized with Metal. I recorded the WebGL calls of a single frame using spector.js and I think there's nothing special going on:

bindFramebuffer: FRAMEBUFFER, null
viewport: 0, 0, 2694, 1892
disable: SCISSOR_TEST
clearColor: 0, 0, 0, 0
clear: COLOR_BUFFER_BIT
useProgram: WebGLProgram - ID: 0
bindBufferRange: UNIFORM_BUFFER, 1, WebGLBuffer - ID: 6, 0, 28
bufferData: UNIFORM_BUFFER, [--(28)--], DYNAMIC_DRAW
bindVertexArray: WebGLVertexArrayObject - ID: 0
viewport: 124, 84, 2550, 1788
scissor: 124, 84, 2550, 1788
enable: SCISSOR_TEST
bindBufferRange: UNIFORM_BUFFER, 0, WebGLBuffer - ID: 7, 0, 36
bufferData: UNIFORM_BUFFER, [--(36)--], DYNAMIC_DRAW
drawArrays: TRIANGLE_STRIP, 0, 117198

Here's the spector.js capture with full WebGL state, etc.: https://karilavikka.fi/slow-on-metal/capture.json

I could submit a bug report (where?), but first I'd like to figure out where the bug is – in my app, ANGLE, or elsewhere.

Thanks!

- Kari

[Ken Russell]

Hi Kari,

I can't reproduce any slow behavior of https://karilavikka.fi/slow-on-metal/ on an M1 MacBook Pro. This is however an M1 Max.

Could you please:

1) Try Chrome Canary

2) Go to about:flags, set "Choose ANGLE Graphics Backend" to "Metal", restart the browser

3) Confirm the slowdown on an example, tell us which one it is

4) Go to about:gpu, click "Copy report to clipboard", paste into a fresh pastebin

Mine, as an example: https://pastebin.com/pB6GJY08

If we can reproduce the issue we can debug it.

Thanks,

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/434A49BE-85A8-4443-80F9-6F686424C035%40gmail.com.

[Kimmo Kinnunen]

Hello Kari,

I can repro on the full site, but not with the slow-on-metal test case.

If you have time, to further narrow things down:

- Please update to the newest macOS and Safari. If you are on an older Safari, it might be that the slowdown you see with slow-on-metal test case is already fixed. There is also Safari Technology Preview available at https://developer.apple.com/safari/technology-preview/

- Try to make the standalone test case with and without the chart labels and axis descriptions. It might be that these routines are the source of the current slowdown.

I filed https://bugs.chromium.org/p/angleproject/issues/detail?id=7694

The GPU History chart in Activity Montor can be used to quantify the hypothesis that OpenGL vs Metal difference is due to different amount of GPU processing.

Br,

Kimmo

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2cq1Kzs2_iHJpp%3DkPScJP73k9Vwr%3DnzD6F%3DCHn2r1cYaA%40mail.gmail.com.

[Kari Lavikka]

Hi Kimmo and Ken!

Thanks for your replies.

I think I was a bit imprecise with the slow-on-metal example. That particular example does not feel slow, but I observed that even such a simple example causes considerably higher GPU usage on Metal according to Chrome’s perf monitor. Also, MacOS System Monitor shows slightly higher GPU utilisation.

The TCGA_BRCA example (https://genomespy.app/examples/?spec=TCGA_BRCA/tcga_brca.json) indeed demonstrates the issue strikingly. I updated it a bit, and now the visibilities of all the different elements are configurable from the toolbar. I noticed that while drawing plenty of TRIANGLE_STRIPs (Copy number variation) is super slow on Metal, POINTs (Point mutations …) are equally fast on Metal and OpenGL and cause pretty much equal GPU utilisation. Both of these use almost exactly the same WebGL calls for initialisation and drawing. The shaders are of course different.

Anyway, the slowness of TCGA_BRCA example occurs on latest Chrome Canary (with Metal) and Safari Tech Preview on macOS Monterey, MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports). Here’s the chrome://gpu dump: https://pastebin.com/7vaZd9SD

Regards,

Kari

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/D20F1520-DD77-40D0-A89C-E327EB403FDA%40apple.com.

[Ken Russell]

Hi Kari,

I can see that this case is slower on the Metal backend. It's far too large for us to diagnose from it what aspect is slower. For example there are some known performance problems with flat shading but it would be difficult for us to see whether this is the cause here. Can you please invest some time reducing this to a smaller and more self-contained example that we can have to debug things on the browser side?

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/B569FDCA-299B-4153-8EEE-4CB36F07EC1D%40gmail.com.

[Kari Lavikka]

Hi Ken,

Thanks for the tip about flat shading! Removing all flat qualifiers from shaders resolved the problem.

The ”Provoking Vertex” part in your presentation in last WebGL meet-up nicely explained the problem. The flat qualifiers were actually unnecessary – I had thought that flat shading would be a practical way to avoid useless linear interpolations, but apparently it triggered some very expensive workarounds on the Metal backend.

 - Kari

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2dRUvy8cbPDfw1LVQ3Xu_fjMAMCo20x7p4wq5SgMB4%2BZQ%40mail.gmail.com.