I don’t think I need to tell you that AI is popular—it is. We are in an AI popularity bubble. But I do not think people are prepared for where it is going. AI is nowhere near saturated.

My brother’s requests changed from “Could you build this website?” to “Can you vibe this website in a few minutes?” Nature is healing, or nothing really changed. People still expect software to cost, be secure and hygienic, and come with support. AI has not yet markedly convinced non-technical people that they can make it themselves.

We have popularity without saturation.

The expensive hobby phase

My AI usage can punch upwards of $3,000 in a month. Most of it is coding, since my craft is software engineering, while a very small amount is personal AI use. Most of my AI coding use will stay the same or increase—I believe coding everything by hand will not be generally competitive for long. However, even on my software engineering team, there are varying levels of saturation. In the graph below, my usage is roughly four times higher than the next-highest coworker. I do not attribute this to working four times as hard; I see it as evidence that even software engineers have not reached high usage.

This makes me a terrible example of normal AI use, but a useful example of its upper end.

I am not using personal AI tools much. I have tried OpenClaw, but I found its usefulness shallower than the public perception. Instead, I find it’s easier than ever to create exactly what I want - zero to one. I have my own daily agenda app with some modest AI capability. I have made my own messaging bots I can interact with to perform certain tasks.

But no tool in existence yet integrates my development workflow on a scalable platform and manages my day. Most tools I use are tools I visit, or maintain, and occasionally forget about.

And this feels familiar. Five years ago, my personal infrastructure was a homelab built from five Raspberry Pis running k3s with RAID storage, redundant networking, independent power switches, and a cooling solution. It was fun. But it also cost hundreds to thousands of dollars and required enough maintenance to qualify as a small, unpaid operations team.

Now my homelab collects dust in my garage, and my personal projects live in my AWS account. That includes this website, my daily agenda app with a database, some business projects, a few Discord bots, and more. My monthly AWS bill is on average $0.09.

Innovation made that possible. Services like Amazon DSQL—a distributed, serverless relational database with zero idle cost—became generally available and gave me a reasonable home for my daily TODOs, health data, and more.

The homelab was useful, but maintenance-heavy and expensive. The cloud turned this into a cheap commodity. I expect AI to follow the same curve.

Cheap enough to forget

AI is prohibitively expensive when used as aggressively as I use it now. That will not last. Models will get smaller, hardware will improve, inference will become more competitive, and providers will keep finding cheaper ways to serve the same useful unit of intelligence. Capability has been getting cheaper, and that is likely to continue. Anthropic raising free usage limits may be another sign of that pressure reaching users.

My prediction is not merely that AI gets cheaper. It becomes cheap enough that ordinary people stop thinking about the meter.

That affects how I think about the broad AI trade in public markets. This is not investment advice. I am personally wary of betting on scarcity when the product looks destined for commoditization. Subsidized competition from China and other countries could force prices down further, although some protected markets—government and defense come to mind—may behave differently.

Saturation looks like a personal manager

AI reaches saturation when most people use it to manage their lives, not infrequent use of a chatbot like Gemini.

Everyone will need something like an OpenClaw in roughly the same way everyone now needs a phone or access to the internet. It will be competitive, and it will understand the annoying surface area of a day: messages, appointments, tasks, files, forms, reminders, purchases, and the small promises we make before immediately forgetting them.

It has not yet arrived for me, even though the AI usage attributable to me could finance a bad habit.

I am, however, coding personal tools more frequently. I see this trend growing independently; “AgenticOS” tutorial series are becoming quite popular on YouTube.

These “OS” tutorials are really just slop dashboards, but I get the allure. Who wouldn’t want JARVIS from Iron Man? Here is the gap - doing this right requires scaling, maintenance, and hard integration work. These are fun experiments for AI enthusiasts. A useful personal manager would need a phone companion, sensible alerts, durable memory, authorization, and recovery when an agent does something stupid. Most people watching these tutorials should not need to learn how containers work before asking software to remember a dentist appointment.

And even worse, OpenClaw. There was a magic spark when I tried it, but that faded quickly. The interface was slop, and its security model did not earn my personal data.

Someone will eventually make the Apple-like quality version of OpenClaw: narrow enough to understand, polished enough to trust, and useful before the user has configured forty integrations. When that happens, the world will come to it. Until then,

A hostile launch environment

A loud part of the public is vehemently against AI.

