Vulkan Validation Layers: Balancing Performance Overhead vs Accessibility in Release Builds

Goal

Determine whether Vulkan Validation Layers should remain enabled in release builds for accessibility‑focused user workflows, while keeping frame‑time impact acceptable.

Constraints & Uncertainty

Enabling VK_LAYER_KHRONOS_validation introduces command‑buffer overhead, measurable in high‑draw applications. The default debug messenger severity levels differ across SDK releases, leading to inconsistent diagnostic visibility. There is no consensus on whether shipping layers in production offers sufficient accessibility benefits to justify the latency penalty.

Questions

• What measurable frame‑time increase does VK_LAYER_KHRONOS_validation cause in typical accessibility‑heavy workloads?
• Can a configurable severity filter or throttling mechanism provide enough diagnostics without the full overhead?
• Is there a documented best practice for shipping validation layers in release builds aimed at accessibility tools?