[Feature] Running WebGPU in Joplin

[HahaBill]

Investigate how Joplin can use WebGPU efficiently for local embedding generation without requiring users to manually launch the app with Electron/Chromium flags.

On Linux, WebGPU currently appears to require flags such as --no-sandbox --enable-unsafe-webgpu --enable-features=Vulkan, which are suboptimal solution for UX.

This issue should investigate:

1. Whether WebGPU can be enabled safely in Joplin/Electron in Linux
2. Whether Windows and macOS work without extra flags
3. The risks of any required Electron/Chromium flags

Based on this:

• PR: feat(embedding, web worker): add embedding pipeline with Web Worker and note reader #2 (comment)
• Comment: feat(embedding, web worker): add embedding pipeline with Web Worker and note reader #2 (comment)

[Harsh16gupta]

1. Windows & macOS (Confirmations)

I tested WebGPU in the Joplin development console on both Windows and macOS.

• Windows: Works out-of-the-box. navigator.gpu.requestAdapter() successfully resolves to a valid GPUAdapter pointing to the system's GPU (e.g., Intel Graphics) with no additional flags.

• macOS: Works out-of-the-box. navigator.gpu.requestAdapter() successfully returns a GPUAdapter pointing to Apple using the metal-3 backend.

Both platforms have WebGPU enabled by default in Joplin’s current Electron environment.

2. Linux Sandbox Issue

On Linux, WebGPU currently doesn't work out of the box. navigator.gpu is available, but requestAdapter() returns null. During testing, WebGPU only worked when launching Electron with --no-sandbox.

After digging into it, this appears to be an upstream Chromium/Electron issue rather than something specific to Joplin.

From what I found, Chromium's GPU sandbox on Linux restricts the GPU process from accessing the Vulkan ICD configuration files (/usr/share/vulkan/icd.d/) and loading the system graphics drivers. Since WebGPU relies on Vulkan on Linux, the adapter initialization fails.

The common workaround discussed in Chromium and Electron issue trackers is to launch with --disable-gpu-sandbox or --no-sandbox, but both options reduce security and aren't something we should require users to do.

For now, I think our current approach of falling back to q8 + WASM on Linux is the safest option (already implemented in #5). Windows and macOS users can continue using GPU acceleration when available.

I've been keeping an eye on this issue and plan to investigate further. I'll also try reporting it upstream to Electron and will share any updates if I find a proper solution.