Linux / Vulkan validation on RTX 3090: hwrt:true, 22-scene real-time sweep, and what drives trace cost #72

Built the engine from source on Linux and ran the full bundled demo set through the headless real-time path on a consumer Ampere card. Hardware ray tracing works end to end — "backend":"Vulkan","hwrt":true, fallbacks: 0 on every frame of every scene.

Posting the numbers and the method because the shipped clients are macOS/iOS and I couldn't find any published Linux or NVIDIA figures. No bug report here; separate issues and PRs cover the asset-fetch gaps.

Built at ef00aa448d493f68bbf98d17ccd9783c86375df4 (main, 2026-11-13).

Environment

{"adapter":"NVIDIA GeForce RTX 3090","backend":"Vulkan","device_type":"DiscreteGpu","driver":"NVIDIA","hwrt":true}

Build

git clone https://github.com/meshy-dev/ThreeRT && cd ThreeRT
npm install
bun scripts/setup.ts
node tools/build-scenes.ts
bun renderer/build.ts

Under four minutes from a clean clone: npm install 2s, setup.ts asset fetch (~976 MB) 1m53s, scene bundling 1s, cargo build --release 1m10s.

Method

All real-time figures below come from the headless live path:

threert-render live out/bundles/<scene>.js \
  --assets <dir> --width 1280 --height 720 \
  --scale 1.0 --bounces 4 --fps 240 \
  --frame-log <scene>.jsonl

60 s per scene, shut down with quit on stdin so the frame log flushes cleanly.

Three deliberate choices, each of which changed the result:

live, not play. view.rs passes None to parse_scale, which resolves to auto — the windowed path applies dynamic resolution scaling to hold the fps target. live/session.rs defaults to 1.0. A number measured through play without an explicit --scale is at an unknown internal resolution. We pin --scale 1.0 either way.

Uncapped (--fps 240), not paced at 60. A paced run on this card reports roughly 2.5× the true frame cost:

trace_mean is flat (1.65 → 1.72) — identical work — while gpu_mean more than halves. Two causes, probably both: the 3090 drops power state during the ~6 ms of idle a 60 fps cap hands it, and any other GPU client takes that gap, so the wait lands inside the frame timer. Paced figures are not frame costs.

GPU otherwise idle. Every figure below was taken with nothing else resident on the card.

