fix(vulkan): clear startup validation errors on native triangle #6

Merged
catbot merged 1 commit from claude/issue-5 into master 2026-05-31 22:59:48 +02:00
Member

Summary

Fixes the two Vulkan validation errors that fired on startup of the native Vulkan examples, reported in #5.

1. Device layers (enabledLayerCount must be 0)

Device::Initialize enumerated device layers and, if found, passed VK_LAYER_KHRONOS_validation to vkCreateDevice. Device layers have been deprecated and ignored since Vulkan 1.0 — passing them violates VUID-VkDeviceCreateInfo-enabledLayerCount-12384. The enumeration/match block is removed and enabledLayerCount is pinned to 0. Layers are still enabled at the instance level (unchanged).

2. Layout transition on an unacquired presentable image

StartInit() and RecreateSwapchainAndImages() eagerly transitioned every swapchain image UNDEFINED → PRESENT_SRC_KHR on a submit issued before any vkAcquireNextImageKHR. A presentable image may only be touched after it is acquired, so this tripped vkQueueSubmit(): ... layout transition on presentable VkImage ... but the image has not been acquired.

Those pre-transitions are removed. Each image's first layout transition now happens lazily in Render(), after acquire, from UNDEFINED; every subsequent frame transitions from PRESENT_SRC_KHR. A per-image imageInitialised flag (reset in CreateSwapchain()) picks the correct oldLayout. Using UNDEFINED on first use is correct because a freshly-acquired swapchain image's contents are undefined anyway.

Testing

Ran under a headless sway compositor (GPU renderer) with VK_LAYER_KHRONOS_validation enabled.

  • Before (original code): HelloUI reproduces both issue errors — enabledLayerCount is 1 (not zero) / Device Layers have never worked, and repeated layout transition on presentable VkImage ... has not been acquired (once per swapchain, including on recreation).
  • After (this PR): zero validation messages across initial render and swapchain recreation. Confirmed on both HelloUI (compute UI passes) and the VulkanTriangle example named in the issue — the two reported error signatures are gone.

There is no crafter-build test suite (No tests matched), so verification was by exercising the app directly under the validation layer.

Resolves #5

🤖 Generated with Claude Code

## Summary Fixes the two Vulkan validation errors that fired on startup of the native Vulkan examples, reported in #5. ### 1. Device layers (`enabledLayerCount` must be 0) `Device::Initialize` enumerated device layers and, if found, passed `VK_LAYER_KHRONOS_validation` to `vkCreateDevice`. Device layers have been deprecated and ignored since Vulkan 1.0 — passing them violates `VUID-VkDeviceCreateInfo-enabledLayerCount-12384`. The enumeration/match block is removed and `enabledLayerCount` is pinned to `0`. Layers are still enabled at the instance level (unchanged). ### 2. Layout transition on an unacquired presentable image `StartInit()` and `RecreateSwapchainAndImages()` eagerly transitioned **every** swapchain image `UNDEFINED → PRESENT_SRC_KHR` on a submit issued *before* any `vkAcquireNextImageKHR`. A presentable image may only be touched after it is acquired, so this tripped `vkQueueSubmit(): ... layout transition on presentable VkImage ... but the image has not been acquired`. Those pre-transitions are removed. Each image's first layout transition now happens lazily in `Render()`, **after** acquire, from `UNDEFINED`; every subsequent frame transitions from `PRESENT_SRC_KHR`. A per-image `imageInitialised` flag (reset in `CreateSwapchain()`) picks the correct `oldLayout`. Using `UNDEFINED` on first use is correct because a freshly-acquired swapchain image's contents are undefined anyway. ## Testing Ran under a headless `sway` compositor (GPU renderer) with `VK_LAYER_KHRONOS_validation` enabled. - **Before (original code):** HelloUI reproduces both issue errors — `enabledLayerCount is 1 (not zero)` / `Device Layers have never worked`, and repeated `layout transition on presentable VkImage ... has not been acquired` (once per swapchain, including on recreation). - **After (this PR):** zero validation messages across initial render and swapchain recreation. Confirmed on both HelloUI (compute UI passes) and the `VulkanTriangle` example named in the issue — the two reported error signatures are gone. There is no `crafter-build test` suite (`No tests matched`), so verification was by exercising the app directly under the validation layer. Resolves #5 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Two Vulkan validation errors fired on startup of every native (Vulkan)
example, reported in #5:

1. vkCreateDevice enabledLayerCount != 0. Device layers are deprecated
   and ignored since Vulkan 1.0; passing them is a spec violation
   (VUID-VkDeviceCreateInfo-enabledLayerCount-12384). The device-layer
   enumeration/match block in Device::Initialize is removed and
   enabledLayerCount is pinned to 0 — layers are enabled at the instance
   only.

2. vkQueueSubmit layout transition on a presentable image that "has not
   been acquired". StartInit() and RecreateSwapchainAndImages() eagerly
   transitioned every swapchain image UNDEFINED -> PRESENT_SRC_KHR before
   any vkAcquireNextImageKHR, which the spec forbids (a presentable image
   may only be touched after acquire). Those pre-transitions are removed.
   Each image's first layout transition now happens lazily in Render(),
   after acquire, from UNDEFINED; subsequent frames transition from
   PRESENT_SRC_KHR. A per-image `imageInitialised` flag (reset in
   CreateSwapchain) selects the correct oldLayout.

Verified under sway (headless, GPU renderer) + VK_LAYER_KHRONOS_validation:
the original code reproduces both errors on HelloUI; the fixed build emits
zero validation messages across initial render and swapchain recreation.

Resolves #5

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
catbot merged commit 26a41ac528 into master 2026-05-31 22:59:48 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Catcrafts/Crafter.Graphics!6
No description provided.