TheDaily Front

A soundness bug in the Lean kernel (#14576) was reported and fixed during the week of July 27. It has had visibility on Zulip and social media (e.g., X, LinkedIn, and Mastodon).

What happened

On July 25, Ramana Kumar published a repository containing a sorry-free "disproof" of the Collatz conjecture, produced with AI assistance. It is not a valid proof because it exploits a bug in the kernel's handling of nested inductive types. On July 28, Kiran Gopinathan reduced it to a small proof of False and opened issue #14576. We pushed a fix one hour after the report (#14577). Joachim Breitner reviewed it and suggested improvements, and it was merged. New patch releases are out.

The bug: when the kernel eliminates a nested occurrence under an inductive type T with parameters Ds, and these parameters are phantom (not mentioned in constructor fields), they disappear from the generated auxiliary type and thus escape type checking. An ill-typed argument in that position could be used to make the kernel accept a proof of False. The bug is only reachable through metaprogramming, by sending the inductive declaration to the kernel directly. The frontend checks the arguments and catches the ill-typed term. This is an implementation bug, not a hole in Lean's meta-theory.

Why nanoda did not catch it

The original Collatz repository also passed a week-old version of nanoda, the main external checker. nanoda is an independent kernel (aka proof/type checker) for Lean implemented in Rust by Chris Bailey. The surprising part is that there are two unrelated bugs involved. The official kernel had a missing check in the nested inductive type support, as explained above. nanoda did check that spot, but did not verify the type name in a projection node. The nanoda bug was reported by Jeremy Chen and fixed a week before the Lean bug was reported. The proof was built so that the expression the kernel never inspects is one that the old nanoda accepted.

Ramana believes the timing was coincidental, but cannot rule out that the model had seen the nanoda report. Joachim proposed the hypothesis that the timing coincidence is due to the availability of strong models able to find this bug.

The practical consequence: checking with an independent kernel still works, since it required two distinct bugs in two implementations, but users who rely on it need current versions of both. lean4lean is affected by the kernel bug, since its handling of inductives is a port of the reference implementation.

Verification

Mario Carneiro's lean4lean is a Lean formalization of Lean's type theory together with a proof that the kernel implements it. The work is ongoing, the proof of consistency does not cover inductive types yet, and the to-be-verified implementation suffered from the same bug as the official kernel. The bug would have been found when attempting to conclude the verification of this part.

On removing metaprogramming

One suggestion in the discussion is to remove or restrict metaprogramming so that this attack is not expressible. This is misguided. The elaborator is untrusted by design. Soundness cannot depend on an untrusted component refusing to build a bad term. An attacker who wants to submit a malicious proof can also write .olean files directly or modify memory, both of which bypass the elaborator entirely. The kernel has to reject ill-typed declarations on its own, in its own process. This separation and isolation of concerns is one of the main advantages of proof terms.

What the FRO is doing

• Regression tests for the exploit, and for a related non-uniform-parameter case raised by Arthur Adjedj, are in the Kernel Arena.
• A follow-up PR (#14582) makes the kernel check that the parameters of a nested occurrence actually behave as parameters, rather than only re-type-checking them.
• Daniel Selsam at OpenAI assisted the Lean FRO with an AI specialized in cybersecurity, and found other programming mistakes in the Lean kernel. All of them have been fixed. All of them were caught by nanoda. These bugs are also only reachable through metaprogramming. PRs: #14607, #14608, #14609, #14613, #14615, #14616.
• We have also hardened kernel invariants. PRs: #14621, #14631, #14632.
• comparator.live now runs nanoda by default, and nanoda is tracked daily so lean-eval and comparator stay current after upstream fixes.
• We are reaching out to and supporting experts who can find further bugs, develop new kernels, and work on the theory or on verified kernels.

Acknowledgments

I am grateful to Joachim Breitner and Sebastian Ullrich for their revisions and suggestions on this post.

Website: https://explorative-modeling.github.io/ GitHub: https://github.com/alexiglad/XM

TLDR: We introduce Explorative Modeling, a new paradigm for generative modeling that acts as a third pretraining axis when added to existing generative models, and also enables end-to-end generation. Increasing exploration monotonically improves existing models across images, video, and language, and the gains grow with scale (7%→36% with data, 13%→23% with parameters). Concretely, Explorative Models (XMs) reach 6.2× sample efficiency, 4.1× FLOP efficiency, and 47% better parameter efficiency. Exploration also enables scaling generalization, and scaling how end-to-end existing models are. As end-to-end generative models, XMs match diffusion on control tasks with up to 256× less inference compute.

Let me start with a question that sounds simple. If I ask a model to “generate a dog”, how many correct answers are there?

It turns out there are a lot… likely billions or more images that we could count as dog images.

So what happens if we train a neural network to directly predict dog images? The model sees thousands of different valid dogs during training, and the single prediction closest to all of them is their average. That’s what the model learns to output, and the average of thousands of dogs looks nothing like a dog, it’s a brown blur.

A real dog from the data

→

What the model predicts

Figure 1: Training a model to directly predict images gives you the average of them all, a brown blur. This is why direct regression doesn't work for generative modeling.

To make this concrete, let’s play a game. I’m going to throw darts at the board below, and each dart will land somewhere random on the rings. Your job is to guess where my next dart will land, and the further off you are, the worse your score.

Figure 2: The dartboard for our game.

So where should you guess? It turns out the guess that minimizes your error is the exact middle of the board.1 We trained a model to play this game, and sure enough, it guesses the middle every time (this is the optimal prediction here)!

Figure 3: A model playing our game (blue) guesses the middle of the board.

This is terrible though… the middle is almost never where a dart actually lands. The “optimal” guess is a spot that no darts ever land.

This is the core problem of generative modeling. When a prediction has many valid answers, the best single prediction is their average, and the average of data is generally a bad answer that looks nothing like the real data.2

And this problem isn’t special to dartboards or dogs, it shows up with any kind of data. When we trained a model to directly generate three piles of 2D points, it predicted a single dot in the middle of them, and when we trained one on text, all it could say was “the”.

Real data

What the model predicts

Ground truth text

Real data

Naive language model only says the word the

What the model predicts

Figure 4: Direct prediction collapses to the average on any kind of data.

But wait. ChatGPT writes coherent text, and image models generate really amazing images. Clearly this problem has been solved somehow, right?

It has, and every scalable generative model today solves it the same way, by breaking generation into many small steps during training, so each step has roughly one right answer. When a step has one right answer, there’s nothing to average, and the blur disappears.

Let’s look at how this works. Autoregressive models (like LLMs) predict one piece at a time, which in our game means never guessing the dart’s exact position all at once. Instead, you first guess only how far left or right the dart lands, and then given that, you guess how far up or down. Once you know the dart landed on the far right, there are only a couple places it could be.

Step 1: predict only the left-right position

Step 1: pick a left-right spot

Step 2: given the left-right position, only two small spots remain for up-down

Step 2: pick up-down, given left-right

Figure 5: Autoregression predicts one sequence element at a time. In our game, once the left-right position is chosen, the up-down prediction only has two small spots left to choose from.

Diffusion models do this differently. They start from pure random noise and take hundreds of tiny steps toward the data. Early on, their guess could still become any dart, but every step narrows the possibilities, so no single step ever faces many valid answers at once.

Start of denoising: the guess is pure noise and could still become any dart

Start: could become any dart

Partway through denoising: fewer areas remain

Partway: fewer areas remain

Near the end of denoising: mostly one small area remains

Near the end: pinned down

Figure 6: Diffusion takes small steps from noise to data. Blue shows the darts the model's guess (purple) could still become, which narrows with every step.

It turns out this is basically how every modern generative model works, by breaking the generation process into smaller pieces that can be predicted well. This includes LLMs, image and video models, and even newer few-step models like MeanFlow and consistency models. We refer to this idea of breaking generation into pieces as factoring generation.

This approach of factoring generation works, but it’s also evil for a couple of reasons. The first is that models get trained on a single step, yet run for hundreds or thousands of steps at inference, so their own imperfect outputs get fed back in as inputs, errors compound, and generations slowly drift away from anything the model saw during training. This problem is called exposure bias (I wrote a whole blog on why it’s evil), and it’s why video models melt into mush after ten seconds and why LLMs get less coherent over really long generations, directly hurting performance and generalization.

The second evil builds on the first, because that mismatch between training and inference means these models are never end-to-end, where an end-to-end model runs at inference exactly the way it was trained. End-to-end learning is what kicked off the deep learning revolution with AlexNet, and the lesson has held ever since… letting models learn everything directly from data beats hand-designing parts of the pipeline, and a model that runs the way it was trained is never forced into out-of-distribution territory. Nearly all of deep learning has gone end-to-end by now except generative modeling, and factoring generation is exactly what’s blocking it.

So ideally we’d stop factoring generation, but factoring is also the only trick we know that handles the many-answers problem. The natural question then is whether we could factor something else instead, and it turns out a generative model only has two processes, how it generates and how it trains. If generation is off the table, that leaves the training loop.

So what does factoring training look like? To answer this, let’s go back to our game, except this time I’ll give you twenty guesses instead of one, and only your closest guess counts. It turns out that with twenty guesses, guessing the middle becomes a terrible strategy. This is because you can now spread your guesses over the spots where darts actually land, lowering your error far more than the middle ever could. In other words, the winning strategy is to use your guesses to explore different answers.

And this is exactly what happens. When we train a model this way with twenty guesses (middle panel below), its guesses spread across the board!

XM with 2 guesses

2 guesses

XM with 20 guesses

20 guesses

XM with 200 guesses

200 guesses

Figure 7: When only the closest guess counts, guesses spread across the board instead of averaging.

Take a second to appreciate what just happened here. The darts land in the exact same places as before, but because we changed how guesses are scored, the best possible prediction moved from the middle of the board onto the spots darts actually land. This reveals something important, which is that the training objective alone controls what the best prediction is (the loss minimizer), and by changing it, we moved the loss minimizer from the average of the data onto the data itself.

This is Explorative Modeling. At each training step, the model explores K possible matches between what it generates and the real data, and only the best match gets trained. We call models trained this way Explorative Models (XMs). In the simplest case, this is literally, beautifully, a for loop:

losses = []
for i in range(K):
    generation = model.generate()  # e.g., from a different random noise
    losses.append(loss_fn(generation, data))
min(losses).backward()  # only the best generation gets gradients

Here’s what happens as we increase the exploration K on real data:

ground truth piles

Ground Truth

K=1

K=1 (no exploration)

K=2

K=2

K=5

K=5

K=50

K=50

ground truth images

Ground Truth

K=1

K=1 (no exploration)

K=5

K=5

K=20

K=20

K=50

K=50

ground truth text

Ground Truth

K=1

K=1 (no exploration)

K=2

K=2

K=4

K=4

K=8

K=8

Figure 8: More exploration turns averages into the real thing. One dot becomes three piles, a blur becomes real images, and "the the the" becomes real text.

If we zoom out, this figure actually hints at something much bigger. All of modern generative modeling is really about designing a training objective whose loss minimizer lands on real data instead of between it, and factoring generation and exploration are just two different ways of achieving this. We call this idea Mode Forcing, and it’s the theory that led us to Explorative Modeling in the first place, predicting almost every result in the paper before we ran the experiments. There’s a whole paper on Mode Forcing coming soon :)

Another thing worth noticing is that all of an XM’s extra work happens during training. For end-to-end XMs, generation itself is left completely untouched, staying a single step that works identically during training and inference.

The two factorization axes of generative modeling: factoring generation vs factoring training

Figure 9: Existing generative models factor generation, which blocks end-to-end training. XMs factor training instead.

So why does exploring more keep helping? It turns out that K controls how many distinct answers a model can commit to. With one guess, the model has to average everything, but with twenty, it can commit to twenty different answers that each specialize to a different part of the data. In the paper we call this capacity generative expressivity, the number of distinct answers a model can capture.

What’s crazy is that generative expressivity has been almost completely overlooked, to the point where the term didn’t even exist before this and the Mode Forcing paper.3 Yet it matters just as much as parameters and data. A model with a single parameter can’t do much no matter how much data you feed it, and in the exact same way, a model with a generative expressivity of one can’t do much no matter how many parameters and data you give it… its best possible output is still the blur (look at the K=1 column of Figure 8). For over a decade we’ve scaled parameters, which set what a model can represent, and data, which sets what a model can learn, while generative expressivity, what a model can generate, has stayed fixed, baked into the training objective. Factoring generation was the field’s fix for this, but the expressivity it supplies is frozen the moment you design the model, whereas exploration turns it into something you can actually scale. This is exactly why scaling generative expressivity through exploration is a third pretraining axis, and as we’ll see below, the empirical results back this up.

At this point we know what Explorative Modeling is, so how do we actually use it? Looking back at Figure 9, there are two ways, combining exploration with existing generative models, or using it as a standalone approach. Combining exploration with existing models is where the new pretraining axis comes from, whereas using XMs as a standalone approach is what enables end-to-end generation.

Let’s start with existing generative models. At first glance it might seem like they don’t need more generative expressivity, since factoring generation already handles the many-answers problem. But if you look closely, single steps inside diffusion or autoregression can still face many valid answers at once, meaning some blurring remains.4 Even worse, as models and datasets grow, parameters and data stop being the bottleneck while generative expressivity stays frozen, so we’d expect it to increasingly become the thing holding models back. If all of this is true, then adding exploration to existing models should improve them, with gains that grow with scale.

To test this, we added exploration on top of existing generative models while changing nothing else about their recipes, not even the hyperparameters.

We started with RAE, the ~state-of-the-art ImageNet generation recipe. Adding exploration reaches RAE’s final performance with 6.2× less data and 4.1× fewer FLOPs, and hits a ~state-of-the-art 1.43 FID on ImageNet 256 without guidance. The speedups also compound across recipes, where XRAE converges 6.2× faster than RAE, which itself converges 47× faster than the standard SiT recipe, making XRAE almost 300× faster to converge than SiT.

Exploration improves data efficiency on RAE Exploration improves FLOP efficiency on RAE

Figure 10: Exploration reaches the ~SOTA RAE recipe's final performance with 6.2× less data and 4.1× fewer FLOPs.

The same story holds on an optimally tuned SiT baseline trained at a third of the compute, where exploration improves FLOP efficiency by up to 52% and reaches the same performance with 2.5× less data.

Exploration improves data efficiency on SiT Exploration improves FLOP efficiency on SiT

Figure 11: On a SiT baseline, exploration reaches the same performance with 2.5× less data and 52% better FLOP efficiency.

There’s also a subtle hint hiding in these plots, where the compute-optimal amount of exploration grows over the course of training (look at the crossovers in the FLOPs plots), directly mimicking how the compute-optimal number of parameters grows with compute in Chinchilla scaling. This reinforces that exploration really is a new pretraining axis, along with some more results below.

We also tested this on domains beyond images, adding exploration to video generation and masked diffusion language models while varying only the amount of exploration. In every domain, more exploration steadily improved performance, with some video models gaining over 20%, and the gains showed no sign of stopping at the largest K we tested.

FID improves with exploration FVD improves with exploration

Exploration improves masked diffusion language models

Figure 12: More exploration improves image generation (top left), video generation (top right), and language modeling (bottom).

The most important result, though, is that the gains from exploration grow with scale. As data scaled, gains rose from 7% to 36%. As models scaled, gains rose from 13% to 23%. And the efficiency gains above more than doubled when we tripled the compute. This is exactly what you’d expect if generative expressivity is a real third axis. Small models are held back by parameters and data, but as those scale, the fixed generative expressivity increasingly becomes the bottleneck, and exploration is what relieves it.

Gains from exploration grow as parameters scale Gains from exploration grow as data scales

Figure 13: Gains from exploration grow with scale, from 13% to 23% as models grow (left) and 7% to 36% as data grows (right).

For reference, frontier training runs use roughly 10,000× more compute than our largest experiments. If these trends of gains growing with scale hold, the numbers here are probably a lower bound.

It turns out exploration improves generalization as well. To see why, remember that during pretraining the same input often gets paired with many different valid targets, which to a model that can only predict one thing looks like noise, and fitting noise is memorization. With exploration, each prediction instead trains toward the target it’s already closest to, so the targets become consistent and what looked like noise becomes structure the model can actually learn.5 We see this directly in our experiments, where models with more exploration overfit less on a fixed dataset and reach better performance (a best FVD of 30.0 vs 37.5 without exploration). In other words, extra training compute directly buys generalization, which I find especially exciting as data, not compute, increasingly becomes the bottleneck for large-scale training.

More exploration reduces overfitting and achieves better minimum FVD

Figure 14: More exploration overfits less on a fixed dataset, reaching better performance.

So exploration clearly works as a pretraining axis, but what about end-to-end generation? One of the biggest implications of generative expressivity is that factoring generation and exploration supply the exact same thing, which means they should be interchangeable. We demonstrate this directly below, where as exploration increases, the best-performing models use less and less generation factorization, meaning models that are more end-to-end benefit the most from exploration.

As exploration increases, the optimal number of generation steps decreases

Figure 15: As exploration increases, the best models use fewer generation steps.

This makes how end-to-end your model is not a fixed design choice, but rather something you can scale. We can scale end-to-endedness :)

