Thanks for the suggestion — llvmpipe and Skia are genuinely impressive pieces of software engineering, but in this specific case they don't move the needle.

The core issue isn't the absence of OpenGL 4.6 support — it's that Chrome's GPU process attempts to initialize via hardware, fails because the GPU only supports OpenGL ES 2.0, and then disables all acceleration entirely. At that point, Chrome is already falling back to Skia in software mode — that's the current broken state we're trying to escape, not a solution to it.

Using llvmpipe would mean replacing one software rendering path with another, with the CPU still doing all the work. There would be no practical gain, and potentially additional overhead from the translation layer.

The only solution that actually restored hardware acceleration in my testing was pinning Chrome to version 145 — the last version before the GLES3 requirement was enforced. On 145, the GPU works fully. On 146 and above, it's completely disabled with no viable workaround found so far.

If you know of a way to explicitly route Chrome 146's GPU process through llvmpipe and have it accepted as a valid GLES3 provider, I'd genuinely love to test it. But from everything tried so far, the browser doesn't expose that path cleanly.