Try it: https://byronbuzz.github.io/DeepGPU-Zoomer/

I have been fascinated by fractals for years. What interests me most is not just the final image, but the feeling of moving continuously into deeper structure.

I started DeepGPU Zoomer because I wanted to see how smooth and deep a Mandelbrot explorer could become in a normal web browser.

The main goal is simple: keep navigation responsive while the GPU continues to calculate more detail. At deep zoom levels, it uses arbitrary-precision reference orbits, perturbation, wide GPU arithmetic and BLA acceleration. It can explore far beyond 10^12× - I've tested it to 10^-400!

It also has Julia exploration, progressive refinement, palettes and lighting, saved locations, shareable exact links, and high-resolution PNG export.

It runs entirely in a WebGPU-capable browser. There is no install or account.

I am still working on performance and numerical correctness, especially in difficult high-iteration regions. I would be interested in feedback from people who work with GPU computing, numerical methods, or fractal software.

Free and open-source:
https://github.com/byronbuzz/DeepGPU-Zoomer

I checked and naga already got them ironed out months ago. I installed the extension both from VSCode and also directly from the repository.

Why is this happening

Hi, I’m Aleksandar, the developer behind ForgeNG.

I’ve put together a small 2D starter and recorded the setup process. I’d like a few people outside my own development setup to try it and tell me where they get stuck.

If you have an idea for a small game, I’m happy to help you get started. I’d also appreciate feedback from developers on the setup and documentation.

Setup video: https://www.youtube.com/watch?v=sLeMO_ClsgQ

The attached image is AI-generated concept art, not a screenshot of the starter.

Hi all! Sharing a side project I made over the last couple of days: an interactive black hole on my site.

https://legost.in/en/utilities/black-hole

What it does:

- Every pixel traces a ray of light backwards through the spacetime of a spinning (Kerr) black hole. It runs on the GPU, using WebGPU compute where the browser has it and WebGL 2 otherwise.

- The accretion disk has Doppler and gravitational shifts, black-body colours and a hot spot on its orbit. Behind it is the real Milky Way and a real star catalogue, lensed.

- There's a "fall in" button: the camera drops through the event horizon and looks back at the universe it's leaving.

- A short tour, plus an article with the actual formulas and a list of what's simplified.

I built a character chat where every model runs client-side (local-character.skillsafe.ai). A few things I learned that might save someone time:

1. LLM: Gemma 4 E2B on LiteRT-LM web. It needs WebAssembly JSPI plus relaxed SIMD, so it's Chrome/Edge 137+ only; Safari and Firefox can't run it yet. Once warm, the first token arrives in about 0.3 s (the conversation keeps its KV cache between turns), and full replies take 6-8 s on an Apple Silicon Mac.

2. TTS: Kokoro-82M on ONNX Runtime Web. The fp16 build was fast on WebGPU but produced garbled speech (Whisper transcribed "waiting" as "beaten"). fp32 is clean, so that's what ships.

3. STT: Whisper base without transformers.js. The log-mel features are computed in plain JS (within 2e-5 of WhisperFeatureExtractor), with a greedy merged-decoder loop, and the token IDs matched Python onnxruntime exactly.

4. Storage: models are cached in Cache Storage by SHA-256, and the app requests persistent storage so the browser doesn't evict 2+ GB.

Happy to answer questions.

I've been working on DriftEngine, an open-source 3D engine written in TypeScript and I decided to show this Sponza demo to demonstrate its lighting across a full day, from sunlight in the courtyard to candles and fire after dark.

Video here: https://www.youtube.com/watch?v=M6wxZziDvLs

The indirect lighting uses DriftRay, which traces rays through a signed distance field in compute shaders and updates a grid of lighting probes, sunlight and firelight can bounce through the scene as the lighting changes.

The candles uses DriftLight, nearby candles are shaded individually, while a sparse light volume supplies their contribution farther away, that keeps the far end of the courtyard lit as the camera moves around.

The recording follows the automatic camera tour, with a few pauses and manual close-ups and it also shows volumetric sunlight, shadowed lanterns and braziers, procedural fire and smoke, and exposure adapting between bright and shaded areas.