Taking this to its limit, we trained fully end-to-end XMs, where sampling is exactly the same at training and inference. On behavior cloning, our Explorative Policy matches Diffusion Policy with a single forward pass instead of 100:

Method	Forward passes	Lift	Can	Square	Transport	Tool Hang
Diffusion Policy	100	100%	100%	94%	72%	86%
Explorative Policy	1	100%	100%	96%	74%	86%

And our Explorative World Model matches Diffuser on goal-conditioned world modeling with 16-256× fewer forward passes:

Method	Score (avg)	Forward passes (avg)
Diffuser	127.2	192
Explorative World Model	130.0	2.3

The reason this is even possible comes back to what each approach factors, where diffusion pays for its generative expressivity with generation steps at inference, while XMs pay for it through exploration during training.

So where does this leave us? If you train robotics policies, world models, image, video, or audio generation models, masked diffusion language models, or really any generative model whose predictions face many valid answers (i.e., models working on decently multimodal distributions), you can add exploration with a for loop, without touching your architecture or hyperparameters (there’s pseudocode on the website if you want to try). In our experiments, adding exploration improved FLOP efficiency, data efficiency, parameter efficiency, and generalization across every domain we tried, so there’s a good chance it does the same for you! The best way to predict whether XMs will help is to determine how many valid answers each of your model’s predictions faces. The more answers per prediction, and the bigger your scale, the more exploration has to offer, while predictions with one clear answer (less multimodal) will likely benefit less (although benefits are still possible, as the paper discusses and lightly experiments with).

This rule of thumb also explains why autoregressive LLMs are the one place we’ve tested so far where exploration hasn’t been an immediate win, since predicting the next token given a long context is already close to having one right answer, and LLMs have no natural latent variable to explore over. That said, we’ve already seen modest early gains in data efficiency for autoregressive LLMs, and we have several ideas for pushing further, such as multi-token prediction, which faces far more valid answers per prediction, or conditioning on a learned latent, which would give exploration something to search over. I believe exploration will eventually make LLMs more end-to-end and better-scaling too, it just needs more work.

Longer term, the two directions I’m most excited about are Reverse XM and gradient-based exploration. Reverse XM flips the search so that one generation searches over K datapoints instead of one datapoint searching over K generations, which costs almost no extra compute and in principle lets K grow to the size of the entire dataset. Gradient-based exploration would replace random guessing with directly descending the loss to find the best latent. Pushed far enough, either one turns generative modeling into pure search for good latents with a very large K.

Taking a step back, the coolest part of this project to me is where it all came from. It didn’t start with tinkering or a lucky ablation, it started with deeply understanding why generative modeling is hard, which to me was an aha moment that resulted in all of Mode Forcing and ultimately ended up resulting in predicting all these results beforehand. And if you look back, that’s exactly the path this blog just walked… we started from first principles, arrived at Explorative Modeling as a way to increase generative expressivity, and from there got both a new pretraining axis and end-to-end generation.

If there was one takeaway from this paper, I’d say it’s the following:

We scale the size of generative models and how much data we train them on… so why haven’t we scaled what they can generate?

Huge thanks to my collaborators Yilun Du and Heng Ji, and to everyone who supported this work! Check out the paper and website for more details/depth!

Citation

