| Filename | Latest commit message | Latest commit date |
|---|---|---|
Device
- Device::Initialize(required, optional) takes DeviceFeatures, the five
core feature structs vulkan10 to vulkan14. The library enables only what
its own shaders and code use. Device::enabledFeatures says what was
enabled, supportedFeatures what the GPU has, apiVersion the version in
use.
- shaderInt16, shaderFloat16, storageBuffer16BitAccess, scalarBlockLayout
and the uniform-buffer, storage-buffer and storage-image non-uniform
indexing bits are no longer enabled for everyone. An application whose
shaders take uint16_t spec constants passes
{.vulkan10 = {.shaderInt16 = VK_TRUE}}. scalarBlockLayout stays on with
the NVIDIA workaround, whose TLAS address may sit in a struct's tail
padding.
- Every GPU is weighed before one is chosen: Vulkan 1.3, the swapchain and,
below 1.4, maintenance5 extensions, the library's needs, the required
features. One that can't run the application is skipped, saying why when
it ranks higher. A CPU device runs it only when nothing else is listed,
and CRAFTER_GRAPHICS_DEVICE never falls back. A GPU two drivers both list
is tried through each.
- When no GPU qualifies, Initialize throws naming each GPU's gaps. It
destroys the instance it made, before any Wayland connection, so it can
be called again asking for less.
- maintenance5 is vulkan14's on a 1.4 GPU and VK_KHR_maintenance5's below.
CRAFTER_GRAPHICS_NO_VULKAN_1_4 runs as a 1.3 application, to exercise
that path on a 1.4 GPU.
- VK_KHR_spirv_1_4 and VK_KHR_shader_float_controls, core since 1.2, are no
longer enabled, nor VK_EXT_shader_atomic_float, which was enabled without
its feature struct. memoryDecompression's feature bit is queried before
it is enabled.
Shaders
- VulkanShader checks a module's capabilities, declared directly or
implicitly, against the enabled core features, the GPU's subgroup
operations and the optional groups, and throws naming the field to pass,
or saying the GPU lacks it. The tables are generated from vk.xml and
SPIR-V's grammar.
- WorkaroundNvidiaAS::Patch sized a row-major matrix push member by its
columns, so the TLAS address could land inside it.
Window
- The swapchain format is one whose own feature flags allow storage reads
and writes without a format, which since Vulkan 1.3 each format says for
itself; shaderStorageImageRead/WriteWithoutFormat are no longer required.
Tests
- DeviceFeatures: ResolveFeatures, ChooseDevice and CheckShaderCapabilities,
without a GPU.
- FeatureRequests: required and optional features end to end, the 1.3
path, and a retry after a refusal.
- PushConstantRewrite: a row-major mat3x4 push member.
- HeapASRead, HeapDynamicIndexHit, RTPassPushData and the ray-tracing
examples ask for the features their shaders use.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
||
| .. | ||
| closesthit.glsl | ||
| closesthit.wgsl | ||
| main.cpp | ||
| miss.glsl | ||
| miss.wgsl | ||
| project.cpp | ||
| raygen.glsl | ||
| raygen.wgsl | ||
| README.md | ||
| resolve.wgsl | ||
Sponza example
Loads the Sponza atrium as a .cmesh + one albedo .ctex and renders
it via ray tracing on both Vulkan (native) and WebGPU (wasm). Same
main.cpp, #ifdef CRAFTER_GRAPHICS_WINDOW_DOM selects the backend.
What this example proves
.cmeshand.ctexdecompression round-trip on both backends (GPU viaVK_EXT_memory_decompressionon Vulkan, CPU viaCompression::DecompressCPUon WebGPU).- A single texture binding flowing from
Image2D<RGBA8>through the RT pipeline's closest-hit on both backends. The closest-hit samples at the barycentric attribs as UVs — proof-of-binding, not visually accurate. Per-vertex UV interpolation is the next step.
The closest-hit reads its texture through a spec constant
(albedo[albedoSlot]), not a runtime index. That is deliberate — see
below.
Native RT limitation: dynamic descriptor_heap indexing in hit shaders
Fixed in NVIDIA 615.78.08: tests/HeapDynamicIndexHit selects buffers and
textures with a runtime index in a closest-hit, including different
descriptors in neighbouring lanes of a wave. This example still uses the
spec-constant pattern below, which also runs on the older drivers.
On NVIDIA driver 610.43.02 (Vulkan 1.4), indexing a
layout(descriptor_heap) array with a runtime (non-constant) index
inside a ray-tracing hit shader aborts the device with
VK_ERROR_DEVICE_LOST (an instruction-pointer / READ_INVALID
device-fault) with validation off. GPU-Assisted Validation masks it —
the scene runs fine under GPU-AV — which is why a validated run doesn't
catch it. It is a driver-side fault, the same family as the
descriptor-heap AS-read fault (#7 / #15) and the RT recursion / compute
TLAS-push issues (#21 / #22), but here for plain SSBO and
sampled-image descriptors read with a non-constant heap index
(issue #23).
What was isolated (NVIDIA RTX 4090, driver 610.43.02)
Driving a native bindless RT scene headlessly and bisecting the closest-hit:
- A closest-hit that reads only
lightHeap[lightSlot]wherelightSlotis a spec constant survives indefinitely. ✅ (This example'salbedo[albedoSlot]is exactly this case.) - Reading
indexHeap[assetIndexStart + gl_InstanceCustomIndexEXT]/vertexHeap[...]— a heap index offset by a runtime value — device-losts on the first geometry hit. ❌ - Reading a texture dynamically,
textureHeap[assetColorStart + gl_InstanceCustomIndexEXT], also device-losts. ❌ So it is SSBO and sampled-image descriptors. nonuniformEXT()on the dynamic index does not help.- The identical dynamic-heap-index pattern works fine in fragment
shaders (the UI renderer indexes
uiTextures[]/ui*Heap[]by per-item runtime slots), so this is RT-stage-specific, not a generaldescriptor_heapproblem. - Reading a spec-constant-indexed SSBO in raygen works; only the dynamic index in the hit stage faults.
Why there is no transparent engine workaround
The AS-read fault (#15) is worked around transparently because an
acceleration structure can be reached two ways: through a descriptor, or
through its device address via
OpConvertUToAccelerationStructureKHR (which reads no descriptor). There
is exactly one TLAS, so the engine rewrites the heap AS read into an
address load and feeds the address in as push data.
Neither half of that applies here:
- Sampled images have no device-address path. A texture must be
reached through a descriptor; there is no
OpConvertUToImage. A dynamic heap texture index cannot be rewritten into anything that avoids dynamic descriptor selection. - There are many buffers, dynamically selected. SSBOs can be
reached by address (
buffer_reference/OpConvertUToPtr), but a per-mesh array selected bygl_InstanceCustomIndexEXTwould need the engine to maintain and bind an address-table buffer and a SPIR-V rewrite far larger than the single-TLAS AS case — and it would still leave the texture half broken.
So the engine cannot paper over this the way it does the AS read. The fix is on the consumer side: avoid dynamically selecting a descriptor in a hit shader.
Recommended pattern
The fault is dynamic selection of a descriptor. Indexing within a single bound resource — an element offset into one SSBO, a layer into one array texture — is ordinary memory / layer addressing and is unaffected. So bind one resource and index inside it, rather than indexing the heap:
-
Geometry — pack all meshes' vertices/indices into a single SSBO bound at a spec-constant slot and index it by a runtime element offset, or reach each mesh's buffer via
buffer_reference(a device address loaded from one bound table). Either way the descriptor is constant; only the offset/address is dynamic.// ❌ faults in a hit shader on NVIDIA: dynamic descriptor selection layout(descriptor_heap) buffer Verts { Vertex v[]; } vertexHeap[]; Vertex vtx = vertexHeap[assetVertexStart + gl_InstanceCustomIndexEXT].v[i]; // ✅ one descriptor (spec-constant slot), dynamic element offset layout(constant_id = 0) const uint16_t vertexSlot = 0us; layout(descriptor_heap) buffer Verts { Vertex v[]; } vertexHeap[]; uint base = assetVertexStart[gl_InstanceCustomIndexEXT]; // from a bound SSBO Vertex vtx = vertexHeap[vertexSlot].v[base + i]; -
Materials / textures — put them in one
texture2DArray(or a small number of arrays bucketed by format/size) bound at a spec-constant slot and index by layer:// ✅ one array texture (spec-constant slot), dynamic layer index layout(constant_id = 1) const uint16_t materialArraySlot = 0us; layout(descriptor_heap) uniform sampler2DArray materials[]; uint layer = materialLayer[gl_InstanceCustomIndexEXT]; // from a bound SSBO vec3 albedo = texture(materials[materialArraySlot], vec3(uv, layer)).rgb;
This is precisely what the WebGPU path already does — bucketed texture arrays plus a single geometry buffer — so it is a proven, cross-backend pattern, and it sidesteps the NVIDIA RT fault on the native path.
Asset fetch
project.cpp calls Crafter::GitFetch(...) on
https://github.com/jimmiebergmann/Sponza
(pinned to commit 222338979d32f4f4818466291bdbc29f192b86ba). The
clone lands in the per-user crafter-build cache; first build pulls
~280 MB once, subsequent builds reuse it.
cfg.assets then picks two files out of that clone:
| Source | Compressed output |
|---|---|
sponza.obj |
sponza.cmesh |
textures/sponza_arch_diff.tga |
sponza_arch_diff.ctex |
Both land flat in the example's bin directory.
Building
crafter build # native Vulkan
crafter build --target=wasm32-wasip1 # WebGPU / wasm
License & attribution
Sponza geometry, materials, and textures are licensed under CC BY 3.0.
- Original model: Frank Meinl, Crytek (2010).
- OBJ packaging / cleanup: Morgan McGuire, McGuire Computer Graphics Archive — https://casual-effects.com/data.
- GitHub mirror used here: Jimmie Bergmann's roof-material fixup — https://github.com/jimmiebergmann/Sponza.
When redistributing builds of this example that bundle the compressed
Sponza outputs (*.cmesh, *.ctex), the CC BY 3.0 attribution
requirement applies. Quoting the original credit somewhere visible to
end users (about-screen, credits page, etc.) is enough.
The Crafter.Graphics library code itself is LGPL-3.0; the two licenses are compatible for data + code distribution.