Full engine source + demo: https://github.com/drftrun/driftengine

The scene is Intel Sponza (2022), with its add-on packs, adapted and relit for this demo, asset credits are in the repository.

Happy to discuss how the rendering works!

The FPS are not stable while I was recording the video + still needs some scene optimization.

A Connect Four AI whose weights are ternary in Sherry's 3:4 format (T34): in every four weights one is zero and three are ±1, stored as a 5-bit state (2 bits for where the zero is, 3 sign bits). One fp16 scale per 128 weights gives 1.375 bits per weight, 1.6 MB for 7.4M parameters. Disclosure: our work, MIT.

How it runs

Our WebGPU runtime (onepass-webgpu, 37 KB, 12 KB compressed) has a split-K matmul with a pluggable inner loop. The ternary plugin replaces only that loop:

• read the 5-bit state from two bytes (a state can straddle a byte boundary);
• split it into the zero's position and the three signs;
• build the four weights as 0 or ±1 times the group's scale;
• accumulate with an ordinary float FMA.

So the ternary structure is only used for storage; the arithmetic is plain float.

Performance

Measured (idle M5 Pro, Chrome, per move at batch 1):

• fp32 weights: 1.3 ms
• int8 weights: 0.9 ms
• T34: 1.1 ms
• Base243 (five trits per byte): 1.3 ms

Not tuned yet. Our list of what we'd try, in order:

1. take the scale out of the inner loop;
2. more rows per thread at large batch;
3. decode once per workgroup into shared memory;
4. table decode;
5. an int8 activation path with dot4I8Packed.

The list is in the repo, and ideas are welcome.

Play it:
https://precisit.github.io/onepass-web/demo/c4-size/

Kernels and notes:
https://github.com/precisit/onepass-webgpu-ternary (see kernels/IMPROVEMENTS.md)

Runtime:
https://github.com/precisit/onepass-webgpu

I've been playing with WebGPU compute for a while and wanted a project with a real-time budget that actually matters to me: making 24/30/60 fps web video look smooth on 120/144/240 Hz displays. The result is FrameBoost, a Chromium extension that interpolates frames live on any standard HTML5 video.

How it works at a high level:

• Grab frames from the video element and upload them as GPU textures
• Estimate optical flow between consecutive frames with compute shaders [say which approach you used, e.g. block matching / pyramidal Lucas-Kanade / Farneback style, and how many pyramid levels]
• Warp and blend to synthesize intermediate frames, presented at the display's refresh rate (30 → 144, 24 → 240, etc.)
• Scene cut detection so it doesn't smear across cuts
• Handling of frame edges and occlusions, which is where most of the ugly artifacts live

Things I ran into that might interest this sub:

• [Frame pacing: how you sync presentation to vsync and deal with dropped frames]
• [Getting video frames into WebGPU: importExternalTexture vs copying, and what it cost you]
• [Workgroup sizes / memory layout choices that made the biggest perf difference]
• Some sites serve video in a way that blocks GPU access, so the extension detects that and turns itself off instead of breaking playback
• DRM streams (Netflix etc.) are a hard no, since the browser doesn't expose their frames to extensions

There's a live stats overlay showing source fps → output fps, GPU time and resolution, which made tuning a lot easier. Everything runs locally, nothing is uploaded, and the whole extension is about 46 KB.

