Site

The render thread's side of the forge for one create site (construct-owner-feedback row 8.16).

A member of construct::pathtrace::KernelPipelineForge. Declared in src/libs/libconstruct/construct/pathtrace/KernelPipelineForge.hpp.

Detailed description

SDFLayer's own pipelines froze the viewport's render thread as the kernel did: sdf-geometry 32.1 s and 34.2 s, sdf-forward 9.1 s and 8.2 s in the owner's log of 2026-10-21, with a full driver cache. A site describes its pipelines (rhi::PipelineWarmer::describe()), names them with a key (rhi::PipelineWarmer::key()) and asks advance() before it creates them:

• A key known on this device (KernelPipelineForge::knownOnDevice(): made into its cache in this process, or named with the blob it was primed from), a device the forge refuses, or a host that cannot wait (no submit) answers Create: the create runs on this thread, as before.
• Another key goes to the forge. The calls after it answer Waiting while the helper compiles, and the site keeps drawing with what it has: the previous pipeline, or nothing and the producer's warm-up frame.
• A compile on the helper under 100 ms was a hit in the device's own cache or the driver's disk cache: Create. A forged cache no larger than the cache the helper started from holds no compiled code: the device is marked cacheless (lavapipe) and the site creates here from then on. Otherwise the device takes the forged cache, and Adopted.

finish() after the creates puts the device's own cache back when the forged one does not cover it (KernelPipelineForge::resultCoversDevice()), and hands the cache to keep to its persist callback: the forged cache as it is, or an export after the first create of a key on the device. Before, SDFLayer exported and wrote the whole cache on the render thread after every create: 250 writes of 62 MB and 129 MB in the owner's log.