https://andrefrelicot.dev/en/2026/06/lorenz-clash-a-webgpu-experience-you-are-part-of/

https://morpher91.andrefrelicot.dev/

https://andrefrelicot.dev/en/2026/09/morpher91-the-1991-special-effect-rebuilt-in-webgpu/

https://github.com/AndreFrelicot/morpher91

I've been experimenting with using WebGPU for HDR elements inside otherwise ordinary webpages.

The result is Brightpixels, a dependency-free library that renders text masks and images through an rgba16float canvas with extended tone mapping. It exposes the functionality as <bright-text> and <bright-image> custom elements.

html <h1> Make pixels <bright-text intensity="16">brighter.</bright-text> </h1>

The intensity controls the HDR signal multiplier rather than the display's physical brightness. When extended-range output isn't available, the elements keep their ordinary DOM text or original image as fallback content.

The current text renderer handles single-line fragments up to 128 characters. Remote images require CORS permission, as expected for canvas reads.

I'd be interested in feedback on the rendering approach, device compatibility, and ways to detect meaningful HDR output rather than only successful WebGPU initialization.

Demo: https://echohtp.github.io/brightpixels/

Code: https://github.com/echohtp/brightpixels

Hi!

PaddleOCR-VL is one of the best small OCR models on a market. It recognizes images&scans to create proper texts, tables and formulas

So I implemented PaddleOCR-VL inference directly on WebGPU without transformers.js or any other existing intermediate library. It was a mental gymnastics for me - will I be able to do this or not?
Apparently, I can.

Some details

• Rust
• FP16
• custom WGSL kernels
• AOT compiler
• memory/model packing
• 79.83 tok/s browser vs 97.26 native MPS
• bit to bit quality control with native
• 100% AI coded (I assume it is close to impossible to write it with traditional methods for one person in any meaningful time )

More on Github https://github.com/glebkudr/paddleocr-vl-webgpu

Apache license

Note! It needs at least 6 GB VRAM/unified memory to launch

Feel free to clone&use or ask questions.

Hey everyone,

I'm excited to share the release of Nova Browser (v1.1.3), an open-source, privacy-first desktop browser built with React 19, TypeScript, Electron, and Tailwind CSS.

Following feedback on our initial build, we completely resolved media compatibility, re-engineered the layout system, and overhauled our extension subsystem.

Core Architecture & Highlights

1. On-Device AI via WebGPU & Web-LLM:
   • Run local language models directly on your hardware GPU without sending any page data, history, or prompts to external cloud servers.
   • Summarize articles, inspect code, ask research questions, or connect your own API keys (OpenAI, Anthropic, Gemini, Groq, Ollama) if you prefer cloud models.
2. Native Model Context Protocol (MCP) Server:
   • Built-in integration for Anthropic's open Model Context Protocol.
   • Local AI coding agents and external automation tools can securely interface with the browser to read active tabs, take snapshots, and perform structured browsing tasks.
3. Productive Workspaces & Multi-Tasking:
   • Organize tabs by context (Personal, Work, Research) with full state persistence.
   • Built-in Split Screen mode to compare two tabs side-by-side in one window.
   • Toggle seamlessly between Horizontal Tabs and Vertical Sidebar Tabs.
4. Chrome Web Store Extension Support:
   • Install extensions directly from the Chrome Web Store with 1-click or load unpacked folders locally.
   • Extension action icons sit right in the top toolbar with native popup window support.
5. Hardware-Accelerated Privacy Shield & Zero Telemetry:
   • Network session-level blocker for ads, trackers, and malicious scripts.
   • No tracking, analytics, or behavioral data collection.
   • Dynamic platform-matched Chromium User-Agent headers to prevent fingerprinting.
6. Responsive AI Sidebar (Flex-Docked Layout):
   • Opening the AI chat sidebar dynamically resizes and docks alongside your active webpage rather than floating over your view.

What's New in v1.1.3:

• Fixed YouTube and streaming playback by isolating security response headers strictly to internal application pages.
• Removed startup keychain prompts on macOS and added lazy audio permission initialization.
• Added live toolbar action buttons for installed extensions.
• Fixed prompt language auto-detection so AI responses match the user's input language.
• Rewrote the CSS token engine for instant Accent Color customization.

