Optional · the gpu feature
On the graphics card
Alignment, the Apex, Relief and Strata fusions and the Relief multigrid solver can run on the GPU through wgpu (Vulkan, Direct3D 12 or Metal). The CPU stays the reference and the fallback.
01What runs where
| Stage | On the GPU |
|---|---|
| Alignment: the objective | yes. Each candidate transform is evaluated on the device; the optimiser itself stays on the CPU. Pyramid levels under 64k pixels are evaluated on the CPU, where they are faster. |
| Alignment: the final warp | yes, with the coverage mask from the same pass |
| Apex fusion | yes, the whole fusion: pyramids, selection, averaged base, reconstruction |
| Relief fusion | yes: focus maps, selection against the threshold, guided filter (focus radius up to 100) |
| Relief multigrid solver | yes: the pinned depth is uploaded once and the whole cycle (restrict, prolong, Jacobi sweeps) runs on the device; the focus maps and the final smoothing stay on the CPU |
| Strata fusion | yes for its two heavy steps: the saliency of each frame and the guided-filter pair that refines the layer weights. The base/detail split, the accumulation and the final blend stay on the CPU |
| Decoding, auto-cull, export | no |
Frames are folded in one at a time on the device, so its memory does not grow
with the number of frames, and only the result comes back. During alignment
each pyramid level goes up once; the hundreds of evaluations the optimiser
makes on it move only a few numbers. Lucas-Kanade, the first step of the
auto optimizer, is a CPU path in every build: only the
Nelder-Mead objective runs on the device, so a GPU run with
optimizer = "neldermead" uses the alignment kernels fully. In the
command-line tool Strata runs on the CPU.
In the browser version only the alignment runs on the GPU, through WebGPU; the fusions, Strata and the multigrid solver run on the CPU in a Web Worker.
02Switching it on
Build with the gpu feature and set the compute device to GPU, in
the desktop app's settings (Compute device) or in the settings file:
cargo build --release -p z-stackr-gui --features gpu
cargo build --release -p z-stackr-cli --features gpucompute_device = "gpu"Without the feature, no GPU code is linked, the settings offer the CPU only, and a settings file that asks for the GPU still loads: the run uses the CPU and says so. The best adapter is chosen automatically: a discrete card before an integrated one, Vulkan before Direct3D 12.
03When the GPU cannot help
A run never fails because of the GPU.
| What happens | What z-stackr does |
|---|---|
| no usable adapter, or a build without GPU support | the CPU from the start, with one message saying why |
| a call needs more device memory than the budget (3 GiB), or a setting the kernels do not cover | the CPU for that call only; the GPU stays on for the others |
| the device reports an error, a call fails or returns non-finite values | the CPU for that call and the rest of the run, with one message giving the reason |
04How close it is to the CPU
The GPU kernels follow the CPU code operation for operation and are tested against it, but they are not bit for bit the same: drivers may fuse a multiply and an add, and the GPU's division is not always correctly rounded.
- Apex: within about 3×10−7 on the test stacks.
- Relief: the focus maps agree to within 5×10−7 of their range; where two frames are equally sharp to within rounding, the winner can differ. On a real series of eight 8-megapixel frames, 0.016 % of the pixels differed by more than 1/1000.
- Strata: the saliency agrees to within 10−5 of the map's range. The guided-filter pair, whose window sums are
f32on the device where the CPU usesf64tables, stays below 10−3 at worst and 10−5 on average for masks between 0 and 1. - Multigrid: the solved depth agrees within 10−3 of a frame index at worst and 10−4 on average; the operations and their order are the CPU's, only fused multiply-adds differ.
- Alignment objective: the same pixels take part and the RMS agrees to about 10−7; the warp agrees to within 3×10−6 with the same coverage.
Because the objective differs in the last digits, an alignment on the GPU can take a slightly different path through the search. Where the frames have a clear best fit, both land within about a thousandth of a pixel of each other. Where the fit is flat (two frames far apart in focus share little detail), both land on points of equal quality that can be a few tenths of a pixel apart, about as far as the CPU's own alignment modes differ from each other there.
05Speed
Timings will be published here once they have been measured on a quiet machine; this includes whether the multigrid solver on the device beats the CPU solve, and the Strata kernels. The first, informal runs on an integrated GPU showed the largest gain in alignment, where the optimiser's many evaluations stay on the device, and a smaller one for the fusions, which are limited by uploading the frames.