TensorRT

TensorRT (Linux)

TensorRT is NVIDIA's optimizer for its graphics cards. With it on, CorridorKey optimizes its networks for your card, once per resolution range, and then keys faster, with the same mattes as CUDA. It's optional and off by default.

How much faster, and what it costs in graphics memory, was measured on an RTX 5080 in the engineering notes: TensorRT on onnx.4 and the same-day pair. Other cards and sizes weren't measured. It's best on cards with 16 GB.

Linux only in this version. On Windows it needs its own engine builder, which comes later; Macs have no NVIDIA graphics. Jobs there run on CUDA.

Switching it on

1. Finish the normal setup first (the GPU runtime and the models).

2. Open the Engine page's settings panel, TensorRT, and tick Use TensorRT (NVIDIA).

3. Press Download and install. TensorRT has its own download:

   • NVIDIA's TensorRT 10.16 libraries (NVIDIA licence), from pypi.nvidia.com;
   • ONNX Runtime's TensorRT part, from pypi.org (only if your runtime was installed before 1.0);
   • the TensorRT models: the same CorridorKey networks, prepared for TensorRT, from this project's GitHub releases. The largest file is copied from the models you already have instead of being downloaded. They go into the folder of the model set chosen in Engine settings, Model set: 2.0.0-onnx.4 gets its own TensorRT set, 2.0.0-onnx.4-trt; 2.0.0-onnx.5 uses the same 2.0.0-onnx.4-trt for now (onnx.5's own TensorRT set isn't measured yet). After switching sets, press Download and install again: the TensorRT models go into the new set's folder (the libraries stay), and until then jobs run on CUDA.

   Like the first install it shows its progress, can be stopped and resumed, and checks every file's SHA-256. The button shows the size; the download and disk sizes are in the engineering notes' Requirements.

Until the parts are installed, jobs run on CUDA.

Builds in the background, per resolution range

TensorRT has to build engines for your card before it can key a size. The app does this in the background, never inside a job:

• Once TensorRT is installed, it builds 4K DCI first, then HD, with a progress bar in Engine settings (which network it's on, how far, how long so far).
• It pauses while you key and goes on by itself when the queue stops. If another program is using the graphics card, it waits until the card is free; Build now starts it anyway. Stop keeps what was built.
• One build per size covers your card. Each build covers every temporal window a job of that size can pick on your card (worked out from the card's total memory, never from what happens to be free while it builds), up to what was measured to build for that size: 4K 8 frames and HD (1920×1080) 24, built and run on an RTX 5080 16 GB on 2026-10-25, and 1280×1080 48, built on 2026-10-24. On a 16 GB card that is every window those sizes pick, except a 1280×1080 clip of 49 to 64 frames (it runs all its frames at once, more than the 48 measured, so it runs on CUDA and says so). Other sizes stay within the nearest measured build, and are not measured themselves: on a 16 GB card with nothing else on it, 2560×1440 clips longer than 15 frames, and 2560×1080 and 1920×1440 clips longer than 19, run on CUDA (and say so) until a build of their size is measured. A job's window is never shortened to fit a build: a clip that runs more frames at a time than its size's build (a longer automatic window, as on a 32 GB card, which is not measured) runs on CUDA and says so.
• A busy card uses the build for its window. A job uses its size's engines only when their own memory need fits what it has (engines built for up to 8 frames hold nearly that much memory at any window: measured at 4K, 10.4 GB at window 4 and 11.4 GB at 8). So the checklist builds every window a job of that size can pick, and while another program holds part of the card the clip's automatic window (picked from the free memory, as on CUDA) runs on its own build. Only a clip shorter than its window, whose length falls between two builds, runs on CUDA then, and its page says so (free some memory, or key it later). Under a memory limit too small for them, the page says the limit is, and how to raise it.
• Jobs never wait on a build. A clip whose size isn't built yet runs on CUDA, and its page says so and offers Build it now: one click starts the same background build for that clip's size, and the next run of the clip uses it. A build that runs short of graphics memory says so, with the memory that was free; when another program was using the card it names it and offers Build it again.

Engine settings, TensorRT is a checklist. Each size (720p, HD, 2K DCI, 2K full aperture, 2.8K, 4K DCI, UHD, and sizes of your own) has a tick per window, up to N frames: every window a job of that size can pick on your card, from 2 up to the longest your card builds. The sizes your clips use start with every window ticked; windows already built are ticked, fixed and marked (built). Ticks are a plan: nothing builds until you press Build ticked, and the line above it says how many builds that is, about how many GB on disk and about how many minutes. Stop stops the build. Remove next to a size deletes its engines (it asks first, and not while a job runs). A size of my own adds any width × height inside TensorRT's ranges (Add).

Scan a clips folder… reads only each clip's width and height, from the folder you choose and two folders under it, at most 500 clips. Nothing is keyed, copied, changed or sent anywhere. The sizes it finds are added and ticked. Clips you add to the queue are remembered the same way. A waiting clip whose size isn't built has Build for this clip's size in its TensorRT section.

Each range shows what it holds once built: the windows it was built for, its size on disk and how long the build took on your card. The build time and disk space per range were measured in the engineering notes, TensorRT on onnx.4.

The engines are kept in the cache folder (tensorrt inside it) and are built again only after a graphics driver, TensorRT or model update. A range built from other model files (after the model set changed) says built for other models · needs a rebuild (the model set changed): its clips run on CUDA until it is built again, which Build ticked (or Build it now on the clip's page) does.

Sizes TensorRT takes

TensorRT ranges go up to 4096 pixels a side and 4096×2176 in area: everything from small sizes to DCI 4K and UHD. 4K open gate (4096×3072), 6K and anything larger run on CUDA. If a network can't be built for a range (for example stage 1 at very long windows), that one network runs on CUDA, and the job's log and page say so.

Windows

A job keys with the same temporal window as on CUDA. A size's engines serve every window up to the one they were built for (whether a shorter window on longer engines matches CUDA's mattes as exactly as at their own window is not measured yet), and builds since 1.0.0-dev.7 cover the longest window a job can pick on your card, up to what was measured to build for that size (above). Sizes built by an earlier version were sized from the memory free at that moment and may cover only shorter windows: a clip with a longer window then runs on CUDA, its page says TensorRT isn't built for this clip yet, so this run used CUDA, and Build it now builds the size for your whole card.

Before a clip runs, its TensorRT section says what to expect: "On · built for this size", "On · not built for this size · runs on CUDA", "Outside TensorRT's ranges · CUDA", and so on.

What really ran

Every job's page has Technology for this run: what it ran on (TensorRT, CUDA, or TensorRT with some networks on CUDA) and, when TensorRT wasn't used, why. The same lines are at the top of the job's log file. See Troubleshooting for every reason.

Removing it

Untick Use TensorRT to stop using it. App settings → Storage lists TensorRT as its own item: its libraries and models (in the data folder) and the engines built for your card (in the cache folder). Remove them there.