(One caveat, kept low: main has moved since ef00aa4 — #67–#70 landed, #68/#69 restructure the live passes — but the interval/gpu instrumentation in live/session.rs and the gpu_ms computation are untouched, so these numbers stand on current main.)

Results

Nine scenes where interval_mean ≈ gpu_mean and frame count is consistent with the 60 s window. The other thirteen are excluded for a measurement reason explained below — not because they failed.

All times in ms. 1280×720, --scale 1.0, --bounces 4, uncapped.

bistro-district's 143.63 ms max is a first-frame cost, not a frame cost. Re-analysing the log with the first 100 frames dropped puts gpu_max at 8.21 ms, within 1.2 ms of the 6.99 ms mean. It's the initial accel-structure build plus geometry upload on a fresh device.

Static vs scene in motion, same assets

zero-day and zero-day-animated share geometry (MEASURE_ONE.gltf, 5.87 M triangles, 551 animated objects, 412-frame animation), which makes them a controlled pair. history_mean collapsing from 3134 to 32 confirms temporal accumulation resetting continuously in the animated version.

A 14 % GPU cost increase for a fully-resetting temporal history on a 5.87 M triangle scene is a smaller penalty than we expected. Note this is animated scene content rather than a verified moving camera — live is headless, so there is no input, and the motion comes from the bundle's frame script.

Three other scenes show the same ~32 history signature: bistro-slice (31.6), instancing (31.9), mannequin-plaza (31.9).

Why thirteen scenes are excluded

Fully-converged static scenes report an interval_mean below their own gpu_mean, which cannot be right. cornell-box: gpu_mean 2.64 ms, interval_mean 0.36 ms, implying 2759 fps.

Dividing frame count by reported fps gives an implied render duration. Every scene ran for a full 60 s:

The nine scenes in the results table land at 50–59 s, consistent with 60 s minus load. The excluded thirteen land at 3–12 s. Their true throughput by frame count is n/60 — around 237 fps for most, not 1700–3400.

Our reading is that once history converges and nothing in the scene changes, the renderer stops doing per-frame trace work and interval stops tracking wall-clock while gpu retains a stale value. If that's intended, the frame log is easy to misread; if it isn't, the timing instrumentation may be worth a look. Either way we've excluded those scenes rather than publish numbers we can't stand behind. Their trace_mean values are still used in the analysis below, since trace is measured on the GPU timer and is unaffected.

What drives trace cost: emitters, not geometry

The cleanest pair in the dataset, where triangle count runs the wrong direction:

khronos-metal-rough   501,778 triangles,        0 emitters  ->  0.88 ms
glb-asset              15,838 triangles,   15,452 emitters  ->  1.95 ms

32× fewer triangles, 2.2× the trace cost. glb-asset is the DamagedHelmet test asset; 15,452 is the GLB's exact triangle count, verified against the file's index accessor, and its single material is genuinely emissive (emissiveFactor [1,1,1] plus an emissive texture), so the renderer samples the whole mesh as light.

The healthy large scenes scale the same way:

kabukicho-district-row   12.27 M triangles,  112,854 emitters  ->  8.94 ms
zero-day                  5.87 M triangles,   10,103 emitters  ->  3.37 ms

2.1× the triangles, 11× the emitters, 2.65× the cost.

Across all 22 scenes, with emitter counts from a CPU-only stats mode (PR feat/stats-subcommand — the world builds in the embedded runtime before anything touches a device, so every scene has counts):

• pairwise: trace vs emitters Pearson r = +0.94, Spearman ρ = +0.90; trace vs triangles r = +0.78, ρ = +0.77
• the predictors are collinear (r = +0.69 — large scenes have more of everything), so neither pairwise correlation separates them
• controlling for that: partial r(trace, emitters | triangles) = +0.88; partial r(trace, triangles | emitters) = +0.53
• two-predictor OLS on logs, R² = 0.91 (statsmodels): standardized β = +0.76 for emitters (t = 8.10, p = 1.4e-07) and +0.26 for triangles (t = 2.75, p = 0.013)

Robustness. The set contains two duplicate-geometry pairs — zero-day-animated is byte-identical to zero-day on both predictors (5,869,892 tris / 10,103 emitters), and mannequin-portrait shares geometry with mannequin at zero emitters each — plus one pathological scene (below). Re-fitting three ways:

Nothing moves. Emitters survive controlling for geometry; triangles survive at about a third the weight. At n = 22 this is suggestive, not conclusive.

The categorical split is the sturdiest part: all 14 scenes with 24+ emitters trace in 1.00 ms or more, and all six zero-emitter scenes in 0.88 ms or less. That includes instancing, whose 768 k triangles are 1,000 copies of an 864-triangle mesh — the BVH holds the base mesh plus transforms, so it is not a unique-geometry-scale test. The two 2-emitter scenes (cornell-box 0.38 ms, light-room 0.44 ms) sit inside the zero-emitter band; two lights don't cost anything yet.

Near-black emissive materials appear to carry full emitter cost

The glb-asset figure is more than an outlier — it points at how emitter cost is attributed. The DamagedHelmet's emissive texture is ~99 % black (mean luminance 0.0033; 98.8 % of texels below 0.05). The helmet emits almost nothing, yet the engine pays full emitter cost on all 15,452 of its triangles. Tracing where the texture enters the chain:

• CDF proposal — weight per emitter triangle is area × luminance(emissiveFactor) × object power (emitter_power, lib.rs:127) — the factor, not the texture. [1,1,1] is full weight.
• Live cull — spatial only: EmitterCull { radius, far, dir, cos } (lib.rs:163) — a 60 m radius plus a 2×-radius view cone with a (d0/d)² falloff, d0 = 10 m (live/mod.rs:439-447). No field in the cull or the power path is a radiance threshold.
• RIS resampling — sample_emitter_ris reweights its six CDF candidates by a geometric target (emitter cosine × the receiving surface's BSDF × 1/d²). The texture does not enter here.
• NEE — the texture first appears here, and only for the RIS winner: emitter_radiance (pathtrace.wgsl:1672) → emission (:1026) multiplies emissiveFactor × srgb_to_linear(texture) (a coarse 5 cm mip). The six-candidate RIS loop above it is purely geometric — its target is the receiver's BSDF, no emitter texture. In the NEE consumer (:1856-1864) the only gates before the visibility ray are es.pdf_w > 0 (the proposal pdf — power/area/geometry, not radiance) and the receiving BSDF. There is no near-zero-radiance early-out, so occluded_emitter — the shadow ray — fires. A near-black emitter is proposed at full rate, NEE-evaluated at full rate (texture fetch, radiance, and the visibility ray), MIS-weighted, and contributes ~0.

So the wasted work is the full NEE path — the visibility ray included, not just a texture fetch — not merely candidate generation. Beyond the traversal cost, this misallocates importance sampling: samples sent to a black texel are samples not spent on an actual light.

The honest distinction: MATERIAL_FUNCTIONS.md documents this split as intended — "the renderer samples emitters by their base emissive, while the function does the actual emission." That is deliberate for library materials with a glow/intensity parameter, where the factor is the brightness. DamagedHelmet is not a library material — it's a plain imported glTF, where emissiveFactor [1,1,1] is a texture multiplier (the glTF default), not a brightness spec, and the texture carries the actual brightness. So the smaller, fairer question is: is proposal-by-factor intended for glTF imports, where the factor is a multiplier and a mostly-black emissive map is the common case? If not, a material-level effective-luminance term in emitter_power (factor × mean texture luminance) looks like it would be cheap for exactly these scenes.

kabukicho is a separate pathology

It completes 196 frames in 60 s (3.3 fps) with gpu_max 123.23 ms against a 15.41 ms mean — the only scene that never settles into a steady rate. Its 11.12 ms trace sits above everything else in the set, but its district variant has 9.4× the triangles (37.75 M) and 4.8× the emitters (375,688) and traces faster at 9.46 ms, while kabukicho-district-row (12.27 M tris, 112,854 emitters) sits at 8.94 ms. The healthy variants scale sensibly against each other; only this one is out of line, so its timing is untrustworthy and it's kept out of the analysis above.

It reports 2674 objects and 475 ms setup. Happy to share the frame log or dig further.

Our numbers against theirs

The point is portability, not a speed contest: the engine's own 60 fps / 16.7 ms frame budget holds on a second, non-Apple hardware platform — consumer NVIDIA Vulkan with HWRT, full 1280×720, no dynamic resolution — for scenes up to 37.75 M triangles and 375 k emitters. Their published figures are on an Apple M5 (a MacBook Pro laptop SoC, laptop-class power); ours are on a 350 W discrete desktop RTX 3090. The two hardware classes aren't comparable, and most of their live numbers are at a lower internal resolution (0.5 floor) than ours, so the tables below are context, not a benchmark.

Their published real-time figures (M5):

Ours (RTX 3090, full 1280×720, GPU otherwise idle):

The only same-scene, like-for-like rows are Zero Day and glb-asset; on both the 3090 runs roughly 2.7× faster than the M5 at equal or higher resolution. That is the expected direction for a 350 W desktop card over a laptop SoC — reported for completeness, not as a result.

Offline renders (different pipeline)

For completeness, the still-image path also works — render ... --spp 32, cinematic preset, atrous denoise. These are whole-image render times in the hundreds of ms and are not comparable to the real-time figures above:

Image quality checks out: cornell-box shows correct GI and colour bleed; neon-reflections' 288 emissive bars render clean, no banding or fireflies, coherent glossy-floor and metal reflections.

Also measured on a second consumer card (RTX 3060, 12 GB)

Same source build, hwrt:true over Vulkan. 14 of 22 scenes fit alongside a ~9.2 GB diffusion workload (renderer peak +0.8–1.6 GB); the 8 heaviest OOM. serve mode: cold job 248 ms GPU init, warm jobs 0 ms — device and game runtimes stay resident between stdin jobs.

render --signals PREFIX writes PREFIX-{diffuse,specular,emission}.raw, each width × height × 3 × 4 bytes (11,059,200 at 1280×720), linear RGB f32 interleaved. Useful as a structural prior for diffusion workloads — light transport instead of a depth map.

Asset fetch on a clean Linux setup

A clean clone leaves 14 of 22 shipped scenes unrunnable, six of them from a single macOS font path that aborts setup.ts before later fetchers run. Filed separately with the full gap table, plus PRs for the two fixable gaps.

Not claimed

• The ΔE comparisons in docs/COMPARE.md — Mac-only data, not reproduced here.
• Real-time figures for the thirteen excluded scenes, for the reason above.
• A verified moving-camera measurement. live is headless; the motion in zero-day-animated comes from its frame script.

Offer

Happy to re-run any of this, add scenes, test other NVIDIA hardware, or share raw data — the sweep is a single script and the frame logs are JSON-lines, so the full per-frame data is easy to hand over if it's more useful than the summaries.