| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
234fcce099
Window - CreateSwapchain asked for exactly numFrames (3) images whatever the surface said, read them into a three-element array, and keyed the command buffers, the fences and the descriptor-heap copy holding "its" swapchain image by the acquired image index. A swapchain of another size fell back to FIFO (asked for MAILBOX or IMMEDIATE) or threw, and a surface whose minimum is above three got a create info below it (#160). Mesa's MAILBOX needs four images: Turnip on phoc, llvmpipe on any Wayland compositor. - The present mode is picked first, then the swapchain is sized by SwapchainCapabilities: the surface's counts for that mode where the instance has surface_maintenance1. With swapchain_maintenance1 the swapchain names its mode (VkSwapchainPresentModesCreateInfoKHR), which is what makes the mode's own count the one that applies, at creation and to the forward progress of a UINT64_MAX acquire; without it the stricter of the mode's and the surface's counts for all modes. It asks for numFrames or that minimum where more, never past the maximum (SwapchainMinImageCount). Turnip's FIFO keeps its three images and MAILBOX gets four. The FIFO fallback and presentModeUnfit are gone. - images, imageViewInfos (was imageViews: they are create-infos), the made imageViews that descriptor sets take, imageInitialised and the render-finished semaphores are per image, as many as the driver made. The views are made once per swapchain. The semaphores only grow, since a present of the old swapchain may still wait on one. - Frames in flight stay numFrames, keyed by currentFrame, frameCounter % numFrames: the command buffer, the fence, the acquire semaphore, the heap copy (or set), RenderingElement3D::tlases, the frameIdx a pass is recorded with. currentImage is the acquired image. currentBuffer is gone, so code that used it stops compiling instead of picking the wrong one; RenderPass::Record's frameIdx keeps its name and is now the frame slot, as RenderPass.cppm says. - The frame's fence is waited before the acquire. The acquire semaphores need no spare then, and a frame waits for exactly the one numFrames before it, which the deletion queue and the staging rings count on and fences keyed by image did not promise once images come back out of order. The swapchain slots are written before the fence is reset. - From the acquire to the present the window is recording: a Resize or SetPresentMode from a listener (a VSync key ticked in onUpdate) takes effect after the present, through RebuildSwapchain, together with a present that found the swapchain out of date. Rebuilding mid-frame used to destroy the image the frame was drawing into; with images sized per swapchain it would also index past the new one's end. DescriptorHeapVulkan - Frames and images pair up differently from frame to frame, so no heap copy can keep one swapchain image. AddSwapchainSlot(slot, window) lists an image slot as that window's swapchain image, and Window::Render writes the image a frame acquired into its window's listed slots in that frame's copy, or its set, before onUpdate, skipping a slot that holds it already. A slot is one window's, so two windows can share a heap without writing each other's slots under each other's frames in flight. A slot listed during a frame its window records is written at once. A slot past the heap's image slots, an empty ImageSlot's 0xFFFF among them, is refused. Freeing a slot unlists it, as does initialising the heap in either binding model. WriteImageSet, the one use of which this replaces, is gone, and with it the per-frame dimension of setImageViews. Device - VK_KHR_surface_maintenance1 (or EXT) and VK_KHR_get_surface_capabilities2 are enabled where the loader has them (surfaceMaintenance1Supported, vkGetPhysicalDeviceSurfaceCapabilities2KHR), and the matching swapchain_maintenance1 with its feature where the device has it (swapchainMaintenance1Supported). - DistinctGpus groups the physical devices by GPU as CRAFTER_GRAPHICS_DEVICE numbers them, for ChooseGpu and tests. UI - UIRenderer lists its output slot instead of writing every copy itself, and again on every resize; the resize listener is gone on both backends. The headers' frameIdx is currentFrame. Examples - VulkanTriangle, Sponza, SponzaBench and RTVolume list their output slot and write only the per-frame TLASes. They wrote imageViews[f] into copy f once, which a resize left pointing at destroyed images. Tests - SwapchainImageCount: SwapchainMinImageCount on the numbers drivers report; every offered mode keeps its mode and gets what the window asks for; every frame presents the colour it drew, read back a texel per frame; a switch and a resize asked for during a frame wait for its present; a slot listed during a frame holds its image at once; two windows on one heap draw their own colours. The frame checks run again in child processes, through CRAFTER_GRAPHICS_DEVICE, on a GPU whose swapchains have more images than frames (this one, else llvmpipe), in each binding model the parent didn't cover; a child skips only for a GPU that can't run the library, and checks it runs the model it was asked for. - FrameLoopSync checks the frame slot follows the frame counter and counts the swapchain's own images. HeapASRead, HeapDynamicIndexHit and RTPassPushData list their swapchain slot and drop their resize rewrites. Docs - README, AGENTS.md and AGENTS.consumer.md: frames and images, the swapchain slots, rebuilds held to the present, the new optional groups. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
| .. | ||
| closesthit.glsl | ||
| main.cpp | ||
| miss.glsl | ||
| project.cpp | ||
| raygen.glsl | ||
| README.md | ||
| run-bench.sh | ||
SponzaBench — measuring the post-#40 performance work
This example exists to answer issue #155: starting with #40 a lot of performance-related issues were merged — what is the net performance gain, measured in a representative scene (Sponza)?
It is a headless benchmark harness built around the native Vulkan
Sponza ray-tracing scene. Same asset bundle and camera as
examples/Sponza, but instead of opening an interactive
window it times the work and prints machine-readable BENCH … lines, then
exits.
What it measures
- setup — process start through the first command submission: asset decompression, BLAS build per mesh group, the multi-instance TLAS, the RT pipeline, GPU memory placement and the descriptor writes. This is the window most of the post-#40 native perf work acts on.
- frames — a warmup followed by a measured loop calling
Window::Render(), reporting per-frame wall-clock stats and throughput.
Unlike the interactive Sponza example — which is single-material on native
because of the hit-shader dynamic-descriptor_heap-index driver fault, fixed
in NVIDIA 615.78.08 (see examples/Sponza/README.md) — SponzaBench's closest-hit shades from
barycentric coordinates and samples no texture, so it can build the
full multi-mesh atrium (25 mesh groups, ~262 k triangles) as one
multi-instance TLAS. The albedo is still decompressed and uploaded during
setup (to keep that path in the measurement) but is not bound.
Running
cd examples/SponzaBench
crafter-build # native Vulkan
# from the produced bin dir:
VK_LOADER_LAYERS_DISABLE='~all~' \
CRAFTER_PRESENT_IMMEDIATE=1 \
BENCH_WARMUP=200 BENCH_FRAMES=2000 BENCH_MESHES=25 ./SponzaBench
run-bench.sh <bindir> <label> <meshes> <reps> [--cold] runs it N times
and reports the median / min / max of each metric.
Environment knobs:
| var | effect |
|---|---|
CRAFTER_PRESENT_IMMEDIATE=1 |
uncapped present mode — without it FIFO pins frame time to the compositor's vblank (~60 Hz) and steady-state throughput can't be seen. |
VK_LOADER_LAYERS_DISABLE='~all~' |
disable the validation layer. The engine enables Khronos validation and GPU-assisted validation unconditionally; that adds large, version-dependent overhead and must be off for a representative measurement. |
BENCH_WARMUP / BENCH_FRAMES |
warmup and measured frame counts (default 200 / 2000). |
BENCH_MESHES |
cap on mesh groups loaded (default: all 25). A small cap shrinks GPU work so per-frame CPU cost dominates; the full scene is GPU-traversal bound. |
BENCH_CLEAN_EXIT=1 |
exit via std::exit (runs atexit, which writes the #69 pipeline cache) instead of the default hard _Exit. Used once to seed pipeline_cache.bin for a warm-cache measurement. |
Results — #40 vs current master
Measured on this repo's CI box: NVIDIA RTX 4090, driver 610.43.02,
1280×720, validation disabled, IMMEDIATE present, 200 warmup + 2000
measured frames, median of 9 runs. "#40" is commit 1451e3a (the #40
merge); "HEAD" is current master. The same SponzaBench sources were
built against each library revision (a git worktree at #40).
Full atrium — 25 meshes / ~262 k triangles (GPU-traversal bound)
| metric | #40 | HEAD | Δ |
|---|---|---|---|
| setup (cold) ms | 322.7 | 316.6 | −1.9 % |
| setup (warm pipeline cache, #69) ms | 322.7¹ | 313.9 | −2.7 % |
| throughput fps | 7 560 | 7 637 | +1.0 % |
| frame time p50 ms | 0.1311 | 0.1298 | −1.0 % |
| peak host RSS (cold) MB | 336.0 | 344.2 | +2.4 % |
| peak host RSS (warm cache) MB | 336.0¹ | 332.0 | −1.2 % |
¹ #40 predates the disk pipeline cache (#69), so its setup is always the cold-compile path.
Light scene — 1 mesh (deliberately CPU-bound)
| metric | #40 | HEAD | Δ |
|---|---|---|---|
| throughput fps | 15 022 | 15 237 | +1.4 % |
| frame time p50 ms | 0.0662 | 0.0650 | −1.8 % |
Interpretation
The net measured gain in a static Sponza RT scene is small: ~1–2 % faster frames, ~2–3 % faster setup, and roughly flat host memory. That is an honest result, and the reason is what Sponza exercises, not that the perf work was ineffective:
- Most post-#40 PRs don't touch this workload. The largest block is UI / text rendering (shaped-run cache, font-atlas dirty uploads, the UI compute-shader rewrites — #46–#57, #61, #122–#129, #132). Sponza has no UI, so those contribute zero. A second block optimises per-frame dynamic uploads (TLAS dirty-tracking #118, deforming-mesh refit #119, the staging ring #120). A static scene builds its TLAS once and never re-uploads, so these don't fire in steady state either. WebGPU-only (#130/#131/#133) and Win32-only (#134) PRs don't apply to a native Vulkan build at all.
- The PRs that do apply act on setup and memory, not frame time. Device-local placement (#65/#72/#73/#75), staging release (#66/#67/#114), the pipeline cache (#69) and the deferred-deletion queue (#101/#116) move setup cost and peak memory — which is exactly where the measured ~2–3 % setup change and the warm-cache RSS drop show up. The pipeline cache itself saves ~3 ms here (one RT pipeline) and, more visibly, ~12 MB of peak RSS by skipping the cold shader-compile allocations.
- Steady-state frame time is GPU-traversal bound. With 262 k triangles the per-frame CPU work (barrier scoping #48/#115, cached heap-bind structs #42/#43) is hidden behind GPU traversal, so it can't move the frame time. Shrinking the scene until it is CPU-bound (the light scene above) surfaces the per-frame CPU savings — and even then they are only ~1.8 %, because that CPU path was already cheap.
Takeaway: the post-#40 work is real but concentrated in UI/text and
per-frame dynamic-upload paths; a static, UI-less RT scene is the wrong
workload to see most of it. To quantify the UI/text gains a separate
benchmark over a text-heavy UIRenderer scene (or an animated/deforming
scene for the dynamic-upload PRs) would be needed.
Caveats / notes
- Numbers are CPU/GPU specific. Re-run
run-bench.shlocally for your hardware; the deltas between revisions are the point, not the absolute figures.