An application of the TTX model

The Godot compute lab

Suppose we want the same image operation to run in GDScript, a native library or CUDA. Each implementation has good reasons to use different algorithms and storage. The lab explores how much of that difference can stay with the provider while the rest of the application works through a common agreement.

Open the browser lab Explore the project

Try the same scene in your browser

The browser version runs the C++ provider as WebAssembly alongside GDScript. There is no CUDA provider in this deployment, so its panel reports that the requested compiler isn't available. The other panels still discover their operations and respond to the same controls.

Change the source, choose an operation, or move the overlay to follow the work through the connected renderers. The panel labeled Native C++ uses the same PocketFFT implementation here, compiled for the browser. Its timings include browser execution and should be compared within this run, rather than against the native capture below.

Open the interactive lab in a desktop browser with WebGL 2 and WebAssembly SIMD support. The Godot runtime downloads when you open it. You can also run the native project to use CUDA on supported hardware.Source, build instructions and licenses are available for the browser version.

The Godot compute lab shows matching native C++, project CUDA and GDScript results beside the source image. — Captured from the running project. The displayed timings belong to this workload and include different implementation choices; they are not a general ranking of languages or GPUs. Watch the recorded interaction.

What each provider brings

The example is useful because the implementations have different constraints. They need to agree on the operation's observable behavior, while remaining free to decide how to produce it.

Native C++

The native provider can choose specialized algorithms such as PocketFFT convolution and manage its own storage. It exposes the image operations the consumer can request without making that consumer depend on PocketFFT.

GDScript

The script provider calculates image operations in GDScript. It also owns the policy that limits expensive synchronous requests, so the bridge has to preserve both its callable behavior and its ability to refuse work.

CUDA

The native CUDA provider and the project-source path exercise device execution. In the project path, image policy assigns meaning to kernel entries while the CUDA service handles compilation, buffers and kernels.

Following an image request

The scene controller begins by asking its renderer nodes which operations they offer. Those offers identify the behavior by UUID and describe applicable limits. The controller gathers them into the available choices, so adding a renderer doesn't require another branch that knows the provider's name.

When the user selects an operation, the bridge establishes the callable interface and the provider applies its policy to the request. A script provider might accept a small convolution and reject a larger one because of the synchronous work involved. Knowing that it offers convolution is useful, but it doesn't mean every possible request has already been approved.

The retained callable then reaches the implementation. Script objects, native allocations and device buffers remain the provider's concern. An interface publication can supply the receiver and operations without moving the image's pixels.

Pixels cross the boundary when a consumer asks to observe them. The image contract supplies their representation, and transport negotiation establishes how they can be accessed. Display and comparison may require a transfer even when a preceding GPU chain kept its intermediate images resident. Keeping those steps separate gives us a way to inspect where the work actually occurs.

Following an overlay update

A correct image can still be the result of doing far too much work. Suppose the blurred background is already on the GPU and a CPU provider supplies a changed overlay. The composition needs the new overlay, but the background and its FFT plan are still useful. Rebuilding them would turn a small edit into a much larger request.

The native regression measures the provider's counters around producing that composite. For this mixed CPU/CUDA case it expects:

Work during the update	Expected change
Overlay uploads	One
Image downloads	None
FFT plan builds	None
Upstream blur evaluations	None

Readback happens after that measurement so the test can check the resulting pixels against an independent alpha-composition calculation. That is a real transfer with a reason to exist. Acquiring the callable interface is checked separately and must not upload or download pixels.

The consumer reaches those operations through the image's published contracts. It doesn't need the CUDA allocation type to preserve the background. The image graph owns invalidation, the provider owns its resources, and the transport supplies the access they agree to use. Those divisions are useful because we can point to the work each one allows us to avoid.

The image regressionalso checks small convolution results against a direct spatial oracle in double precision. Its benchmark warms the convolution before timing repeated requests and reports readback separately. This catches different mistakes from timing the entire interface and calling the result a kernel benchmark.

bazel test \
  //tests:image_check \
  --config=release \
  --config=cuda \
  --nocache_test_results \
  --test_output=all

Changing the scene without teaching it another backend

The project CUDA renderer includes an effect with its own contract UUID. It appears through the renderer's offers, while the other renderers remain free not to provide it. The rendered check also adds another renderer to the scene. These cases test whether discovery is doing useful work or merely hiding a fixed list of implementations.

The rendered scene checks the same dependency relationship through ordinary controls: moving the overlay retains the upstream filter, and changing the source causes it to run again. This catches mistakes in the scene's connections that a native provider test wouldn't see.

Elsewhere in the integration, the class bridge inspects exported declarations and emits Godot registrations backed by independent runtime factories. Discovery can then be released while instances continue to use their retained callable interfaces. That lifetime distinction lets providers expose domain behavior without taking over Godot registration themselves.

The tests cover those relationships alongside image agreement, refusal and destruction. Native consumers exercise the modules outside Godot, and the rendered test checks the actual scene. These are the examples we can inspect before extending the model to a larger engine or toolchain surface.

What does a replacement need to know?

If a new provider makes the shared consumer learn its allocation strategy, the contract has left work for the next author to discover. That is the connection to the agent research: an agreement that lets people work independently may also reduce how much surrounding code an agent needs to understand before making a correct change.

Read about the research