@misc{gladstone2026explorativemodelingunlockingpretraining,
      title={Explorative Modeling: Unlocking a Third Pretraining Axis and End-to-End Generation}, 
      author={Alexi Gladstone and Heng Ji and Yilun Du},
      year={2026},
      eprint={2607.27372},
      archivePrefix={arXiv},
      primaryClass={cs.LG},
      url={https://arxiv.org/abs/2607.27372}, 
}

Footnotes

1. Being scored by squared distance means your best guess is the average of all landing spots, and for rings centered on the board, that average is the exact middle. ↩
2. The formal name for this is a multimodal distribution, a distribution with many distinct peaks (called modes), where each mode is a valid answer. The paper talks about “capturing modes instead of averaging them”, which is this exact idea. ↩
3. To be fair, people have long known that generative models need to capture modes instead of averaging them, and problems like mode collapse are well studied. What’s been missing is formalizing this as a capacity of the training objective itself, and recognizing just how central it is. Mode Forcing’s core claim is that having enough generative expressivity is the most important property of a generative training objective, and that even modern approaches like diffusion and autoregression have a fixed amount of it, a fundamental limit that scaling parameters and data can’t fix. ↩
4. There’s fun indirect evidence for this. Classifier-free guidance, which nearly all image models rely on, improves samples by pushing them away from a blurrier version of the model. If models weren’t blurring at all, there would be nothing to push away from. ↩
5. This is similar to overparametrization, where models with more parameters than they strictly need generalize better because the surplus capacity makes good solutions easier to find. Surplus exploration seems to do the same thing for generation. ↩

Agentic AI applications are pushing LLM inference into a new regime. A request can now reach one million tokens from aggregated long prompts, tool calls, retrieval results, and multi-turn reasoning. During the text generation phase, each new token must attend to all previous tokens from the KV cache, so the kernel needs to repeatedly read past states from HBM. As a result, the performance bottleneck shifts from compute units to the memory system.

The AMD Instinct MI450 series GPU introduces a new set of hardware features for memory-sensitive AI workloads. This blog uses attention decode as a case study and discusses how to design a high-performance kernel on MI450. We will walk through core hardware features, explain how kernels can use these features, and showcase the performance of an optimized Gluon kernel, which achieves 85% of the peak HBM bandwidth on MI450 as an early result.

MI450 Hardware Overview

MI450 is a large step forward from the MI350 series for AI workloads. Compared with previous generations, MI450 provides more on-chip resources and larger HBM capacity with higher bandwidth. The following table summarizes the key spec changes between MI350 and MI450. A Workgroup Processor (WGP) is the hardware unit that runs a workgroup (named CU in earlier MI-series). In this model, one WGP contains four SIMD32 units, each with 32 lanes. Each SIMD32 has its own Vector General-Purpose Registers (VGPRs), which are used by the Vector ALU unit (VALU) and Wave Matrix Multiply-Accumulate unit (WMMA). All SIMD32 units in a WGP share the same Local Data Share (LDS) memory.

Specification	MI350 series	MI450 series
VGPRs per SIMD	512	1024
Max LDS per WGP	160 KB	320 KB
HBM capacity	288 GB	432 GB
HBM bandwidth	8.1 TB/s	19.6 TB/s

In addition to more on-chip resources, MI450 introduces a specialized hardware unit - TDM, to help move structured tensor data between global memory and LDS. With TDM, the kernel describes the target tensor to access using its memory address, shape, strides, and layout, then issues a bulk data transfer asynchronously. TDM helps accelerate memory access and also makes it easier to write pipelined kernels where compute and memory can be overlapped. This marks a significant change from MI350, where the kernel must issue many small vector loads to move data from global memory to LDS.

Features	MI350 series	MI450 series
Memory instruction	Global/Buffer load to LDS	TDM load to LDS
Load granularity	32/96/128-bit vector loads	Descriptor-based tensor tiles
Memory units per WGP	1	2

Moreover, MI450 further extends the workgroup model with workgroup clusters. A normal workgroup runs on one WGP, independently of other workgroups. A cluster lets several workgroups, each running on its own WGP, coordinate through hardware-supported cluster barriers. Workgroups that access the same data can use multicast loads to share data across WGPs. This gives kernels a way to express cooperation at a larger scope, without falling back to a separate kernel launch or using global memory for synchronization.

The figure below shows a kernel programmer’s view of the whole MI450 GPU hierarchy.

Kernel programmer view of the MI450 GPU hierarchy.

To write the MI450 kernel more efficiently, we will use Gluon in this blog. Gluon is a Triton-based DSL that keeps the tile-based SPMD programming model. Unlike Triton, tensors in Gluon must carry an explicit layout, which describes how each element is distributed across registers, lanes, waves, and workgroups. The layout also affects how the compiler generates instructions to move data among different memory hierarchies. This makes Gluon a lower-level programming language than Triton, and especially useful for kernel experts who want explicit control over generated instructions.

We assume the reader is familiar with the basics of Gluon semantics and its programming model. For Gluon kernel examples, please refer to the MI450 Gluon Examples.

Attention Decode Basics

With this hardware context in place, we can now turn to the workload: attention decode. We will start with a baseline attention decode kernel, then use it as the reference point for the optimizations in later sections. The attention operation can be expressed as follows: first, we perform a matrix multiplication of Q and K, then apply softmax to get P, and multiply P with V to get the final output O.

Attention formula.

In this blog, we use general 4D tensors to represent the attention inputs and outputs. For notation throughout this blog, B is the batch size, H_q is the number of Q heads, H_kv is the number of KV heads, T_q is the number of Q tokens, T_kv is the number of KV tokens, and D is the head dimension. The input QKV tensors are shown below.

Q: [B, H_q, T_q, D]
K: [B, H_kv, T_kv, D]
V: [B, H_kv, T_kv, D]

When H_q is equal to H_kv, we have standard multi-head attention (MHA), and when H_q is a multiple of H_kv, we have multi-query attention (MQA) or grouped-query attention (GQA). Modern LLMs often use MQA, such as GPT-OSS, so we will focus on MQA in this blog.

Attention in LLM inference includes two phases: prefill and decode. For prefill, T_q = T_kv, and the kernel can process many tokens in parallel. For decode, T_q = 1, but T_kv remains large and grows with the context length. Given each head is independent, standard MHA can waste a lot of compute resources for single-token decode.

However, in MQA decode, because multiple Q heads share one K and V head, the kernel can group those Q heads together. This can be reflected in the tensor shapes, as shown below, where the Q tensor is reshaped to group H_q / H_kv Q heads together for each KV head.

Q: [B, H_kv, H_q / H_kv, D]
K: [B, H_kv, T_kv, D]
V: [B, H_kv, T_kv, D]

Because tensors in each batch and each KV head are independent, we can process them in parallel. The kernel can be launched with a grid of (B, H_kv, 1), and each program processes a portion of the attention computation:

Q: [H_q / H_kv, D]
K: [T_kv, D]
V: [T_kv, D]

Following the Flash Attention algorithm, the kernel can compute one tile of K and V with shape (BLOCK_N, D) and one Q tile with shape (BLOCK_M, D) at a time, then slides through the T_kv dimension. The figure below shows an example workload with 2 batches and 2 KV heads. Each workgroup owns one (B, H_kv) pair, so there are 4 workgroups in total. Within each workgroup, multiple Q heads are processed together and shown as multiple rows. Here, we assume BLOCK_M = H_q / H_kv.

Attention decode workload mapping across batches and KV heads.

Decode Kernel Optimizations

So far, we have introduced a baseline implementation of an MQA decode kernel on MI450. This section will further discuss a series of optimizations that push the kernel toward peak performance on MI450. We will cover 4 major optimizations: tensor layout, data loading, pipelining, and parallelization with Split-k.

Optimize Tensor Layout

Gluon gives kernel authors explicit control over tensor layouts, which matters a lot for performance. A kernel can contain many different tensors, and deciding the right layout for each of them is non-trivial. In practice, the most important layout to decide first is the layout for the WMMA operands. In an attention kernel, there are two WMMA operations: QK and PV. We can start our layout optimization there.

In Gluon, AMDWMMALayout describes the WMMA output layout, and DotOperandLayout describes the WMMA operand layout. A given AMDWMMALayout determines the final WMMA instruction the compiler generates. For example, an AMDWMMALayout with instruction shape [16, 16, 128] for wmma_scaled generates v_wmma_scale_f32_16x16x128_f8f6f4 under the hood. This instruction consumes one FP8 operand of shape (16, 128), another FP8 operand of shape (128, 16), reduces over the K dimension of size 128, and produces a FP32 output tile of shape (16, 16) in one wave, where each element is assigned to a specific lane and register in this wave. The following figure shows how elements in the 2 WMMA operands and output tensor are assigned to lanes.

Lane assignment for the WMMA operands and output tile.

Next, we need to consider how waves are distributed. The kernel can use any power-of-two number of waves and distribute them across 2 dimensions of the WMMA output tile. Since online softmax reduces along T_kv dimension, we prefer to distribute waves along grouped Q dimension to avoid cross-wave communication during the reduction. In MQA decode, the Q tile has shape (H_q / H_kv, D), and H_q / H_kv is usually small, so we also need to avoid using too many waves there. For example, if H_q / H_kv = 32, the kernel chooses 2 waves, as shown below. In this figure, 2 waves have their own first WMMA operand, and share the second operand.

Two-wave WMMA layout with waves distributed across rows.

Another important factor to keep in mind is layout conversion. When two tensors in Gluon use different layouts, the kernel must use an explicit layout conversion operation to match them. Depending on the source and destination layouts, this conversion can happen in registers or through LDS. In attention, the output of the QK WMMA becomes the input of the PV WMMA after softmax. If the QK output layout is not compatible with the PV input layout, the hot loop pays an extra conversion cost. One useful technique is to “transpose” the WMMA output layout. This can be done by simply setting transpose=True in AMDWMMALayout, and the compiler will generate corresponding instruction to produce the transposed output. Note that this transpose operation does not incur extra instructions. For more details, please refer to this talk.

Transposed WMMA output layout used to make the QK output compatible with the PV input layout.

Transposed WMMA output layout for matching the PV input layout.

Another detail worth mentioning is the concept of “K Width”. In DotOperandLayout, K Width describes how many contiguous elements along the K dimension for WMMA should be assigned to one lane. A standard 16x16x128 WMMA instruction assumes K Width 16, but the transposed output for QK can have K Width 8. Therefore, we also need to explicitly set the PV input layout with K Width of 8 to match the QK output.

Optimize Data Loading

The hot loop of the decode kernel is dominated by loading K and V tiles from global memory to LDS. TDM helps accelerate this data path, but using TDM naively is not enough.

To understand the performance impact of TDM, we first need to understand the cache hierarchy on MI450. MI450 has a per-WGP cache at the same level as the LDS. But different from LDS, this cache is not directly visible to the programmer. TDM can either move data directly into the programmer-managed LDS or route the data through the cache path before it reaches the destination. Considering the limited size of the cache, memory-bound workloads are better off bypassing the cache and moving data directly into LDS.

TDM load paths comparing indirect loads through the cache path with direct loads into LDS.

Indirect and direct TDM load paths on MI450.

Whether a TDM transfer uses the direct path depends on the shape of the TDM request. The innermost dimension needs to be at least 128 bytes to use the direct path, and 256 bytes is recommended to keep more in-flight memory traffic. Recall that K and V tiles have shape (BLOCK_N, D), so the innermost dimension is the head dimension D. Assuming an FP8 data type, this means the head dimension needs to be 256 for the optimal performance. In practice, head dimension is determined by the model architecture and cannot be changed by the kernel. However the kernel can reshape the K and V tensors to increase the innermost dimension before loading, then reshape them back while loading from LDS to registers. The following figure shows an example data flow of K and V for head dimension of 128.

K and V reshape data flow showing a wider innermost dimension in global memory and LDS before restoring the register view.

KV reshape used to create a wider TDM innermost dimension.

Pipeline for Latency Hiding

So far, we have optimized the tensor layout and data path. However, the hot loop can still stall on memory access latency. The next step is to pipeline the loop so that memory movement for one tile overlaps with computation for another tile.

To understand the pipeline, we can zoom into the attention formula shown earlier and write it in the tiled form used by the Flash Attention algorithm. The formula below shows one iteration i of the loop that processes one KV tile. Here we only focus on operations on 2D tiles, and omit operations on reduced 1D intermediate values. We use short operation names on the right side to denote each operation, making the pipeline easier to discuss later.

One iteration of the tiled attention loop

This figure shows one iteration i of the tiled attention loop, including only 2D operations. O, m, and l are loop-carried intermediate values for online softmax. The right side shows the short operation names used in the pipeline discussion.

Each line in the figure can be expressed as one Gluon operation, which will be expanded to a sequence of instructions. The following table shows the expanded instruction groups for FP8 decode attention with BLOCK_M = 32, BLOCK_N = 128, D = 128, and two waves. The Cycles column gives a simplified per-instruction cost estimate based on hardware specifications. Memory instructions are left blank because their latency is modeled separately.

Operation	Instruction	Count	Cycles
TDM K	tensor_load_to_lds	1
LDS K	ds_load_b128	32
QK	v_wmma_scale_f32_16x16x128_f8f6f4	8	8
MAX	v_maximum3_f32	32	1
FMA	v_pk_fma_f32	32	1
EXP	v_exp_f32	64	2
SUM	v_pk_add_f32	32	1
MUL	v_pk_mul_f32	32	1
CVT	v_cvt_scalef32_pk8_fp8_f32	8	4
TDM V	tensor_load_to_lds	1
LDS V	ds_load_tr8_b64	64
PV	v_wmma_scale_f32_16x16x128_f8f6f4	8	8

This table gives us the basic scheduling units. The goal of pipelining is to move independent units from different loop iterations into the same time window.

Our first attempt is to separate memory movement from computation. In the simple two-stage pipeline below, one stage issues TDM loads for future iterations, while the other stage consumes data that has already arrived in LDS. The notation [i] means the operation belongs to loop iteration i. This schedule needs double buffering. While one LDS buffer is being consumed by LDS loads and WMMA, the other buffer can be filled by TDM for a later iteration. On the next loop step, the two buffers swap roles.

Two-stage pipeline showing TDM loads for future iterations overlapped with LDS loads and compute for current iterations.

Two-stage pipeline schedule.

The two-stage pipeline can overlap TDM loads with computation. This works well when the loop is clearly memory-bound, but it treats the entire compute side as one monolithic block. As a result, LDS loads, WMMA for QK, WMMA for PV, a series of vector instructions for softmax are effectively serialized inside the compute stage. This unnecessarily inflates the compute block. In the worst case, the kernel can shift from being limited by TDM latency to being limited by serialized compute.

To avoid this, we split the compute block according to the actual data dependencies. These operations do not all depend on the same values or use the same hardware resources, so WMMA instructions, LDS movement, and softmax vector work can often be interleaved once their operands are ready. In the dependency graph below, each node is one scheduling unit. An edge means the destination cannot start until the source has produced its value.

Data dependency graph for TDM K, LDS K, QK, softmax work, TDM V, LDS V, and PV.

Data dependencies among the scheduling units in one loop iteration.

We can observe that the QK for iteration i + 1 does not need the softmax result from iteration i, so the next KV tile can be prefetched and its QK computation can start earlier. Moreover, QK and PV use WMMA instructions, while the online softmax only uses VALU instructions, so these operations can be interleaved instead of serialized.

These observations motivate the four-stage pipeline. Instead of putting all non-TDM work into one compute stage, the four-stage pipeline interleaves memory and compute units from neighboring iterations. A stage may contain QK from iteration i + 1, softmax work from iteration i, an LDS load for iteration i, and a TDM request for a future iteration. We group the softmax work into two stages with roughly equal amount of work, to help hardware better interleave WMMA and VALU. Here, QK WMMA can interleave with VEC0 and PV WMMA can interleave with VEC1. In addition, EXP uses the transcendental unit and can be further interleaved with other VALU instructions.

Four-stage pipeline interleaving TDM, LDS, QK, softmax vector work, and PV across neighboring iterations.

Four-stage pipeline schedule with double buffering.

This four-stage schedule exposes more overlap than the two-stage schedule, but it still leaves one question: how far ahead should the TDM requests be issued? With double buffering, the kernel has 2 LDS slots. One slot is being consumed by LDS loads and compute, while the other slot is being filled by TDM. This gives each TDM request roughly one iteration of compute time before the data is needed.

We can estimate whether that is enough with a simple cycle model. Assume TDM load takes about 1000 cycles and all LDS load latency can be hidden by scheduling. Using this model and the previous table, we can get the following estimate for one decode iteration shown in the table below. Here we use 2 interleave rules: 1) one WMMA takes 8 cycles, and can hide 2 cycles of VALU; 2) one EXP takes 2 cycles, and can hide 1 cycle of non-EXP VALU. Also note this 1000 cycles is an empirical number to help us reason about the pipeline. The actual TDM latency depends on many factors, like the tensor tile shape and access pattern.

