Independent providers

Once the data and interface agreements are in place, we can ask a more useful question: how different can the implementations be before the consumer needs to care?

In the Godot lab, native C++, project CUDA and GDScript produce images through the same consumer. Their outputs can agree even though a request that works well on one provider would be expensive, or unacceptable, on another. The consumer has to preserve those differences without becoming an implementation of each provider itself.

Giving each provider room to specialize

The native implementation can use PocketFFT to perform convolution. The script implementation calculates the image operation in GDScript. CUDA can keep buffers on the device and launch kernels, with either native provider code or project source supplying the image operation.

Requiring a host byte array after every operation would make the interfaces easy to compare, but it would also force a GPU chain to download intermediate images that its next kernel could have used directly. The provider needs to retain its own representation until a consumer actually asks for another form. That leaves the script runtime and native libraries free to manage their results according to their own lifetimes as well.

The consumer asks for the operation and establishes how it can observe the result. The provider makes the internal choices needed to fulfill that agreement. If the consumer later needs pixels for display, that observation may require a transfer, but it doesn't follow that every preceding operation also had to copy the image.

Adding a provider to the scene

The controller finds renderer nodes and gathers the operations they offer by UUID. It uses those offers to construct the available choices. There is still configuration that selects a module, script or Resource, since something has to decide which implementation the application should load. That decision stays at the application boundary rather than spreading into every image operation.

This becomes useful when a project adds a new CUDA effect. The project supplies its meaning and implementation, the renderer advertises it, and the controller can discover it without learning a new backend name. Another renderer may not offer that effect at all. The scene needs to show that difference honestly.

Offering an operation also leaves room for request-specific limits. The script provider can accept a small convolution while refusing one that would consume too much synchronous work. The UI can help the user stay within those limits, but the provider enforces the policy. Otherwise any caller that bypassed the UI would accidentally bypass the agreement as well.

Following the costs

The lab displays timings because the implementations should be allowed to have different performance characteristics. Those numbers take some care to interpret. An FFT implementation, a direct script loop and a GPU kernel aren't merely three spellings of the same algorithm. Initialization, resource creation and readback can also dominate a small operation.

The native overlay regression checks the work more directly. Changing a CPU overlay uploads that overlay once while preserving the CUDA background and its FFT plan. Pixel readback is a later request. Those counters tell us whether the intended reuse survived, even when elapsed time varies with other activity on the machine.

The lab walkthrough shows the visible result, and the provider tests exercise the agreements behind it. Matching images is one part of that evidence. Refusal, ownership and repeated use are what make the same design useful after the first successful demonstration.