GoKawiilscreenshot WebGL is everywhere now: 3D maps, seat charts, product configurators, shader-art landing pages. It was also the slowest thing you could ask Microlink to. One Chrome flag fixed that.
animated screenshot A WebGL page (three.js) captured as an, rendered through Mesa llvmpipe on a GPU-less node
TL;DR
Our servers have no GPU. WebGL still has to render somewhere.
Chrome's default software path (SwiftShader) took ~24s per 3D page.
per 3D page. Pointing ANGLE at Mesa llvmpipe ( --use-angle=gl ) dropped it to ~6s .
) dropped it to . The one-line flag is the easy part. The display, the from-source Mesa, and proving it stays on the fast path are the rest of the story.
Our browser fleet runs on commodity Linux nodes with no graphics card and no /dev/dri . Cheaper, simpler, fewer drivers to babysit. But WebGL is a GPU API, so without one, something has to emulate it on the CPU. Which something was the difference between a 24-second screenshot and a 6-second one.
ANGLE , which translates it to whatever backend the platform has: Direct3D, Metal, native OpenGL or Vulkan, or a software renderer when there's no GPU. Chrome hands WebGL to, which translates it to whatever backend the platform has: Direct3D, Metal, native OpenGL or Vulkan, or a software renderer when there's no GPU.
SwiftShader, its bundled default, or the system OpenGL stack, which on our Linux nodes is Mesa llvmpipe . Same pixels on the CPU, wildly different speed. With no GPU, that software renderer is the whole ballgame. Chrome ships two:, its bundled default, or the system OpenGL stack, which on our Linux nodes is. Same pixels on the CPU, wildly different speed.
... continue reading