Getting started

The Godot lab is the easiest place to see the project doing something. It puts image providers beside one another and lets you change the source, operation and overlay. The walkthrough has a capture if you'd like to look around before building it.

Building the example

The reference build uses Linux x86-64, Bazel, Godot, the configured Clang toolchain and the dependencies pinned by the build. The CUDA examples also need the CUDA SDK and a compatible NVIDIA GPU and driver.

Development currently uses sibling checkouts:

workspace/
  tetrodotoxin/
  cuda/
  godot/

The repositories are linked from the Tetrodotoxin organization. Godot's MODULE.bazel selects those local dependencies, so their revisions need to agree. The build configuration and tools directory contain the requirements for the revision you're using.

From the Godot repository root, this script builds the addon, installs it into the demo project and launches the scene:

tools/run-lab.sh

There is also a CPU/script build path:

tools/run-lab.sh --cpu

That path leaves CUDA unavailable. A renderer that requires it should report the missing capability rather than present another provider's result under the same label.

Following the work through the scene

Start with an operation offered by several renderers and compare their images. Then move the overlay. The composed result should change while the unrelated upstream filter remains reusable. Changing the source gives that filter new work to do.

The renderer Resources and policies show where those decisions belong. The controller gathers offered operations, while each provider supplies its implementation and enforces its limits. The project-authored CUDA source is another useful place to look: the project gives the kernel its image meaning, and the CUDA service supplies compilation and execution.

The timings are useful for exploring those choices, although they cover more than interface dispatch. Result creation, computation, readback and UI work can have very different costs. Compare a measurement with the path it includes before using it to explain why one implementation is faster.

Checking the integration

The repository's check script runs the native and engine-facing checks:

tools/check.sh

check.sh also describes the CPU-only and nonvisual options. The visual check uses the actual scene to exercise renderer discovery and connected updates.

Once the example is familiar, core concepts explains the underlying interfaces and development describes the review and test approach. The Puffer page follows the related work on the source toolchain.