People see companies exploiting the political system, building data centers that may raise local water and electricity costs, expecting a government bailout, and burning cash without a believable return. Some of those concerns are measurable. Others are projections. A credible personal AI platform will have to survive all of them.

Saturation will only make this launch environment more hostile. Adoption and acceptance are pulling in opposite directions: more aggregate compute means more electricity, cooling, and water demand. Global nervousness about AI is rising while excitement drops. Models and data centers will get more efficient, but cheaper intelligence will also invite us to use much more of it.

I think we will literally need an act of Congress: national rules deciding when data centers pay for the infrastructure they require, how scarce resources are allocated, and what costs can be passed to everyone else. AI companies want government assistance, but it needs to be politically favorable, or public opposition to AI will continue to harden.

The winning product cannot merely be capable. It must be cheap, boring, secure, and visibly worth the infrastructure behind it.

Five years, probably

My guess is that we are at least five years away from saturation, unless another ChatGPT-sized viral moment pulls the schedule forward.

By around 2031, I expect a credible personal agent to be common on phones and personal devices. It should:

• behave like a normal app;
• have understandable permissions and mistakes;
• cost little enough that use is not a financial decision; and
• become a meaningful part of the day.

The final signal will not be another benchmark. It will be my brother building the software for his shop without asking me anything.

And if he leaks the customer database, we are only halfway there.

Download

• Slides (Google Slides)
• Slides (download .pdf)
• Slides (download .pptx)

Citation

Please use the following attribution, if needed:

• BibTeX

