Qt 6.12 Beta Lands With LTS Status, Vulkan Device Fault Support, and XR Apps That Run on Flat AR Glasses

Qt 6.12 Beta 1 shipped on June 12, and unlike a lot of point releases, this one matters past the changelog. For paying commercial customers, 6.12 becomes the latest Long Term Support branch in the Qt6 series, which means the decisions baked into this beta are the ones a lot of shipping products will live with for years. The official release is targeted for around September 22.

{{IMAGE:2}}

The attention-grabbing line from the release is on the XR side: the Qt Quick 3D XR module can now be configured for a mono view configuration. In plain terms, an application written for stereoscopic headsets can now render a single view and run on flat 2D XR devices like augmented reality glasses. That is a meaningful shift. A pair of waveguide AR glasses is not a Quest. It typically has a single combined display path, far less GPU budget, and a thermal envelope measured in single-digit watts because it sits on your face. Letting one Qt Quick 3D XR codebase target both a full stereo HMD and a lightweight mono AR display means developers stop maintaining two render paths for two wildly different power profiles.

The parts that actually touch the GPU

If you measure things for a living, the QRhi changes are where the substance is. QRhi is Qt's Rendering Hardware Interface, the abstraction layer that sits between Qt Quick and the native graphics APIs (Vulkan, Metal, Direct3D, OpenGL). It is the piece that determines how efficiently Qt translates scene-graph work into actual GPU commands.

Two additions stand out:

• Indirect rendering support for QRhi. Indirect draw calls let the GPU pull draw parameters (vertex counts, instance counts, offsets) from a buffer instead of having the CPU specify them at submit time. This is the foundation of GPU-driven rendering. For scenes with large numbers of objects, it moves work off the CPU and reduces driver overhead, which is exactly the bottleneck you hit on lower-power SoCs and integrated graphics. On a homelab thin client or an ARM SBC driving a kiosk UI, CPU-side draw submission is often the thing eating your frame budget.
• Vulkan VK_EXT_device_fault support for QRhi. This is a diagnostic win. When a Vulkan device hits a fault (a GPU hang, a page fault, a lost device), VK_EXT_device_fault lets the application query structured information about what went wrong instead of just receiving VK_ERROR_DEVICE_LOST and shrugging. If you have ever tried to debug a GPU hang on a headless box over SSH, you know the value of getting an actual fault address and vendor-specific crash data back rather than a generic error code.

Here is roughly how those QRhi changes map across the targets people actually deploy on:

Feature	Primary benefit	Where it pays off
Indirect rendering	Lower CPU draw-call overhead, GPU-driven scenes	iGPU, ARM SBCs, thin clients
VK_EXT_device_fault	Structured GPU crash diagnostics	Headless / remote deployments, CI rigs
Mono XR view config	Single codebase for stereo + flat AR	AR glasses, low-power wearables

Canvas Painter graduates

The other notable maturity milestone is the Qt Canvas Painter module being promoted out of technology preview into a fully maintained and supported module. Canvas Painter can be used to render 2D graphics, and one of the called-out uses is rendering 2D graphs in combination with the Qt Graphs module. Moving from tech preview to supported is not a flashy change, but it is the difference between something you can prototype with and something you are allowed to ship and expect API stability on. For dashboards, telemetry displays, and the kind of always-on monitoring UI a lot of homelab and embedded builds depend on, a stable 2D rendering path with proper graphing support is worth more than most marquee features.

Rounding out the release are client-side request compression for Qt GRPC, which trims bandwidth on chatty RPC links, and a batch of general improvements to the Qt core code.

Build and testing recommendations

If you maintain a Qt application and you are anywhere near the commercial LTS train, this beta is the one to test against now rather than in September. The LTS designation means bug-compatibility expectations get strict fast once it ships, so the beta window is your cheapest chance to catch behavioral changes in QRhi or the scene graph.

A few practical notes for setting up a test rig:

• Validate the Vulkan backend specifically if you target Linux desktop or embedded. The device-fault and indirect-rendering work is Vulkan-path; an OpenGL fallback build will not exercise it. Confirm your driver actually advertises VK_EXT_device_fault (recent Mesa RADV and NVIDIA proprietary drivers do) before assuming you will get the structured crash data.
• If you deploy on low-power ARM hardware, profile draw-call CPU time before and after to see whether the indirect rendering path is reachable for your scene structure. The win only materializes if your rendering is draw-call bound rather than fragment-bound.
• Pull the work-in-progress release notes and the beta from the Qt blog and download page rather than waiting for distro packages, which will lag the beta significantly.

The shape of this release is consistent with where Qt has been heading for a couple of years now: less churn in the high-level QML surface, more substance in the rendering plumbing underneath. For people who care about where the watts and the frame time actually go, the QRhi work in 6.12 is the part worth your bench time, and the mono XR configuration is a quiet signal that Qt expects flat AR glasses to be a real deployment target rather than a demo curiosity.