I spent a ridiculous amount of time trying to get WebGPU working properly on my Linux machine.
I eventually figured it out, wrote a script to laun...
For further actions, you may consider blocking this person and/or reporting abuse
Great post, this hits so close to home π I spent a few weeks shipping a Pandoc WASM
build (~56 MB binary) that runs entirely in-browser, and I landed at the opposite
end of the same conclusion β for CPU-bound workloads (file conversion), plain WASM
with a good IndexedDB cache was faster AND simpler than wrestling with WebGPU
cross-browser. No Vulkan flags, no X11 hacks, no GPU detection headaches.
Also the part about past-you being more organized than present-you is too real. My
dev journal is just a growing folder of files I've cryptically named fixes-notes.md π«
Did you end up ditching the WebGPU launcher for WASM inference after all, or do you
still keep it around for heavier models?
56 MB just to convert files is wild π WASM really said, βWhy make it complicated when it can just work?β And those cryptic notes are basically every developerβs autobiography! π
Sending an AI agent to find code you wrote yourself is peak 2026 developer life π Also love that the Wayland fix was basically telling Chrome to pretend itβs on X11. The Safari note about WASM beating WebGPU for small models is a great reminder too. Past you deserves a thank-you note!
"Sending an AI agent to find code you wrote yourself is peak 2026 developer life" is the most accurate description of modern development I've read this year.
We've reached the point where we need AI to remember what we did before AI. It's funny, but it's also a real problem: if you can't find your own work, you can't build on it.
"Sometimes the practical solution isn't the elegant one. It's the one that actually works" is the most honest sentence in this article.
I've spent hours trying to make Wayland and NVIDIA cooperate, only to end up with
--ozone-platform=x11as the final answer. It feels wrong, but it works, and at some point "works" beats "elegant".Curious how much of this is still necessary on newer Chrome versions. The article mentions WebGPU support has improved, but I'm wondering if the hybrid graphics problem (Intel vs NVIDIA) is still the same.
Haha, exactly! I spent so much time trying to get everything working properly under Wayland, only to end up using XWayland anyway.
I'm curious about the newer Chrome versions too. I haven't gone back and tested which flags are still necessary, mostly because I finally had a working setup and didn't want to mess with it! I'm thinking I might experiment with a separate test profile and see how much has changed. The hybrid GPU selection is definitely something I'd want to look at more closely.
"I finally had a working setup and didn't want to mess with it" is the most honest sentence in this thread.
Every Linux user knows this feeling: you spend 6 hours getting something to work, and then you never touch it again because you're afraid you'll break it. The setup works, but nobody knows why.
Curious if the separate test profile helps. If you can experiment without risking your main setup, that's the right way to figure out which flags are still necessary.
Wow, that's an epic fight with Linux!!! π€©
Nice! I've gone through a similar rabbit trail, but it was for Three.js WebGPU instead of AI use. Solutions look approximately the same though. Come to think of itβ¦ I'm not certain I've left a good paper trail to recover and ensure I'm using the right thing their. π€ Thanks for the reminder π
I'd put a tiny recovery note at the top of the launcher: last working Chrome and driver versions, the sample that passed, and where the longer build log lives. Then add a one-line command that prints that note. Two backups can still leave me searching; having the explanation reachable from the thing I actually launch would make it easier to rediscover six months later.
Great Work
nice!