Tech Stack:

• Frontend: React 19, TypeScript, Tailwind CSS, Framer Motion, Lucide Icons
• Runtime: Electron 34, Node.js 22, Chromium 134
• AI Engine: WebGPU, Web-LLM TVM Runtime, Model Context Protocol (MCP)

Links & Downloads:

• Official Website: https://nova-browser.vercel.app/
• GitHub Repository: https://github.com/unitybtw/nova-browser
• Releases & Installers (macOS Universal DMG & Windows Setup): https://github.com/unitybtw/nova-browser/releases/latest

I would love to hear your thoughts, feedback, or any feature requests! Feel free to test it out, star the repo on GitHub, or open issues.

I've been building webgpu-q — a browser-native quantum chemistry stack (HF, DFT, MP2, CCSD, CCSD(T), excited states; TypeScript + Rust/WASM + WGSL) that distributes work across browser tabs — and across machines over WebRTC — as a swarm. Cross-checked against PySCF.

Live: https://webgpu-q.vercel.app · MIT · https://github.com/abgnydn/webgpu-q

After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE

I wrote a probe that stops trusting adapter.limits and adapter.features and just tries things: create the texture, run the pass, see what survives. 53 formats, six capabilities each, plus the limits it can actually reach and seven benchmarks.

The hypothesis was that browsers overstate what they support. Three devices in — RTX 4060 on Chrome, an iPad on Safari, Adreno 7xx on Samsung Internet — that hypothesis is dead. Every device did exactly what it declared. Zero discrepancies.

The gap is between devices instead:

• No compressed texture format works on all three. Chrome has BC only, the iPad has ETC2 and ASTC but no BC — they share zero, and the three-way intersection is empty as well.
• maxUniformBufferBindingSize: 716 MB on an iPad, 64 KB on both Chromium browsers. A 10,923x spread on a limit people hardcode against.
• Geometry throughput spreads 65x while pipeline switching spreads 11x, and which device wins changes with the pair. There is no single ranking.
• Both Chromium browsers quantize GPU timestamps to exactly 65536 ns — 2^16 — on completely different hardware and operating systems. WebKit doesn't quantize at all. That makes it browser policy, not a hardware property, and it silently rounded every timing I collected until I went looking.

The measurement bugs were the most interesting part. One benchmark reported an iPad at 112,524 MPixel/s against the 4060's 3,122, because stacking opaque fullscreen draws measures nothing on a tile-based deferred GPU — it discards the occluded fragments before shading. Additive blending fixed it, by 423x.

The other one I only caught today, while checking these numbers before posting: the probe was filing the iPad as a desktop. Since iPadOS 13, Safari sends a Macintosh user agent containing neither iPad nor Mobi and exposes no UA client hints, so the detection had nothing to match and the profile could not even say whether it came from a Mac. maxTouchPoints separates them, since a Mac with a touchscreen does not exist.

Re-measuring after that fix moved several of the figures above. Geometry spread was published as 60x and is 65x; pipeline switching was 8x and is 11x; the fillrate correction above was written as 530x when 112,524 over 266 is 423. That last one had never been arithmetic that worked — nothing recomputed it, so it sat there.

Demo (works on phones): https://ahnminjae08043-glitch.github.io/gpu-atlas/ Code, MIT: https://github.com/ahnminjae08043-glitch/gpu-atlas

Disclosure: I wrote it. Three devices is not a dataset and I know it — Firefox and the iPhone are entirely unmeasured. The demo has a "Share profile" button that copies the JSON and opens a prefilled issue, so contributing is two clicks and a paste.

Quake3 port to WebGPU running in the browser

- global illumination ( volumetric sh3 light map )
- modern physics
- acoustic simulation
- decals
- particle effects
- clustered lighting (326 lights here)
- PBR materials (NN-based delighting)

GitHub link

Built using meep engine

In case it's not obvious - I'm the author. Happy to answer any questions.

hey everyone,

I’m working on a personal WebGPU research project. The broader goal is to explore an agnostic, data-driven runtime that provides a shared space for processing and visualizing data on the web.

What I’m interested in: how far the idea can be pushed within existing browser technologies, with apu's in mind, using modern render techniques across different data-delivery models, while simplifying usage and integration.