Group	Total Cycles
QK	64
PV	64
VEC0 = MAX + FMA + EXP	192
VEC1 = SUM + MUL + CVT	96
QK + VEC0, interleaved	176
PV + VEC1, interleaved	144
Total, interleaved	320

In a double-buffered schedule, a TDM request has roughly 320 cycles of effective compute work to overlap with before the loaded tile is consumed. This is much smaller than the 1000-cycle TDM latency in this model, leaving about 680 cycles of exposed wait for each load.

This motivates a longer lookahead distance. Triple buffering adds one more LDS slot, so the kernel can request a future tile earlier instead of waiting for the next buffer swap. Conceptually, one buffer is being consumed, one buffer is ready or close to ready, and one buffer is being filled by TDM. In the same model, looking ahead by two iterations gives about 640 cycles of effective compute work to overlap. It still does not cover the full memory latency, but it reduces the exposed wait from about 680 cycles to about 360 cycles and gives the hardware more outstanding memory work.

Four-stage triple-buffered pipeline with TDM requests issued farther ahead of consumption.

Four-stage pipeline with triple buffering.

Parallelize with Split-k

The pipeline optimizes latency hiding inside one workgroup, but one GPU has many workgroups, and we also need to make sure we can saturate the full GPU memory bandwidth across all workgroups. In the baseline MQA/GQA decode mapping, each workgroup owns one (B, H_kv) pair and walks through that pair’s KV sequence serially. The total number of workgroups is only B * H_kv. On MI450, there are 256 workgroup processors, so small batch sizes or small numbers of KV heads may launch too few workgroups to fully utilize the available memory bandwidth.

Split-k addresses this under-utilization problem by partitioning the KV sequence across multiple workgroups. Instead of assigning the whole KV sequence for one (B, H_kv) pair to a single workgroup, Split-k divides it into S partitions and lets S workgroups process those partitions in parallel. The number of workgroups increases from B * H_kv to B * H_kv * S, improving GPU saturation while also reducing the number of KV blocks handled by each workgroup. The partial results from the partitions are then merged to produce the final attention output. The following figure shows an example with 2 batches, 2 KV heads, and 2 partitions: the total number of workgroups doubles, and each workgroup processes half of the KV sequence.

Split-k workload mapping where the K/V sequence is divided into partitions processed by additional workgroups.

Split-k workload mapping across K/V sequence partitions.

One challenge with Split-k is that all workgroups also need to synchronize and merge their partial results. Typically, there is a separate reduction kernel to merge the partial results. This two-kernel approach uses global memory to store the intermediate results and also sets a natural synchronization point. MI450 introduces the new workgroup cluster feature, which allows a cluster of workgroups to synchronize. We can use this feature to implement Split-k in a single kernel by fusing the reduction compute.

In Gluon, the concept of a workgroup cluster is expressed via multi-CTA programming. “CTA” is the Triton term for a workgroup, and “CGA” is the term for a cluster. The following table shows the mapping between Triton and MI450 concepts:

Triton Concept	MI450 Concept
Warp	Wavefront
CTA	Workgroup
CGA	Workgroup Cluster

Gluon kernels distribute CTAs just like warps; both are part of the layout system. One detail to note is that when discussing block size in Triton, it usually means the block size of one workgroup. With a multi-CTA layout, the block size is the size of the whole cluster.

Layouts in Gluon, such as AMDWMMALayout, allow specifying the cga_layout field for the multi-CTA kernel. In the Split-k case, since each workgroup processes a partition independently until the final reduction, we can perform the partial attention in 3D format. Effectively, each program processes the attention computation shown below. All partitions here share the same Q.

Q: [1, H_q / H_kv, D]
K: [S, T_kv / S, D]
V: [S, T_kv / S, D]

To see how this maps to the layout system, it is useful to look at a single WMMA operation under a multi-CTA layout. In the figure below, we add one extra dimension to the WMMA layout for workgroups. The first operand is shared across 2 partitions. The second operand and output are different. Within each workgroup, the two waves are still distributed as before.

Multi-CTA WMMA layout showing workgroup and wave dimensions for split-k attention.

Multi-CTA WMMA layout for split-k attention.

After the partial attention, we need to merge the results from all workgroups. The kernel will first write the partial results to global memory, synchronize all workgroups in the cluster, and finally read back the partial results. It is also worth mentioning that MI450 provides the L2 cache which is shared across workgroups in a cluster. So the partial results do not need to be passed through global memory. This helps to cut the overhead of the reduction.

As the reduction is fused into the same kernel, we will use the same launch grid for the reduction, but with a different layout. Workgroups are now distributed along the head dimension and loop through each partition to compute the final result.

CTA layout for attention and reduction showing how workgroups are redistributed for the split-k merge step.

CTA layouts for split-k attention and reduction.

Performance Evaluation

So far, we have covered the main optimization steps for MQA decode on MI450, including:

1. Optimize tensor layout: Choose optimal Gluon layouts to help the compiler generate better instructions;
2. Optimize data loading: Optimize K/V TDM requests to speed up memory access;
3. Pipeline for latency hiding: Overlap memory access, matrix multiplication, and softmax to reduce exposed memory latency;
4. Parallelize with Split-k: Split the KV sequence across multiple workgroups to fully utilize the GPU memory bandwidth.

Apart from all the optimizations discussed above, the kernel also uses a few other techniques to improve performance, including better code generation and underlying instruction-level optimizations in LLVM.

We implemented the above optimizations in a Gluon kernel. The kernel source code is fully open source in the MI450 Gluon MXFP Attention Example. Our evaluation of this kernel covers the following target settings:

• Batch: 64
• Number of Q heads: 64
• Number of KV heads: 1 or 2
• KV sequence length: 4096-65536
• QKV data type: FP8 with a global scale

We use the effective bandwidth of the kernel as the target metric, defined as the total number of bytes read and written to global memory divided by the total kernel execution time. For a system-level memory-bandwidth reference, we also measured the peak read-only bandwidth on the same MI450 system using the BabelStream. The following figure shows the performance of the kernel for the target settings:

Effective bandwidth results for attention decode on MI450 across K/V sequence lengths and K/V head counts.

Effective bandwidth of the optimized attention decode kernel on MI450.

The reported peak bandwidth on our evaluation system is 20TB/s. In the GQA case with H_kv = 2, effective bandwidth reaches 17.10 TB/s, 85% of the peak bandwidth. In the MQA case with H_kv = 1, the kernel reaches 16.65 TB/s, 83% of the peak bandwidth. The throughput of the kernel increases with sequence length. At shorter sequence lengths, fixed costs such as prologue and reduction overhead take a larger fraction of the total runtime.

The above results were collected with ROCm 7.14.0 and PyTorch 2.11.0, using Triton commit ecfc626 with the latest mxfp_fa_gfx1250.py script. To reproduce the results, please run the following command:

# H_kv = 2
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 4096 --num_q_heads 64 --num_k_heads 2 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 8192 --num_q_heads 64 --num_k_heads 2 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 16384 --num_q_heads 64 --num_k_heads 2 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 32768 --num_q_heads 64 --num_k_heads 2 --head_sz 128 --pipelined --scale_type global --profile

# H_kv = 1
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 8192 --num_q_heads 64 --num_k_heads 1 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 16384 --num_q_heads 64 --num_k_heads 1 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 32768 --num_q_heads 64 --num_k_heads 1 --head_sz 128 --pipelined --scale_type global --profile
python3 third_party/amd/python/examples/gluon/mxfp_fa_gfx1250.py --q_type e4m3 --kv_type e4m3 --batch 64 --seqlen_q 1 --seqlen_k 65536 --num_q_heads 64 --num_k_heads 1 --head_sz 128 --pipelined --scale_type global --profile

Summary

In this blog, we used attention decode as a case study to walk through the main optimization steps for MI450. We started from a baseline attention loop, then optimized the WMMA layouts, data loading, and software pipelining. We also discussed how to use split-k with workgroup clusters to increase parallelism for long-context decode. The optimized attention decode kernel can reach 85% of the peak memory bandwidth on MI450. This is an early result, and we expect to further improve the kernel performance with more optimizations in the future, such as memory prefetching, better instruction-level scheduling and improved reduction for split-k.

We also demonstrated that MI450 provides several hardware features that are especially useful for decode workloads: TDM for asynchronous global-to-LDS movement, larger register and LDS resources, and workgroup clusters for cooperation across workgroups. Gluon exposes all of these features and allows kernel authors to perform low-level optimizations while maintaining a tile-based SPMD programming model consistent with Triton. This opens up many optimization opportunities for kernel experts to achieve peak performance on MI450.

Moving forward, we plan to continue to apply these optimization techniques to other attention decode kernels, covering different data types, paged KV cache, and also different attention variants like MLA/DSA kernels in the DeepSeek family. These kernels will be further pushed to production-ready quality and integrated into LLM inference frameworks.

We now have a new way for you to help us write the monthly updates :)

