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.
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:
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.
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:
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):
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.
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.
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:
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).
wgpu is an implementation of the WebGPU API, so it's basically an alternative to Dawn.
gpu.cpp is one level up - it's implemented using the WebGPU API, not an implementation of the WebGPU API. In theory it should work with both wgpu and dawn but in practice you find there's enough differences it takes some conditional branching + testing to support both.
Having both wgpu and dawn support would be nice and I think we'll get there in the coming months but for faster early iteration I wanted to keep things simple for now. There's implementation + maintenance + testing overhead that you start to have to carry around so it isn't free.
The data that is out there is reasonably promising with WebGPU already in use in some production ML inference engines. TVM of course is way ahead of the curve as usual - https://tvm.apache.org/2020/05/14/compiling-machine-learning... though this post is quite old now.
It's still early days for pushing compute use cases to WebGPU (OctoML being super early notwithstanding). There's a small matmul in the examples directory but it only has the most basic tiling optimizations. One of my goals the next few weeks is porting the transformer block kernels from llm.c - I think that will flesh out the picture far better. If there's interest, happy to collaborate + could potentially do a writeup if there's enough interest.
There's always some tradeoffs that comes with portability, but part of my goal with gpu.cpp is to create a scaffold to experiment and see how far we can push portable GPU performance.
You're probably better prepared than you think. The funny thing is after working on making compute workflows work with graphics APIs like vulkan and webgpu, CUDA is so user friendly by comparison :)
Windows should work since WebGPU can target DirectX or Vulkan and it should be possible to build in WSL.
However I was planning to announce next week after I've had a chance to test with my Windows-using colleagues and this thread came early, so it's possible we'll run into some hiccups.
I've had hour long conversations explaining the project talking about how webgpu can be used natively, how rust and zig people are using webgpu as a main GPU APIs (with wgpu and mach) and at the end there's still clarification questions about differences from WebGL and WASM.
The phrase "native webgpu" might as well be a Stroop Effect prank in technology branding.
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.