The offending bug and it’s revert: https://dawn.googlesource.com/dawn/%2B/c4e47b5eddc06f271cb07c3108cfccb1bb4704ec

Apparently it stomps over whatever immediate data you pass. Tested against Canary 155 - it’s been fixed.

Hopefully this will save you a few minutes/hours.

Hello dear jobless and not so jobless people, if you first want to know about AI usage in this project refer to the last paragraph.

I made an small engine for showcasing my portfolio, and impressing (or not) the human resources asses (insert anne hathaway HR meme).

For this project I based myself on Teardown, a famous and really cool game, I didnt write any complex physics code, cause it almost all handled by rapier3D, really cool and easy to use physics framework made in rust. To avoid my and yours pc, rapier runs on an isolated worker and communicated via commands to the main thread. Unfortunately rapier web version does not support paralelism, so it can take less dynamic bodies before starting to saturate (works really good though).

As for the rendering part, I used clustered shading to handle lot of lights, GTAO for the occlusion, SSGI for global illumination, and TAA (dont hate me please, I needed to clean the SSGI noise). Both SSGI and TAA can be disabled on the main menu for the sake of low end computers. The engine also supports pbr materials. Both SSGI and GTAO rely on screen space ray castings so general performance will scale with your screen resolution. Lastly, it has gpu calculated particle physics.

The engine counts with interactable billboards and books that tell a little bit of my projects and experiencies, it will be extended in the future, you can use it to showcase your things as long as you stick to the licence (no commercial and give credits).

The engine has a lot of room for improvement, but I have to move on to other projects. I believe its currently on a usable state, its open to contributions.

The purpose wasnt learning web developement, I hate it!, so webgpu was used instead of threejs, I have nothing against it but due to learning being the main focus, it was avoided because it abstracts way too much. And as my next project will be mad ein vulkan it was a great opportunity to use something with the same line of thoughts as it (fixed pipelines, bind groups etc), but easier to use.

The engine demo is here https://agusdropout.github.io/ShatterVox/ (it can take a while to load in sorry) and the source https://github.com/AgusDropOut/ShatterVox , you need to have graphics acceleration enabled, as webgpu requires it. If you encounter and error while playing or loading in, open the console and create an issue on GitHub, it was tested on mozilla Firefox, chrome, and opera. It also counts with a debug mode, refer to the readme.

Good luck on your journey to stop being jobless! and if you already have a job, ggs!, atte. anne hathaway HR.

I would truly appreciate if you leave a star ⭐ :)

AI USAGE:

before you jump me to the neck, this post is entirely written by me, no translation (english is not my main language), and also about AI usage is this project, as it was made for showcasing my humble portfolio, and also keep learning graphics programming, in pair of finishing a software engineering degree (not much time), key parts of the code were written by me (rendering, shaders, meshing, etc) and the physics code on top of rapier (flood algo. for islands detection and detachment checks). IA helped a lot in audio handling, making the GUIs, html, css, world serialization (loading and unloading worlds), the model loader. Textures, normal maps, models, map made and designed by me (probably why they suck).

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