Servo 0.4.0 contains all of the changes we landed in June, which came out to yet another record 558 commits (April: 534, May: 391). For security fixes, see § Security.

We’ve shipped several new web platform features:

• ‘attr()’, in experimental mode (@Loirooriol, #45041)
• ‘image(<color>)’, ‘closest-corner’, and ‘farthest-corner’ in ‘ellipse()’ and ‘circle()’ (@Loirooriol, #45421)
• ‘calc()’ and other mathematical expressions can now be resolved later than parse time, e.g. sign(1em - 32px) (@Loirooriol, #45421)
• ‘font-feature-settings’ in ‘@font-face’ (@simonwuelker, #45393)
• ‘@media (device-width)’, ‘@media (device-height)’, ‘@media (height)’, ‘@media (aspect-ratio)’, and their min- and max- variants (@jdm, @mrobinson, @nicoburns, @jschwe, #44978, #45707, #45490)
• ‘@media (orientation)’ (@nicoburns, #45707)
• ‘@media (pointer)’ and ‘@media (any-pointer)’ (@nicoburns, #45681)
• ‘@media (hover)’ and ‘@media (any-hover)’ (@nicoburns, #45681)

Plus a bunch of new DOM APIs:

• Shared­Worker (@Taym95, #45786)
• console­.dir() (@Taym95, #45109)
• custom­Element­Registry on Document and Shadow­Root (@shubhamg13, #45872)
• initialize() on Custom­Element­Registry (@shubhamg13, @yezhizhen, #45903)
• new Custom­Element­Registry() (@shubhamg13, #45791, #45550)
• text­Stream() on Request, Response, and Blob (@yezhizhen, #45864, #45861)
• set­Pointer­Capture(), release­Pointer­Capture(), has­Pointer­Capture() on Element (@webbeef, #45048)
• on­touch­start, on­touch­end, on­touch­move, on­touch­cancel on Element (@stevennovaryo, #45049)
• crypto­.subtle­.digest() for KT128 and KT256 (@kkoyung, #45699)
• crypto­.subtle­.get­Public­Key() for ML-KEM and ML-DSA (@kkoyung, #45252)

You can help!

Servo is steadily becoming a bigger and busier project every month, and by June 2026, we’ve been reading through over four times the commits as we did when we started in September 2023.

This is hard work, particularly since there are things we need to know that are often difficult to answer just by reading the changes:

• Who does the change affect, if anyone? Does it affect users, Servo developers, embedders, or some other group?
• What observable difference does the change make, if any?
• Does the feature require any preferences to be enabled, or is it enabled for everyone by default?
• Are any real-world websites affected by the change?
• What issue or broader project is the change related to? This question is answered by Fixes: #xxxxx or Part of: #xxxxx in the PR description.

Thanks to an initiative by @jdm, it’s now easier than ever for you to help us answer those questions, using the Servo Highfive bot! If you’re working on a pull request that you think might be interesting for the next monthly update, even if you’re not 100% sure, tell us about it by following the steps below:

1. You add the monthly update label to your pull request, or comment @servo-highfive monthly update
2. Highfive posts a comment asking you some questions
3. You answer those questions in a comment containing @servo-highfive monthly update answer

Security

Servo’s JS runtime, SpiderMonkey 140.10.1, had several security bugs that have been fixed in Servo 0.4.0 with the update to SpiderMonkey 140.11.0 (@jschwe, #45584). For more details, see CVE-2026-8388, CVE-2026-8391, CVE-2026-8974, CVE-2026-8975, and MFSA 2026-48.

Several more security bugs in Servo’s JS runtime have been fixed in Servo 0.4.0 with the update to SpiderMonkey 140.12.0 (@jschwe, #45766). The exact CVEs that apply to us are not yet known, but for more details, see MFSA 2026-58.

RSA operations in Subtle­Crypto now do modular exponentiation in constant time (@kkoyung, #45631). Please note that our RSA implementation is currently vulnerable to the Marvin Attack – for more details, see RUSTSEC-2023-0071.

ML-DSA operations in Subtle­Crypto now do the Decompose step in constant time, fixing RUSTSEC-2025-0144 (@kkoyung, #45294).

We’ve fixed an HTML injection bug (XSS) in file:/// directory listings, which affected file names containing </script> (@sahvx655-wq, #45510).

Real world compat

Layout correctness has significantly improved on lichess.org, and many websites have become a lot more readable thanks to our improved handling of variable fonts (@simonwuelker, #45768), including Zulip (servo.zulipchat.com) and Speedtest (speedtest.net).

v0.3.0

v0.4.0

lichess.org

v0.3.0

v0.4.0

Zulip (servo.zulipchat.com)

v0.3.0

v0.4.0

Speedtest (speedtest.net)

Many websites worked in Servo even before version 0.4.0, including Google Photos (photos.google.com) and Cash Converters (cashconverters.com.au), and continue to work in version 0.4.0. Other websites, like Google Maps (maps.google.com) and OpenStreetMap (www.openstreetmap.org), render well but have some issues with interactivity.

Google Photos (photos.google.com)

Cash Converters (cashconverters.com.au)

Google Maps (maps.google.com)

OpenStreetMap (www.openstreetmap.org)

We’re interested to hear how well your favourite websites run in Servo! Report successes in this Zulip thread, and failures in our GitHub issues.

Work in progress

We’re implementing the more powerful version of ‘attr()’ that can be used anywhere, not just in ‘content’, under --pref layout­_css­_attr­_enabled (@Loirooriol, #45041, #45421, #45495, #45752).

WebGPU support has improved, under --pref dom­_webgpu­_enabled:

• implemented copy­External­Image­To­Texture() on GPU­Queue (@sagudev, #45646)
• implemented create­Query­Set() on GPU­Device and resolve­Query­Set() on GPU­Command­Encoder (@sagudev, #45644)
• implemented push­Debug­Group(), pop­Debug­Group(), and insert­Debug­Marker() on GPU­Command­Encoder, GPU­Compute­Pass­Encoder, and GPU­Render­Pass­Encoder (@jschwe, #45489)
• more conformant GPU­Texture (@sagudev, #45300)
• more conformant request­Adapter() on GPU (@sagudev, #45424)
• more conformant secure context enforcement (@sagudev, #45279)

All of the features above are enabled in servoshell’s experimental mode.

We’ve made more progress towards accessibility support, under --pref accessibility_enabled (@alice, @delan, #45555, #45554, #44949).

We’ve started implementing visible and interactive text selection (@mrobinson, @SimonSapin, #46107), one of the most long-awaited features of any web browser. Stay tuned!

We’ve also started working on Web Animations, under --pref dom­_web­_animations­_enabled (@simonwuelker, #45522, #45983), as well as webkit­Relative­Path on File, under --pref dom­_entries­_api­_enabled (@yezhizhen, #45666).

Rust doesn’t have a stable ABI, so it has generally not been possible to embed Servo in another application without building Servo from source. To make it possible, we’ve started designing a wrapper C API that will let you consume Servo as a prebuilt shared library using the stable and ubiquitous C ABI (@mukilan, #44984). Eventually the idea is that we’ll create a wrapper Rust API around that wrapper C API, so you can have both the ergonomics of Rust and the build simplicity of C.

Embedding API

New in the Servo API:

• Web­View::rendering­_context (@mrobinson, #46047)

Breaking changes:

• Web­View::send­_error has been removed (@mukilan, #45502) – this method was always meant to be internal, and has become unused after we introduced the new Web­View- and Web­View­Delegate-based API

We’ve improved the docs for Web­View, Web­View­Delegate, JS­Value, Alert­Dialog, Allow­Or­Deny­Request, Authentication­Response, Bluetooth­Device­Description, Confirm­Dialog, Console­Log­Level, Create­New­Web­View­Request, Embedder­Control, Embedder­Control­Response, File­Picker, Image, Java­Script­Error­Info, Navigation­Request, Permission­Request, Pixel­Format, Prompt­Dialog, Protocol­Handler­Registration, Protocol­Handler­Update­Registration, Scroll, Select­Element, Select­Element­Request, and Web­View­Vector (@mukilan, #45282, #45467).

For users and developers

In servoshell:

• the Android version now requires Android 13+ (@jschwe, #46104)
• the desktop version now lets you drag and drop files to open them (@simonwuelker, #45454)
• the desktop version now lets the tab bar scroll horizontally if you have too many tabs open, but from one tab hoarder to another, maybe you should reconsider having so many tabs open (@Nylme, #44884)
• the desktop version enters fullscreen on the monitor containing the window, even if you’ve moved it to a different monitor (@rhit-kapilaar, #45556)
• the desktop UI is more performant, resizes more smoothly, and no longer gets stuck in hovered states (@mrobinson, #45289, #45456, #45290)
• <select multiple> should now be interactable on all desktop platforms (@alexcat3, #45419)
• localhost:<port> now implies http:// in the location bar and on the command line, rather than treating localhost: as an unsupported URL scheme (@SteveSharonSam, #45729, #45832)

When using the Firefox DevTools:

• in the Console tab, uncaught exceptions are reported correctly (@jdm, #45549)
• in the Console and Debugger tabs, you can now inspect the elements of nested arrays and the entries of Map objects (@atbrakhi, #45435, #45514, #45767)
• in the Debugger tab, the Scopes panel now shows any ‘(uninitialized)’ variables, the value of this, and the global scope (@atbrakhi, @eerii, #45824, #45517)

We’ve fixed some build issues on riscv32, riscv64, and arm64 (@fxzjshm, @saschanaz, #45285, #45731), and modernised servoshell for Android to use Compose UI and Kotlin (@veyndan, #45923, #45932, #45941, #45982, #45985, #46015, #46035, #46037, #46046, #46053, #46061, #46071, #45641, #45643, #45650, #45665, #45671, #45676, #45679, #45683, #45712, #45713, #45734, #45738).

For developers of Servo itself:

• mach try --help now lists all of the kinds of try jobs you can run (@shubhamg13, #45607)
• mach test-wpt --update-expectations lets you run Web Platform Tests and update expectations in a single command (@TimvdLippe, #45521), rather than having to run mach test-wpt --log-raw <path> followed by mach update-wpt <path>

More on the web platform

To allow for more performant scrolling, ‘wheel’ events are no longer .cancelable unless there are one or more non-passive event listeners (@kunalmohan, #45667). Note that like in Firefox, ‘wheel’ events are passive by default.

‘dotted’, ‘dashed’, and ‘wavy’ text decorations are now continuous across element boundaries (@mrobinson, #45726).

We’ve improved the conformance of <dialog> (@skyz1, @mrobinson, #45825, #45761), <iframe sandbox> (@cychronex-labs, #45880), <input minlength> and <input maxlength> (@skyz1, #45705), CSS gradients (@mrobinson, #43945), ‘font-style’ and ‘unicode-range’ in ‘@font-face’ (@Loirooriol, #45821), FontFaceSet (@mrobinson, #45390, #45382), HTML­Input­Element (@steigeo, #45416), Intersection­Observer (@jdm, #45655, #45659, #45680), new Response() (@yezhizhen, #45953), URL.create­Object­URL() and URL.revoke­Object­URL() (@yezhizhen, #45182, #45417), and ECDSA and Ed25519 in Subtle­Crypto (@kkoyung, #45833, #46017).

We’ve fixed bugs related to <input hidden> (@mrobinson, #45750), ‘animation-delay’ (@yezhizhen, #45013), ‘clip-path’ (@Loirooriol, #45468, #45373), ‘tab-size’ (@SimonSapin, @mrobinson, #45309), ‘width’ and ‘height’ (@RichardTjokroutomo, #44627), ‘box-shadow: inset’ (@Loirooriol, #45620), ‘animation­iteration’ events (@Loirooriol, #45990), ‘click’ events (@mrobinson, #45751), ‘load’ events (@jdm, #45883), ‘error’ events in Worker global scopes (@Gae24, #45829), and document­.get­Element­By­Id() (@mrobinson, #45433).

Garbage collection safety

We use a RefCell-based mechanism to store many of our DOM types in other DOM types, enforcing Rust’s “aliasing xor mutability” rule at runtime by panicking if the rule is violated. But when garbage collection happens, we need to borrow() each DomRefCell to trace the references, and this is the source of many panic bugs. To fix that whole class of bugs, we initially created CanGc, a marker type that would annotate the code paths where GC can occur, in conjunction with custom static analysis (@jdm, #33140).

With the Rust type system we can do even better, if we flip that around and require any borrow_mut() call to prove that GC can not occur by passing a NoGC marker value. We can then require that a &NoGC must be borrowed from a &JSContext (which blocks GC) and not a &mut JSContext (which allows GC), taking advantage of how Rust references work without needing any custom static analysis.

We have a large codebase that needs to be migrated in parts, so for now we’ve created the new method safe­_borrow­_mut() (@sagudev, #46050). We also need to update all of our script-related code to borrow our safe JSContext wrapper, rather than creating an owned JSContext on the spot.

This continues our long-running effort to use the Rust type system to make Servo’s integration with SpiderMonkey safer and more reliable (@Gae24, @Keerti707, @Narfinger, @TimvdLippe, @sagudev, @guptapiyush16, @ivomurrell, @kunalmohan, @skyz1, #45230, #45436, #45503, #45617, #45711, #45797, #45800, #45858, #45884, #45937, #45902, #45968, #45977, #45991, #46003, #46005, #46084, #45548, #45552, #45590, #45909, #45912, #45943, #46089, #46117, #46114, #45320, #45324, #45328, #45340, #45381, #45385, #45410, #45392, #45409, #45604, #45616, #45618, #45627, #45636, #45662, #45663, #45675, #45674, #45677, #45684, #45735, #45807, #45810, #45816, #45818, #45828, #45838, #45836, #45837, #45840, #45841, #45857, #45859, #45862, #45875, #45887, #45931, #45964, #45935, #45987, #45988, #46001, #46040, #46051, #46057, #46106, #46125, #45678, #46002, #45845, #45645, #45673, #45259, #45817, #45822, #45876, #45877, #45891).

Performance and stability

NoGC was designed to prevent dynamic borrow failures, but it also enables some performance optimisations! If we can prove that garbage collection is impossible in some part of Servo, we can often avoid rooting JavaScript objects when interacting with them within that region of code. This has allowed us to reduce overheads by over 1% in the layout process and in HTML­Collection (@Narfinger, #46092, #45582).

Our memory usage has improved, with BoxFragment now 17% smaller (288 → 240 bytes on amd64) and ShapeCacheEntry now smaller too (@SimonSapin, @mrobinson, @simonwuelker, #45183, #45496).

We’ve fixed some nasty memory leaks when reloading and in 2D canvases (@Taym95, @sagudev, @jschwe, #45455, #45261, #45414).

Speaking of which, 2D canvases now use up to 23% less power (@yezhizhen, #45301), and we now avoid rasterising the same SVG more than once (@Narfinger, @jschwe, #44805).

Servo now decodes all images asynchronously and fills image caches asynchronously, leaving script threads (web content processes) more time for other work (@Narfinger, #45542, #44483). On top of that, we’ve improved incremental layout (@mrobinson, @Loirooriol, #45411) and reduced reflows in IntersectionObserver (@jschwe, #45986).

We’ve started working on incremental updates for the stacking context tree, and as a side effect, we’ve made some layout-bound microbenchmarks up to 10% faster (@mrobinson, @Loirooriol, #45208).

We’ve also reduced allocations, copies, GC rooting steps, and other operations in many parts of Servo (@Narfinger, @SimonSapin, @mrobinson, @Loirooriol, #45506, #45969, #45940, #45760, #46090, #45335, #45413, #45511).

For several months, Frédéric (@fred-wang) has been fuzzing for Servo bugs, and thanks to his work we’ve fixed sixteen (16) crash bugs in June, affecting <iframe>, <slot>, <link onerror>, ‘animation’, ‘clip-path’, ‘content’, ‘rotate’, ‘transition’, ‘transform-style’, ‘display: contents’, ‘overflow: clip’, CSS­Keyframes­Rule, Font­Face, stop() on Window, document­.element­From­Point(), and the DOM tree (@mrobinson, @Loirooriol, @fred-wang, #46031, #46027, #46054, #46058, #46016, #46028, #46033, #45287, #45951, #45634, #45629, #46110, #46094, #45799, #45611, #45682, #45788, #45612, #45834).

We’ve also fixed crash bugs related to IPC failures, HTML­Input­Element, Range, the DevTools Debugger tab, and when servoshell is built with --features native-bluetooth (@jschwe, @Taym95, @mrobinson, @atbrakhi, @mukilan, #45311, #45619, #45765, #45513, #45702).

New contributors

A special thanks to the following people for landing their first patch in Servo:

• Deepam Goyal (@Deepam02, #44836)
• Mark (@Mark-Boger, #45486)
• Mr SheerLuck (@MrSheerluck, #45557)
• Psychpsyo (Cameron) (@Psychpsyo, #45494)
• TusharSariya (@TusharSariya, #43663)
• Adam Sharif (@adamsharifc, #45551)
• Akash Ravikumar (@ak4shravikumar, #45736)
• Sean Cunneen (@alexcat3, #45419)
• Abdul Wahab Melethil Shibu (@cychronex-labs, #45880)
• darkdragon-001 (@darkdragon-001, #45267)
• Frédéric Wang Nélar (@fred-wang, #45834)
• fxzjshm (@fxzjshm, #45285)
• Piyush Gupta (@guptapiyush16, #45845)
• Ivo Murrell (@ivomurrell, #45645)
• rhit-kapilaar (@rhit-kapilaar, #45556)
• sahvx655-wq (@sahvx655-wq, #45510)
• Kagami Sascha Rosylight (@saschanaz, #45731)
• shangguanmachine-dot (@shangguanmachine-dot, #45310)
• Glenn Skrzypczak (@skyz1, #45471)
• Oskar Steiger (@steigeo, #45416)
• Veyndan Stuart (@veyndan, #45326)

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Donations

Thanks again for your generous support! We are now receiving 7681 USD/month (+0.2% from May) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.

Servo is also on thanks.dev, and already 35 GitHub users (same as May) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at [email protected].

Use of donations is decided transparently via the Technical Steering Committee’s public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

But can your calculator run Linux?

One of my all time favorite calculators is the HP 16C. It is an RPN calculator aimed at computer programmers with support for hex, binary, octal and decimal and all sorts of useful operations like bit shifting, masking and rotations. I don't own one myself, I have a Swiss Micro's DM16L, a high quality modern day remake with improvements like a 2 line display. There is a limited run collectors edition of the HP 16C coming soon though. But none of those calculators run Linux.

This one can:

xcalc on an actual calculator

Screenshot of the console and partial fbv image viewer

Of course it runs Doom

My all time favorite, the HP-16C

Below are at least a thousand words covering the HP Prime G2 and other graphical calculators capable of running Linux. You can skip that if you just want to read about my updated Linux port for the Prime G2.

HP Prime G2

The HP Prime is a graphing calculator on the market since 2013, with a hardware revision in 2018 (the G2 model). It has a touch screen and as far as I can find, most people are happy with it and find it a very capable and fast calculator. Here are some pictures of the opened up calculator and here is a website with some more downloads.

I'm not really interested in the calculator part. For most calculations I do for my day job, embedded programming, the HP-16C is a better fit. I was interested in this device because I found posts online suggesting it could run Linux and even a Windows 10 port.

Bow for me for I am root

I do have a history running Linux on older HP devices and I do like to have full privilege on all devices I own. Back then I wrote:

I have a rule that I try to adhere to for devices I own. They must allow a means of root or administrative actions. The Nintendo Switch I got second hand is old enough to be jailbroken. The two Apple devices I own (a first gen iPad Air and first-gen iPhone SE) have vulnerabilities that give me root access. All Android phones I owned I've specifically bought because the bootloader can be unlocked. Once I buy a device, it is mine and I decide what to do with it. Not the manufacturer. Otherwise it is e-waste the moment it leaves the factory.

Being able to develop software on a device is almost a must have as well for me. Missing functionality, otherwise known as stuff the manufacturer does not make (enough) money on, can be programmed back in as long as you can develop on a device and are willing to put in enough time and/or money.

Now with a calculator that isn't a huge issue since I don't see them as general purpose computing devices. Although Texas Instruments did later on removed and restricted features that their device shipped with initially, namely running assembly code on your calculator and Numworks also locked down their calculators. That all has to do with cheating and exam mode, so I do understand that part. If your device is not allowed on official exams / tests, it won't be used or sell well. On the HP Prime there never was assembly (only a custom basic like language called PPL) so they can't take that away. There is a quote from an HP employee stating:

"It is not locked down and is just used for verification at this time. Note however, we DO have the ability to fully encrypt and lock the system to hell as that is part of the new chip. We DO have that tested and working. We WILL turn it on if needed. It IS a corporate security mandate (after things like firmware being loaded into mice/keyboard or printers to hack networks came to light) that we fought to get an exemption for. Nobody dick around with exam mode."

Hardware specs for a calculator!?

The Prime G2 is comically overpowered for a calculator if you ask me. It has an i.MX 6 Ultralite ARM Cortex A7 CPU, 256 MB DDR3 RAM and 512 MB of internal storage. I mean come on! It's closer to a small embedded Linux machine with a calculator keyboard attached than to a traditional calculator.

The G1, the previous hardware revision already had a 400MHz ARM CPU with 32MB ram, but the G2 is like an Android phone of a few years back.

The coffee machine hardware I work on at my day job has an i.MX6 module with comparable specifications. And that runs dedicated C++ and Qt applications on top of Yocto. The HP Prime G2 runs on FreeRTOS and the G1 runs on a custom RTOS named Besta OS.

I'm still shocked by the specifications, for a calculator! In daily usage it is very responsive and compared to other calculators, calculations are way faster, graphing is faster and via the touchscreen you can zoom/scale graphs, which is also almost instant. So they do put those specs to good use at least.

Hardware specs for other calculators

Let's check what their competitors have regarding specifications and possible Linux support. I've tried to find specifications of a few models available here in The Netherlands.

The TI 84+ CE has an 48 MHz eZ80. No linux there.

The Numworks Graphing Calculator N0110 has a 216 MHz ARM Cortex-M7 CPU, 8 MB storage and 256 KB of SRAM. I still find 216 MHz to be way more megahertz than you'll probably need for a calculator, but who am I to judge. The later N0120 model even has a ridiculous 550 MHz ARM Cortex-M7, but a more reasonable 564KB of RAM. Then we're talking microcontroller levels of RAM. No linux here, but the OS is open source. There are even a few forks, but it seems that later firmware versions are locked down. Sad for enthousiasts, but probably it has something to do with cheating and exam mode.

The Casio FX-CG50 doesn't list cpu specifications but this post says 118 MHz and this post says the type, a custom Renesas SH7305 CPU, 8 MB of RAM and 32 MB of ROM. No linux there either. Although, maybe this guy can make it work.

The only other calculator I found with a linux port is the TI Nspire CX (II) (CAS). Here is an article on running Arch Linux on it and here is more info. The CX-II has a 396MHz ARM CPU with 64MB RAM and 128MB of flash storage. Not as much as the HP Prime, but still Linux capable.

My favourite calculator, the HP-16C, is a different story. This is not a competitor because it has no graphing features and its not exactly modern. The NUT CPU detailed description (A-1LF5-9002-1 - 7/14/81) states 200 to 230KHz for the 11C/12C and 340 to 380KHz for the 41C. There is a definition in the Nonpareii emulator stating 215 kHz, a post here by Nelson M. Sicuro from 2003 suggesting about 230 kHz and this page, stating 220 kHz. And 203 bytes of storage for programs. No Linux there sadly.

I don't have a big calculator collection nor am I an expert on calculators. I used them in high school and further in my education whenever math was involved. I stil have a TI-83 somewhere from those days. And a HP 11C, the non programmer, regular version of the HP 16C. I like that the 11C is RPN. For math, that just clicks better in my head.

HP Prime G2 Linux

For the G2 there is an old unsupported port with a 4.14 kernel. The linked linux repo no longer has the correct branch, buildroot failed, the devicetree file was messed up and the provided download doesn't show a console login, so I couldn't really use it. But it provided enough info to get started. I've updated the port for my HP Prime G2, with some enhancements:

• Make the keyboard better, you couldn't enter numbers or characters like pipe, a dash or an underscore.
• Shows up as an USB serial device
• Runs in RAM but allows a larger than 15MB image.
• My unit has a newer touchscreen controller (Ilitek ILI211X, due to the old Goodix GT5688 being out of production), made a kernel driver for it.
• You can login to the console
• The X11 server works and has a few basic apps
• Ships with Doom (prboom) at a great framerate
• Ships with a C compiler for on device development

After reconstructing the repo's using software heritage I was able to get a build up and running. I only tried running this in RAM, not wanting to flash the NAND and potentially loose the original calculator software.

hp-prime-g2-linux-console

The keyboard in Linux was only sending the orange marked letters, no dashes, underscores, numbers or a pipe character. At first I made an alternative keymap which loadkeys configured at boot. However, that didn't work in X11, so I just patched up the kernels keyboard driver (imx_keypad.c) to send the correct keys. The patch intercepts keycodes and if the ALT key is pressed it sends a different keycode. See input-event-codes.h for the mapping.

Using the Alpha key (ALT) you can enter numbers and some other special characters. Pressing the ALT key together with e.g. COS or TAN failed to send a keycode. I didn't look into that further, just used other keys. It might have to do with the keyboard matrix.

The original build's uuu scripts could boot Linux in RAM, but only a 15MB max build. By changing offsets in the kernel configuration, uuu script and u-boot you can now run an image up to 130 MB from RAM.

The original port did not boot up to a login screen but that was just a case of configuring getty in the init scripts.

The original build and a few articles in Russian (here, here and here) had a working touchscreen using a Goodix kernel driver, but in my build that did not work. It claimed to be on i2c bus 1 address 0x14 but i2cdetect showed no such address. It did show a mystery device at 0x26, which while poking around showed a data structure changing while touches were sent.

After much fiddling and looking at raw i2c messages I found out that it looked comparable to an Illitek ILI211X device. Newer kernels have a driver and the ILI211X_DATA_SIZE matches my observations for a 43 byte data packet on i2c, a 0x5a start byte and the 0x26 address matched with another imx6 devicetree with that driver.

The HP recovery screen showed the touchscreen fw version as ilitek-03 which also was a hint. This old kernel has no driver for that model, only for older ones with a different protocol. I coded up a kernel driver based on the newer kernel driver, but stripped out all non-essentials, for example multitouch and finger pressure. I also made a calibration tool fbtouch_test since my screen had some oddities in the bottom right corner. Later I found a french forum post that stated that HP switched screens due to the Goodix ones not being in production anymore.

Working touchscreen

During debugging I found that modprobing the kernel module for usb serial support locked up the entire device. I changed that from a loadable kernel module to compiled in the kernel, which gave no crash anymore. I can now connect via serial to my calculator.

With touch support working I could also include X11 and a few programs. Once you're logged in on the console, type startx and twm will start together with xeyes, xclock and xcalc. Mouse and keyboard inputs work. Have fun running xcalc on your calculator. A long press is interpreted as a right click.

For fun I added tcc, the tiny c compiler. Because what good is a calculator if you can't compile your own code on it? There is a small sample hello.c file in /root which you can compile (tcc hello.c -o hello) and run (./hello) yourself.

The source code is available on my github:

• linux
• buildroot
• u-boot
• prime-linux

For convinience I've made a pre-built download you can directly run without compiling the entire thing. buildroot and linux take quite a while to build and might bitrot over time. With the pre-built download you can get started right away playing.

Instructions for running Linux on the HP Prime G2

Beware that you need to open up your calculator and you might damage it, unrecoverable, not being able to boot into the HP software. Continue with caution.

Download the pre-built package from HERE and extract it to a folder. Download uuu from here.

Open the calculator (remove 4 screws from the back, open the housing with a small pry tool or guitar pick), plug it in via USB and press the RESET button while shorting 2 pads marked on the photo:

I've used an iFixit tweezer to short those two pads, they're tiny.

Use the uuu script to boot Linux in RAM:

uuu ./run_linux_in_ram.uu

After a few seconds you should see a login prompt. You can login as root without a password. Type startx to start the graphical environment. Type sh ./doom.sh to start Doom.

I have not tested any of the NAND flashing scripts so use those at your own risk. The Goodix touchscreen should still work, but I cannot test that. If you have a unit with that type of screen, please test and let me know.

HP Prime G1 Linux

For the Prime G1 there is a forum topic and screenshot here and this port has actual source code and a modern 6.x kernel. I don't have G1 hardware so I cannot test this version. The port provides no downloadable image, you have to build one yourself. The instructions are on the page, but a bit tense. Note that this is specifically for the G1 hardware version. I did try to build this version myself to see if there was much bit rot or broken links, but surprisingly it all went quite smooth still.

First clone all 4 repo's:

mkdir prime-linux
cd prime-linux
git clone https://github.com/Repeerc/Linux-For-HPPrime-V2
git clone https://github.com/Repeerc/hpprimev2_linux_loader
git clone https://github.com/Repeerc/Kernel-6.1.35-HP-Prime-V2_G1
git clone https://github.com/Repeerc/buildroot_hpprimev2

Build the loader:

cd hpprimev2_linux_loader
mkdir build
cd build
cmake ..
make
cp BOOT1.ROM ../../

If you receive an error like error: unknown type name 'caddr_t', replace that type with void in the code. Modern compilers don't support that anymore.

Build the kernel:

cd ../../
cd Kernel-6.1.35-HP-Prime-V2_G1
make ARCH=arm CROSS_COMPILE=arm-none-eabi- hpprimev2_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-eabi- zImage -j8
cp arch/arm/boot/zImage ../../

Build buildroot:

cd ../../
cd buildroot_hpprimev2
make hpprimev2_defconfig
make
cp output/images/rootfs.jffs2 ../../

Package it all up together:

cd ../../
cp BOOT1.ROM Linux-For-HPPrime-V2/
cp zImage Linux-For-HPPrime-V2/
cp rootfs.jffs2 Linux-For-HPPrime-V2/
cd Linux-For-HPPrime-V2/
bash ./mkimg.sh

Flash BOOT1.ROM and LINUX.DAT to the calculator:

Use usbtool.exe, connect the calculator in Recovery Mode (RESET + Symb) , select Auto update then click Update.

There are documents online suggesting this won't work with a USB3 port.

Here are a few screenshots I found online.

Prime G1 screenshot from the 2017 forum topic:

prime g1 screenshot

Prime G1 running an X session:

Prime g1 x11

Prime G1 also has a Doom port:

prime G1 doom

Windows?!

If you're that kind of person, someone ported UEFI for Windows 10 (source). Check out the most meta picture ever, Windows calc.exe on an actual calculator:

calc.exe

I cannot find any downloadable image and some links on the blog post to twitter are deleted so I cannot test this build myself. There are a few more screenshots:

Failed bootloader:

bootloader win

The boot screen:

bootloader 2

The print dialog:

win print

Notepad:

notepad

Credit: aroz_design07 / Shutterstock

What you’ll learn:

• AI financial advice encourages people to save more, diversify their investing, and take on less risk as they age.
• However, AI’s advice often fails to properly adjust to shocks like unemployment, and it allows portfolios to drift rather than actively rebalancing them.
• Differences in prompts can lead to variation in advice, based on gender, degree of financial literacy, and familiarity with using large language models.

People are increasingly turning to artificial intelligence for financial advice, but will following it improve their financial standing?

“Half of Americans say they are using AI to get financial advice, but we know very little about what kind of advice they’re getting and whether they’re acting on it,” said Taha Choukhmane, an assistant professor of finance at the MIT Sloan School of Management and co-author of a new paper that measures and analyzes the quality of financial advice given by large language models.

Research by Choukhmane and co-authors showed that following AI recommendations can result in sizable saving buffers for virtually all individuals above age 30.

AI consistently advised people to save during their working years, draw down savings in retirement, invest heavily in diversified stock funds, and reduce stock exposure after age 45. However, AI chatbots were less successful in adjusting to shocks like unemployment, and they allowed portfolios to drift rather than actively rebalancing them.

The quality of financial advice given by LLMs improved when the researchers introduced more structured prompts, but the AI still often generated too little active portfolio rebalancing. 

How the study was conducted

The researchers built a model reflecting how people’s incomes, jobs, investments, and taxes typically evolve over their lives, which gave them a benchmark for what “good” financial decisions look like. 

Then they asked a sample of 1,000 adults to write their own prompts seeking spending and investing advice from GPT-5.2, GPT-5.6, or Gemini 3 Flash. 

Next, they simulated what would happen if people from 22 to 89 years of age followed that advice over time, repeatedly asking AI these same types of questions and following its advice on spending, saving, and investing. 

How the researchers define “academic prompt”

An academic prompt is one that asks the LLM to give regulated professional financial advice, references life cycle planning and the user’s best interests, and provides explicit information about all of the simulated individual’s relevant financial conditions and explicit assumptions about the economic environment.

Finally, they repeated the exercise using well-written academic prompts that included full financial information and clear assumptions. These more-detailed prompts included information on the individual’s age, job status, income, and savings balances, along with assumptions about the economic environment. 

The authors compared the simulated advice (what would happen if regular people followed the AI recommendations from the prompts they gave) to what people were already doing financially without the help of AI. They also compared the simulated advice to the academic prompt. 

The results showed that LLMs can offer an affordable, widely accessible source of financial guidance that can help users overcome the significant costs, biases, and conflicts of interest associated with traditional human financial advisors.

Breaking down the findings

Overall, the researchers found that the financial advice given by LLMs over time is good but gets better when the questions are asked in an academic fashion, and that the models have strengths and weaknesses. 

1. AI encourages smart financial behavior.

LLM advice was better than the scholars expected, regardless of whether the prompts were written by regular users or by academics. It steered people toward higher savings, increased participation in the stock market, and promoted well-diversified allocations and age-appropriate risk-taking. 

“We were somewhat surprised by how good the advice was,” Choukhmane said. “Especially when you read the kind of questions people asked, it was not a given that the advice would line up with what academics think are good financial principles.”

2. AI misses important nuances. Better prompts could help.

The LLMs’ advice fell short on more subtle aspects of good financial planning. It tended to rely on simple rules of thumb for saving and spending and didn’t adjust well enough when circumstances changed. For example, it advised people who had experienced a job loss to cut spending too sharply, even when they had savings. 

The way people ask questions is part of the problem. A typical prompt might read: “Where should I invest starting with $50 and consistently adding $25 a month after?”

When a more detailed, structured “academic” prompt was used, the LLM performed better. For example, an academic prompt might tell the chatbot to assume normal life expectancy, living expenditures, retirement age, employment risk, and income risk, and to assume that current U.S. tax law and Social Security rules will not change.

“Regular people are not writing their prompts the way a finance professor is,” Choukhmane said.

3. AI advice varies depending on the user, which can lead to wealth gaps.

The authors found that LLMs’ advice differs depending on the prompter’s gender, financial literacy, and experience, leading to meaningful gaps in retirement wealth. 

Following the advice in response to prompts written by men, more financially literate users, or those with prior AI experience generated about 5% more wealth close to retirement. Specifically, 

• The LLM recommended higher equity allocations in response to prompts written by men and by individuals with high financial literacy. Over the life cycle, such differences in investment advice compounded into roughly $50,000 (4%) lower wealth at age 60 for women and for less financially literate users.
• The LLM recommended lower saving rates in response to prompts written by individuals who had not previously used AI for financial advice. Following the advice left them with almost $100,000 (6%) less wealth at age 60 than individuals with prior AI experience.

These differences come from two sources, Choukhmane said. First, different users asked different kinds of questions and often brought up different topics. Women, for example, were more likely to use words such as “family,” “grocery,” and “pay” in their prompts, while men used words like “strategy,” “crypto,” and “growth,” he said. 

Second, the model may give different advice even when the underlying question is the same. In the case of gender, about two-thirds of the gender gap in wealth outcomes could be attributed to differences in how men and women wrote their prompts, while the remaining third came from the model changing its advice when the same prompt was labeled as coming from a woman rather than a man. 

That latter pattern could reflect the LLM making reasonable inferences about how preferences or circumstances vary by gender — which, ideally, the model could make explicit to users, Choukhmane said — or it could reflect biases learned from training data.

The challenge with AI financial advice is that there are no clear benchmarks, Choukhmane said. Only when there is an accepted framework for how advice should vary with demographics will LLMs be capable of progressing in the right direction. He said he remains hopeful that will happen. 

In addition, it’s important to remember that not all variation in advice is problematic, Choukhmane said. For example, “we want [the LLM] to have different bias because men and women are different and have different life expectancy and income risk,” he said. 

Takeaways for consumers

Beyond being mindful of bias, and, for the time being, asking LLMs to guard against it, success boils down to smarter prompts. Prompts grounded in life-cycle planning, portfolio theory, and real-world financial assumptions improved advice on spending and saving and cut down on basic, rule-of-thumb answers.

“I think the real challenge is, how do we make sure that AI financial advice delivers for people who don’t have [a] level of financial literacy and who don’t write prompts perfectly?” Choukhmane said. One idea for people interested in using AI for financial advice is to start by using AI as a tool for building financial understanding rather than simply following its advice.

AI can serve as a good complement to working with a financial advisor — someone you might meet with twice a year — because it can help you implement the advice they give you in real time, Choukhmane said. 

And for people who don’t have the money to work with a human financial advisor, AI is a good way to get advice inexpensively. “A lot of the people who would benefit from financial advice are precisely the people who don’t have a lot of resources,” he said.

Takeaways for business

As consumers increasingly turn to LLMs for financial advice, providers may need to rethink how customers learn about their products. The study found that LLMs often recommended specific account types, financial products, and providers that respondents themselves did not mention. (For example, Vanguard investment products appeared in 6% of LLM responses, and iShares products appeared in 3.4%, even though fewer than 0.4% of prompts mentioned either company.)

That suggests that AI advice might be changing how people find and compare financial products, Choukhmane said. For financial firms, attracting customers’ attention may depend less on traditional marketing or search visibility and more on whether and how their products are described by LLMs when consumers seek advice.

“AI Financial Advice: Supply, Demand, and Life Cycle Implications,” which won the Swiss Finance Institute Outstanding Paper Award 2026*,* was written by Taha Choukhmane, Weidong Lin, and Matthew Akuzawa from MIT Sloan and by Tim de Silva from the Stanford Graduate School of Business.

Pushing 2.4 GHz Wi-Fi to the limits.

Introduction

For this project, we aim to answer a simple question: given an ideal environment, how far can you push the range of Wi-Fi connectivity?

To test this, we set out with the goal to control a robot as far away as possible using Wi-Fi to transmit commands from a laptop to a Phidget SBC4.

Before we could start, though, we had to do some research.

Setting Up the Test

Background Research

Some Definitions

To get a handle on our main question, we need to establish some background. Wireless communications, such as Wi-Fi, rely on transmitting radio waves at a specific frequency in specific patterns. These patterns are then picked up by a receiving antenna, and translated to usable data. In order for the receiver to understand the incoming signal, it must be strong and clear enough to be distinguished from background noise. The power of a transmission decreases with distance from the transmitter, so to increase the range of a given transmission, you can increase the power in the signal.

The power for wireless communications transmissions is specified in terms of watts, and dBm (decibel-milliwatts). The dBm unit is a logarithmic scale, where 0dBm is one milliwatt, and every additional 10dBm is 10 times more power.

Antennas can be used to boost the effective power of a wireless transmission. They do this by focusing the power that would otherwise be dispersed in all directions into a smaller area. The amount the antenna increases signal strength in its focal area is called the gain. The gain of an antenna is specified in in dBi, which stands for decibels over isotropic, and indicates the amount the input signal is boosted in the focal area relative to a hypothetical antenna that emits power equally in all directions.

Connecting an antenna to a transmitter, the output power of the system is rated in terms of Equivalent Isotropic Radiated Power or EIRP. This describes the intensity of the signal in the focal area of the antenna, relative to an antenna that emits power equally in all directions. To calculate the EIRP, you multiply the power of the transmitter by the gain of the antenna. Since both are rated in terms of decibels, the dBm of the transmitter and the dBi of the antenna can be added together to get the EIRP of the sytstem.

How much can I boost my Wi-Fi signal?

Now that we have all the techno-babble established, we can answer this question.

For a Wi-Fi transmitter to be allowed to operate in Canada and the United States, the maximum transmitter output power for a 2.4GHz Wi-Fi transmitter is 1W (30dBm), with a maximum EIRP of 4W (36dBi), before you need to licence your application. [Canadian Regulations] [FCC Regulations]

These regulations are less strict if you are using directional antennas in a fixed point-to-point configuration with no moving parts, but our aim is to control a rover over Wi-Fi, so while this may help in some situations, it does not apply to our test.

For transmitters with less power, you can subtract the power of the transmitter in dBm from 36dBi, and the remaining dBi is the maximum gain you can use for your antenna.

In practical terms, what this means is that you can take a standard Wi-Fi transmitter with 0.1W (20dBm) of output power, and attach it to an antenna with up to 16dBi of gain, and be just within the limits for licence-exempt RF operation in the United States and Canada.

What about 5GHz Wi-Fi?

As a general rule, as the carrier frequency of a transmission is increased, it suffers greater losses as it travels and will have a shorter range. Because of this, 2.4GHz communications will have a longer range than an equivalent 5GHz signal, so we will focus on the former.

Equipment

With the knowledge of the specific limitations of how much power we can put into our Wi-Fi signal, we can look for equipment to push as close to this limit as we can.

Parts List

• 802.11n Wi-Fi Adapters
• 12dBi 2.4GHz Omni-directional Antennas
• 14dBi 2.4GHz Yagi Antenna
• Phidget SBC4
• Windows Laptop

802.11n Wi-Fi Adapters

For this experiment, we opted to use 802.11n USB Wi-Fi adapters to send and receive our signals. Specifically, we used a MOD-WIFI-R5370-ANT adapter, which is a variant of the 3706_0 adapter (sold by Phidgets), that has an external antenna jack. These adapters proved a good fit for the experiment, with 20dBi output power, and compatibility with both the linux-based Phidget SBC4 and the Windows laptop, allowing it to be used on both ends of our Wi-Fi network.

Since our transmitter has 20dBm of output power, we can use antennas with up to 16dBi of gain.

Omni-Directional Antenna

The Omnidirectional Antenna

The omni-directional antenna we sourced for this experiment is 1.2m tall, and focuses the signal it transmits into a horizontal disc, with a gain of 12dBi. This disc is specified to have a 7° slope from horizontal, so the antenna will have to be kept level, and other antennas in the system will have to be at roughly the same height for the best results.

This antenna would be the ideal solution to attach to a large moving platform.

Yagi Antenna

The Yagi Antenna

Looking like something directly out of a sci-fi movie, the Yagi antenna uses a specialized set of parallel elements to transmit and receive radio waves along very focused beam. Yagi antennas are ideal for transmitting wireless signals between fixed points over incredibly long distances.

The antenna we used for this experiment had a gain of 14dBi, with a length of 0.59m. It specifies the beam it transmits is 36° wide.

The Small Omnidirectional Antenna

Small Omnidirectional Antenna

The final antenna we tested was the small 2dBi omnidirectional antenna that came with the USB Wi-Fi adapters. This antenna serves as a stand-in for a typical Wi-Fi device, and gives a baseline of what you might expect from a laptop or cell phone.

The Test

To test the Wi-Fi signal strength at various long distances under nearly ideal conditions, we travelled to a small airport outside the city. This ensured very flat ground to guarantee line of sight, and minimal interference from outside signals. Pair all this with a relatively dry climate, and we have as close to an ideal testing ground as we're likely to find outside of a lab.

We used standard GPS to mark the locations of our base station, and the locations of various landmarks beside the runway where we measured the Wi-Fi signals.

Taking Measurements

The basic setup we used was to host a Wi-Fi network on a Windows laptop, and set up a PhidgetSBC to connect to it. This was done to mimic a potential scenario where a number of rovers running on Phidgets SBCs might be controlled by a single, central server.

For simplicity, we placed the SBC4 in a static location (the Base) for all measurements, and moved the laptop from point to point in the field. This allowed easy access to the keyboard and mouse for the duration of testing.

Wi-Fi signals were categorized using the open source iperf3 software to measure bandwidth, and using the iwlist wlan0 scan linux command on the SBC4 to measure the strength of the Wi-Fi signal. Since we were carrying the network host from point to point, we connected to the Phidget SBC using PuTTY to access its command line to get a reading of the signal strength at each point.

Results

Signal Strength Chart (Click to Enlarge)

Data Rate Chart (Click to Enlarge)

Discussion

The results from this test show that using a standard 0.1W USB Wi-Fi adapter, you can realistically extend your Wi-Fi out to 1400m using the right antennas.

Other antennas were not tested beyond the 770m point, as this point marked the end of the airfield's property. The farthest two points were taken in the middle of a farmer's field, and we decided not to leave the airport more than once. At 1400m we reached a road, and decided that was as far as we would go.

It is interesting to see how the stock 2dBi antennas still managed to transmit a functional Wi-Fi signal out to 430m. This neatly showcases the effects that structures and interference have on the range of a Wi-Fi signal, as this is much farther than it would reach indoors. Beyond 430m, while data was technically being transmitted, the reception was intermittent and experienced several seconds of packet loss between successful transmissions.

Our data seems to indicate an increase in the data rate at the 600m point. This could be due to a number of causes, though it is difficult to point to anything directly. Perhaps a small incline improved the alignment of our antennas.

The very directional yagi antenna had notably less signal drop-off for points directly in its line of sight than the large omni-directional antenna. However, any deviation outside the antenna's beam resulted in a largely diminished signal.

Conclusions

After analyzing the data, we can claim that given the right equipment, a Wi-Fi signal can propagate at least 1400m under idealized real-world conditions.

Here's a video of us driving the antenna-tank over Wi-Fi at 770m (wait until the end to see how far away this really is):