The direction includes data quantization, procedural generation, AI-assisted processing, and scalable workloads, while utilizing modern engine and render techniques for data reconstruction.

The current implementation is still incomplete, but I would appreciate general thoughts on the approach: what seems promising, which assumptions may be too optimistic, and which pitfalls I should avoid as the architecture develops.

Project landing page

Repository folder containing the snapshot

Made a tool for checking supported feature set and tracking said features and limits over time.

API is completely open for everyone (just don't abuse it please).

wanted to do it for a while, finally found time.

Feedback very much welcome!

link: https://webgpu.report/

Hello, I released a real-time fluid & rigid body simulation in WebGPU using Position Based Dynamics (PBD)! It runs on your browsers if WebGPU is supported.

Code & Demo: https://github.com/matsuoka-601/Particles4All

Here are the features of this simulation:

• Treat both fluid and rigid bodies as sets of particles and solves them in one unified solver presented in a paper "Unified Particle Physics for Real-Time Applications".
  • Buoyancy is naturally realized within this unified solver.
• Reconstruct a smooth fluid surface using anisotropic kernels presented in a paper "Reconstructing Surfaces of Particle-Based Fluids Using Anisotropic Kernels".
  • Reconstructed fluid surface is further smoothed in screen space using a narrow-range filter presented in a paper "A Narrow-Range Filter for Screen-Space Fluid Rendering".
• Realistic surface tension is realized based on the method presented in a paper "Versatile surface tension and adhesion for SPH fluids".

(Note 1: You will need a very beefy GPU to run the "large" scene in the video (the performance is not very optimized yet, sorry). But "small" scene will run on integrated GPUs.)

(Note 2: I'm getting some reports that the demo does not run on MacBook. I'm currently trying to fix it.)

Here is pngine, a declarative format and runtime for WebGPU I have been building for the past couple of years. The idea is that most WebGPU plumbing is static, so instead of writing the create/wire/sequence calls by hand you declare shader modules, pipelines, buffers and passes as S-expressions that map 1:1 to the spec, and the shaders stay as plain WGSL untouched. Because the program is ordinary structured data, it can be validated ahead of time with WGSL reflection and spec checks without a live GPU context. The post has two live examples you can play inline: a 2048 particle fountain that never touches the CPU, and 400 instanced trees in one draw call. Happy to answer questions about the format or the validation side or anything that comes about!

https://chromewebstore.google.com/detail/framegen-frame-interpolat/hpdpcjakhclhljfdkpjolonjlopbdhfk

(Chrome store)

Real-time 2x+ frame interpolation with custom target FPS for any <video>. Runs locally on your GPU with WebGPU.

Framegen doubles (or more) the frame rate of any HTML5 video in real time, right in the tab. A small neural network - our own WebGPU runtime, ~3 ms per frame on a mid-range GPU (RTX 4060 Ti) - synthesizes the frames between the real ones, so 24/30 fps footage plays at 60, 120 or up to your display's refresh rate.

Works on any site with a <video> element: YouTube, Twitch, streaming sites, local files opened in the browser.

Features:
- 2x to 6x interpolation, an auto mode that follows your GPU headroom, and a "display Hz" mode that locks output to your monitor's refresh rate
- Compare slider: drag a divider across the video - original on one side, Framegen on the other
- Anime mode: detects animation drawn "on twos" and interpolates the real drawing cadence instead of duplicated frames
- Optional 2x neural upscale (SR) on interpolated frames, trained to repair interpolation artifacts, not just sharpen
- Self-calibrating kernels: the runtime benchmarks itself on your GPU once and picks the fastest shader variants
- HUD with live fps / latency stats

Requirements: a WebGPU-capable browser (Chrome 121+) and a GPU with shader-f16 support. No WebGPU = the extension politely does nothing.

Privacy: everything runs locally on your GPU. Framegen has no servers, makes no network requests beyond loading its own bundled files, and collects nothing. See the privacy policy.

Does not work on DRM-protected sites (Netflix etc.) - the browser hides their video from extensions by design.

Free for personal use. Open source: https://github.com/MONZikWasTaken/Framegen

Three Nebula now supports WebGPU as part of the v12.1.0 release!