@misc{imbleau-2024,
    author = {Imbleau, Spencer},
    month = {8},
    title = {{Compute-centric vector graphics using bevy_vello}},
    year = {2024},
    url = {https://www.youtube.com/watch?v=VQGQhotekvY},
}

• BibLaTeX

@video{imbleau-2024,
    author = {given-i=SCI, given=Spencer, family=Imbleau},
    date = {2024-08-01},
    title = {Compute-centric vector graphics using bevy_vello},
    url = {https://www.youtube.com/watch?v=VQGQhotekvY},
}

• APA (7th Edition)

Imbleau, Spencer & Rustunit. (2024, August 1). Compute-centric vector graphics using bevy_vello [Video]. YouTube. https://www.youtube.com/watch?v=VQGQhotekvY

Yes, the image model that uses points, lines, and equations to encode image data. Of which, several common encoding formats exist, such as like SVG and PDF.

The internet has done this once meaningfully in the past. In the 2000s, a herculean effort to optimize the performance of interactive vector graphics brought an advent of vector games through Adobe’s Shockwave Flash player. But in the wake of SWF’s deprecation from major browsers, there wasn’t a worthy successor, and the era of web games died off. Unfortunately, efforts like HTML5 and WebGL were never able to replace what was lost.

Hence, I believe the first games to understand and successfully use this image model under the constraints of major browsers could benefit from content-delivery savings, resolution independence, and offer novel applications of interactivity, physics, and non-destructive transformations.

Onto the papercuts

Vector images are notoriously unfit for modern GPU architecture because of an inherent locality issue. In contrast to raster graphics where color and fill information is explicitly encoded, rendering a pixel in a vector image requires knowledge of the entire image. Efficiently solving the fill of every pixel in realtime poses a unique challenge. With the rising accessibility of compute kernels and low-level GPU architecture access over the past few years, especially from projects like wgpu, friction with general purpose GPU computing is fading. Projects like vello are pioneering the 2d vector graphics space, and furthering the experimental research inspired by projects like pathfinder.

The high-level strategy used by these new hardware-accelerated renderers is to create a compute-centric pipeline with a sort-middle architecture to parallelize the problem space efficiently. This is a technical leap in recent years and its efficiency will be hard to challenge.

Vong

The technical leap was implemented in vello (formerly piet-gpu), started by Raph Levien and my colleagues in the linebender community. The Vello API depends on WebGPU to provide an abstraction layer to targets, while offering more accessibility to low-level hardware like compute shaders. It’s for these reasons rust, webgpu, and vello would make a perfect combination for cross-platform vector games with one code-base.

This spurred on my race to prove the lost benefits are still relevant. In a sudden case of reviving-the-horse syndrome, I worked with a few colleagues from my previous tenure at NASA to understanding the unknowns of why I’ve never seen a modern Kurzgesagt vector game. Hence, the decision to start by creating the classic game of Pong was deliberate, providing a foundational exploration of Vello’s capabilities in rendering vector graphics dynamically. It felt appropriate to call the project Vong, joining “Vector” and “Pong”.

Matching webgpu, vello, and rust’s strengths, bevy was the obvious choice for a cross-platform open source game engine. It also uses webgpu, and was developed open-source and code-first.

Rendering integration

Standing in the way of seeing my first Ghostscript Tiger (the Hello, World! of vector graphics) was an integration to render vector assets in bevy with vello. Sebastian Hamel (@seabassjh) and I (@nuzzles) developed that integration in the open, bevy-vello. Just like any other ordinary asset in bevy, such as a png, there are no surprises:

// Bevy 0.12
fn setup_assets(
    mut commands: Commands,
    asset_server: ResMut<AssetServer>
) {
    // Load image of egg
    commands.spawn(
        VelloVectorBundle {
            vector: asset_server.load("egg.svg"),
            origin: bevy_vello::Origin::Center,
            transform: Transform::from_scale(Vec3::splat(0.1)),
            ..Default::default()
        }
    )
}

Architecturally, bevy-vello was built with two backends. The first is an .svg ETL library called vello-svg which loads the SVG using the vello SceneBuilder API. The second is vellottie, a parser and runtime for Airbnb’s .json lottie format, and a rewrite of Chad Brokaw’s lottie runtime, “velato”.

Strategically, it made sense to pursue both formats, but a painful lesson learned was that the .svg and .json lottie specifications are huge, with plenty of feature flags that aren’t supported by vello. While writing a parser wasn’t too challenging using the serde parsing library, dealing with animation inconsistencies and rendering artifacts remains a difficult task. Currently, vello is writing CPU shaders to help triage these artifacts. But for the future, I’m inclined to support only lottie formats, since any SVG could be reformed into a 0 frame-rate lottie animation. One of the biggest obstacles in commercial viability is artist tooling, so I’m keeping an eye on companies like LottieLab, Phase, and Rive.

Physics

Once rendering was solved, another thorny issue with pong was physics: collision detection between arbitrarily curved shapes is really hard. While some algorithms exist, none today are obviously good.

Eventually I settled on tessellation as a decent proxy for physics. The technique is quite simple in concept.

First, curves are flattened into line segments with configurable accuracy (aka “tolerance”).

Attribution: Image from Lyon, licensed under MIT/Apache 2.0

Then, vertices are paired to generate a triangle mesh. The resulting triangle mesh is used to derive a convex hull hitbox.

Attribution: Image from Lyon, licensed under MIT/Apache 2.0. Modified by Spencer Imbleau.

This is obviously not true collision detection between arbitrary curves with infinitessimal precision, but was rather a compromise given a lack of algorithmically efficient collision detection between curves.

As with most things in game development, this is a hack, but a good one! Even when using a liberal tolerance for curve flattening, physics yield a high level of collision fidelity, nearly indistinguishable from the true underlying curves. Granted, this only works great since my egg is convex in nature.

The lyon library was used for tessellation and bevy_rapier was used for collision detection, linear velocity, and angular momentum.

Demo

Is the frame immediately below solid black? Vong uses compute shaders. Make sure your browser is updated to Chrome M113 or another browser compatible with WebGPU!
Edit 1/31: It seems Firefox Nightly, even with the WebGPU flag, is having issues. For now, please use Chrome.

Controls:

• Up/Down (Arrow keys): Scale camera
• PgUp/PgDown/Home/End: Free camera
• W/S: Left bacon
• I/K: Right bacon
• C: Watch egg intensely

You may find the source code here. You may also build and play this natively with cargo run.

What now?

I look forward to following up with future development on vector games. I’m committing this year to publishing more about where this is all leading, but for now, please keep in touch. The next blog planned is on WebRTC to bring our games to life with multiplayer.

Introduction to NVTX

NVTX is a C-based API for annotating events, code, and resources in your application. These annotations get captured by NVIDIA profiling software, such as NSight Systems². Emitting tracer annotations during the runtime of your program can help identify key issues such as hardware starvation, insufficient parallelization, expensive algorithms, and more. Later in this post we will explore an example (#show-me).

Thankfully, one of Rust’s promises is its ability to interoperate with C APIs through foreign function interfacing (FFI) at identical performance³. This is called a zero-cost abstraction, and allows us to call NVTX functions with identical performance to C, in Rust.

NSight Systems

NSight Systems is a feature-ruch CLI and GUI profiler which executes a command and samples certain opt-in measurements you subscribe to. For example, if I instruct NVIDIA Nsight Systems to run a binary, Nsight Systems will launch the binary on my behalf, collect measurements while waiting for termination, and deliver a report file. In that order.

These reports can be better understood with annotations from my nvtx crate. With it, you may name your threads, add markers, and annotate timespans. Tracers emitted during program runtime appear on the NVTX layer of a report file when capturing NVTX annotations. The following image shows an example of some tracers, with nothing else captured.

Code

The following sections provide some examples which demonstrate how trivial it is to augment runtime with annotations.

Markers

Firstly, I will show markers. Markers are used to tag instantaneous events during the execution of an application. For example, dropping a marker can be used to annotate a step in an algorithm.

Markers are injected with the mark! macro, which accepts a name for the event. It behaves similarly to the println! macro with argument formatting.

use std::thread::sleep;
use std::time::Duration;

use nvtx::mark;

fn main() {
    mark!("Operation A - Begin");
    sleep(Duration::from_millis(150)); // Expensive operation here
    mark!("Operation B - Begin");
    sleep(Duration::from_millis(75)); // Expensive operation here
}

Thread ranges

Thread ranges are similar to markers, except they annotate a span of time, rather than an instant of time. For example, a thread range can track the total time of an algorithm or process.

Ranges are pushed with the range_push! macro, and popped with the range_pop! macro. Thread ranges are also safe to push and pop over thread boundaries, hence thread in the name.

use std::thread::sleep;
use std::time::Duration;

use nvtx::{range_pop, range_push};

fn main() {
    range_push!("My Range");
    sleep(Duration::from_millis(100)); // Expensive operation here
    range_pop!();
}

Thread naming

Lastly, threads can be named with the name_thread! macro. This macros will alias the calling OS thread with a friendly name. Currently, this macro works cross-platform and has been tested on MacOS, Windows, Linux, and Android.

use std::thread::sleep;
use std::time::Duration;

use nvtx::name_thread;

fn main() {
    name_thread!("Main Thread");
    let handler2 = thread::spawn(|| {
        name_thread!("Thread 2");
        sleep(Duration::from_secs_f32(0.2));
    });
    let handler3 = thread::spawn(|| {
        name_thread!("Thread 3");
        sleep(Duration::from_secs_f32(0.3));
    });
    sleep(Duration::from_secs_f32(0.5));
    handler2.join().unwrap();
    handler3.join().unwrap();
}

Show me

To demonstrate NSight Systems, NVTX, and Rust, I will present a finding I organically stumbled upon when writing a naive SVG renderer using Lyon and wgpu.

Situation

My task was assessing if tessellation could have any usefulness in optimizing vector graphics. Vector graphic renderers solve a very complicated problem; they don’t simply read rows of pixels like in raster graphics. You may imagine an SVG file as a composition of overlapping paths and lines, and a renderer must decide on varyings (scale, viewbox, etc.) to calculate the image.

Vector tessellation makes this easier. The idea is to transmute mathematical paths, curves, and lines into discrete triangles, a friendlier format for GPUs. My renderer would cache the triangle geometry in a storage buffer and re-use the work to inexpensively redraw the SVG.

I chose some sample images as an organic range with varying complexity, and proceeded to benchmark the frametimes.

Results

The benchmark was simple: render 50 frames and record how long each frame took. The results are plotted below.

Tessellation-time was not plotted here, and no frame was rendered any differently. So to my surprise, why was the first frame taking longer? Using the power of NVTX annotations, I dropped some tracers to understand the instructions temporally. I annotated the first frame as “Strange Behavior”.

To my surprise, it seemed like the GPU wasn’t working hard until the 2nd frame. The reasoning would be that wgpu (the graphics library I used) submitted the queue of geometry in the first frame. What we are witnessing is gpu latency, specifically, the time to transfer the geometry to the GPU storage buffers and return. This became an obvious que when able to inspect and see a timeline with ques: blocked state, PCIe bandwidth, and GPU occupancy.

This is one example of how annotations have helped me, and work will continue to help in more ways.

Features in progress

I have only ported a fraction of the NVTX SDK, and there are some noteworthy features outstanding. NVTX can be used to measure CPU code blocks, track lifetime of CPU resources (e.g., malloc), log critical events⁴, and more. I’d love to port filtering tracers by domains and resource naming. Feel free to contribute or check out the issue board.

I will especially do so in my favorite topics, such as open source, technical subjects, and lifestyle (as a programmer).