austinvhuang
Joined 5 years ago
Karma
181
Submissions
46
Member since
Oct 17
Recent submissions
Comment · 3 months ago
Comment · 3 months ago
Will have some video demos soon, but for now here's a few screenshots of it in action:
- Codex using it for notes and html visuals: https://postimg.cc/CzfXZfjP
- Visual prototyping space for a meal planning app: https://postimg.cc/rKt3dtSv
- Coordinating multiple agent workstreams on a deployment (agents are all updating the desktop contents): https://postimg.cc/ppn49nD4
- Agents commenting on a markdown doc: https://postimg.cc/3dDVyDgs
Comment · 5 months ago
Information processing in organisms likely resembles NCA more than feedforward/backprop of neural networks.
Comment · 8 months ago
Some may also find Junji Hashimoto's GPU programming library in lean (w/ webgpu) interesting:
https://github.com/Verilean/hesper
Even includes an example of transformer inference (quantized 1.5 bit):
https://github.com/Verilean/hesper/blob/a688ce9848d6416b2e95...
Comment · 9 months ago
I don't have firsthand knowledge, but r/SesameAI seems to believe Maya/Miles products are based on a Gemma3 backbone.
Comment · 9 months ago
My first implementation of gemma.cpp was kind of like this.
There's such a massive performance differential vs. SIMD though that I learned to appreciate SIMD (via highway) as one sweet spot of low-dependency portability that sits between C loops and the messy world of GPUs + their fat tree of dependencies.
If anyone want to learn the basics - whip out your favorite LLM pair programmer and ask it to help you study the kernels in the ops/ library of gemma.cpp:
Comment · 1 year ago
Been following makepad for years. Congrats!
Comment · 2 years ago
author here - WebGPU Puzzles is a web incarnation of Sasha Rush’s GPU Puzzles - a series of small, fun, self-contained coding challenges for learning GPU programming.
gpupuzzles.answer.ai
Using WebGPU, you write code in the browser and computation runs entirely locally on your GPU.
Comment · 2 years ago
The raw WebGPUAPI is geared towards infrastructure type of usage, eg ML compilers, game engines, etc and is pretty verbose for application and research use cases.
Under examples/, for pedagogical purposes + help contributors understand what happens with WebGPU under the hood, I actually included an example of invoking the same GELU kernel as in the hello world example without gpu.cpp. It looks like this and is ~ 400+ LoC and also will take several minutes to build Dawn:
https://github.com/AnswerDotAI/gpu.cpp/blob/main/examples/we...
A goal of gpu.cpp is to make the power of webgpu much less painful to integrate into a project without having to jump through as many hoops (+ also sets up the prebuilt shared library so builds are instantaneous and painless instead of reams of cmake hassles + 5-10 minutes of waiting for dawn to build):
https://github.com/AnswerDotAI/gpu.cpp/blob/main/examples/he...
Comment · 2 years ago
Yes wgpu is a much lighter build and has a lot going for it.
The situation has gotten a lot better for both dawn and wgpu integration in C++ with:
https://github.com/eliemichel/WebGPU-distribution/
Getting a shared library build was a revelation though, credit to:
https://github.com/jspanchu/webgpu-dawn-binaries
because the FetchContent cache invalidations would still periodically lead to recompiling which gets quite annoying. When it's just a matter of linking you get few-second builds consistently. The cost is we'll have a bit of hardening around potential ABI bugs but it's ultimately worth it.
We'll work towards wgpu support. There's some sharp edges in the non-overlap w/ dawn which seem most pronounced with the async handling (which is pretty critical), but I don't think anything is a hard blocker.
Comment · 2 years ago
Part of the goal is not to get in the way if there's other aspects of a project that talk to WebGPU directly. If you're already using WebGPU the correspondence should be pretty familiar if you look at the `gpu.h` source. We specifically avoided extra layers of indirection so that you can mix in direct calls against the WebGPU API when needed.
Comment · 2 years ago
See https://news.ycombinator.com/item?id=40952182#40957959
It's early but my current since WGSL -> SPIRV is fairly shallow mapping you should be able to get close modulo extensions. Extensions can be important though, in particular I'm tracking this closely:
https://github.com/gpuweb/gpuweb/issues/4195
One subgoal of gpu.cpp is to be able to have a canvas to experiment and see how far we can push the limits.
Comment · 2 years ago
Fair enough - I don't think there's any hard blockers to doing this, but to get the same QoL we'll want to add a dawn dll to the available prebuilt binaries and adjust the download script.
Will look into this in the coming weeks (or if anyone is up for contributing let us know).
collaborate.dev is free. Nothing to install or setup. No account is required (login is optional).
Just copy + paste the instruction prompt into your agent. Then give the agent any task to work with you on the desktop.
What can you use it for?
*Multiplayer Context* - collaborate.dev is multiplayer - multiple people can join the desktop and you all see cursors and changes in real time. Place skills, research, guidelines, and articles as text or html right on the desktop. Share the agent instructions with your team and you can build/reuse agent context together.
*Multiplayer Documents* - Work on multiple documents on the desktop, co-edit them gdocs style with realtime multiplayer editing and commenting (agents can edit + comment too).
*Visual Artifacts* - organize and compare HTML outputs side by side in a unified space, deploy them to a sharable link with a click. Draw on the canvas itself label/organize artifacts spatially.
*Multiagent Coordination* - Beyond teams of people, desktops can be used to coordinate teams of agents. They can check status of different work streams, comment on each others’ plans, share knowledge with each other directly without you having to juggling and copy-pasting between windows.