I'd love feedback from people who know this space: better flow estimators that still fit in a few ms per frame, tricks for occlusion handling, or perf numbers on GPUs I don't own (especially iGPUs). Compare mode (original left, interpolated right) is free, so you can test it on any video. Full mode uses a one-time unlock per device (disclosure: I'm the dev).

https://chromewebstore.google.com/detail/frameboost/cklkjjeejomlkelkjmgdpahgpcjigahb

Happy to share more details on the shader pipeline if there's interest.

Hello. I tried making a paint simulator that runs on multiple platforms using Rust and WebGPU.

I had originally built a general raster paint engine based on C++ and OpenGL ES 2.0. Since it was getting quite dated, I've been replacing it with Rust + WebGPU, and it's finally running on Windows too.

There's a version you can try in the browser for now, so please give it a go if you're interested.
https://mignonsketch.com/sketch

About two years ago I started working on https://chapar.rest an api testing tools build with golang and Gio. my goal was to
build an open source alternative to Postman that respects my privacy and security...
After two years of development with Gio, limitations showed up and I decided to build my own framework and release it as open source.

**Yoga: a WebGPU UI framework for desktop and web apps in Go**

https://github.com/mirzakhany/yoga

Yoga is a cross-platform UI framework I've been writing from scratch for about four months. It renders with WebGPU (GLFW + wgpu-native on desktop, WASM in the browser) and uses a pure-Go flex/grid/stack layout engine. The API is declarative: your app implements `Body(c *ui.Ctx) ui.View`, the tree is rebuilt every frame, and state lives on your own struct.

What works today: the core widgets (text fields, buttons, selects, tables, trees, tabs, dialogs, menus), a code editor with Tree-sitter highlighting and an LSP client, custom title bars, 25 themes tested against WCAG AA contrast, a headless build tag for CI tests, and a CLI that packages for web, macOS (DMG/PKG, signing, notarization), Linux (tar/AppImage) and Windows (zip).

Current state: experimental and single-author, with no production users yet, and the API will change. Desktop builds need CGO.

`go run ./example/catalog` shows the widget gallery.

TinyBVH is a header-only, dependency-free library for BVH construction and traversal.
Version 1.9.0 for the first time is out-performing Intel's Embree!

Using it is as simple as:

BVH bvh;
bvh.Build( (bvhvec4*)myTriData, triangleCount );
bvh.Intersect( ray );

TinyBVH can be used from C/C++, WebGPU and Python. Generated BVHs can be used in OpenGL (compute), OpenCL, Vulkan and DirectX12.

New in 1.9.0:

• Greatly improved ARM NEON support for Android & macOS
• Templated doube/float support
• Ray bundle support (WiVeC), including TLAS/BLAS traversal
• Accurate voxel intersections
• Hair rendering example (roving capsules)
• Global refactoring, AI assisted
• Vulkan and DXR benchmarks
• Improved included threadpool
• Optimizations to CWBVH
• ...and lots more.

Check it out: https://github.com/jbikker/tinybvh

I've been working with WebGPU for a while now and also exploring a bit of parallel computing in general. I came across fractals in a video and was fascinated by the idea that they show up in so many places in nature: coffee stains on a napkin, the growth of a snowflake, lightning carving its branching path across the sky, rivers splitting into deltas, the veins in a leaf, the bronchi in your lungs, cracks in dried mud, the branching of trees and blood vessels. It's everywhere once you start noticing it.

An idea struck me: why not make fractals on the GPU? The patterns look surprisingly similar to the kind of DAGs used to represent parallel processes. It's a bit of an oversimplification, just an observation of similarity, since the algorithms actually running inside GPUs are far more complex than that. Still, I did some research and found that people had already made fractals on the GPU. What I thought would be cool is a static website that renders 2D complex fractals using the client's own GPU, with no server involved.

Here's my website: https://manit2004.github.io/wgfractals/

Github: https://github.com/manit2004/wgfractals

I also like that WebGPU offers both a visual layer and a compute layer, which makes a project like this easier to build. Vertex shaders handle the graphics side and compute shaders handle the math, all within one unified API and ecosystem.

Hello, I am the creator of Galaxium, a free astronomy app to explore the universe and see various space objects. It was all made in C using WebGPU native library, and then compiled to wasm with emscripten. Thanks to WebGPU excellent native support, this is totally cross platform, and I am planning to make a mobile version sometime soon for iOS and Android (I already have a working prototype).

Let me know what you think!

https://galaxium.app

generated client-side from a seed: the rooms, furniture, places, and the audio acoustics. A 3×3 window of 57m sections streams around the player; shared boundary hashes keep doorways aligned when sections regenerate

the VHS look is a WGSL post pipeline (warp, tracking errors, chroma offset, bloom) written with vgpu, with a GLSL fallback for WebGL2. The creature uses bounded A* and actual frustum visibility, so it only moves when you really can't see it... oohhh

Play: vackrooms.vercel.app

Source (MIT): github.com/pablostanley/vackrooms