From da0d13bdd27b064a210df00a2f475468eddec613 Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 4 Oct 2026 09:41:58 +0000 Subject: [PATCH] Record that Lepton's Vulkan driver cannot share buffers between devices The Capability Viewer inside Lepton shows no AHardwareBuffer, external memory fd, semaphore fd or fence fd extension, so the Quest backend's two-device eye handoff cannot present there; the eyes need to be copied on Dawn's own device bound to the session, as on Windows Vulkan. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_019HBRGKTE1GnN2ah8gcZKr3 --- docs/steam-frame.md | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/docs/steam-frame.md b/docs/steam-frame.md index 838d9d9..eb92dcf 100644 --- a/docs/steam-frame.md +++ b/docs/steam-frame.md @@ -11,8 +11,11 @@ document covers what differs. A native SteamOS ARM64 build is a separate, later piece of work: Linux has no OpenXR graphics backend yet (see [A native SteamOS build](#a-native-steamos-build)). -**Status: not yet run on a Steam Frame.** Everything below compiles and is unit-tested, but the -device checks at the end are still to do. +**Status: not yet run on a Steam Frame, and the Android backend as it stands cannot present under +Lepton**: Lepton's Vulkan driver has no external memory or sync fd extensions, which the Quest +backend's two-device design needs (see [What the Frame reported](#what-the-frame-reported)). The +flavour, controller, refresh rate and foveation work below stays valid; the eye handoff has to move +to a single shared device first. ## What the flavour changes @@ -172,9 +175,17 @@ What follows from them: - **Foveation.** The host's Turnip has density maps for non-subsampled images through dynamic rendering, what the Dawn patch needs, and both density map offset extensions, which would let eye-tracked foveation shift one map instead of switching maps. -- **Open:** whether Lepton's Android build of Turnip also imports AHardwareBuffers. `cmd gpu - vkjson` from the shell lists only instance extensions there (its device entry comes back empty), - and Mesa's binaries carry every extension name, so it takes an app inside Lepton to tell. +- **No buffer sharing between devices in Lepton.** The Vulkan Hardware Capability Viewer (4.03, + the last release for Android 11), run inside Lepton, reports Turnip `26.2.99` (Vulkan 1.4.362, + display name "Valve Lepton") with `VK_EXT_fragment_density_map`, both density map offset + extensions, `VK_VALVE_fragment_density_map_layered`, `VK_KHR_timeline_semaphore` and the + maintenance extensions, but **no** `VK_ANDROID_external_memory_android_hardware_buffer`, + `VK_KHR_external_memory_fd`, `VK_KHR_external_semaphore_fd` or `VK_KHR_external_fence_fd`. The + Quest backend (`openxr_vulkan.cpp`) hands each eye from Dawn's device to its own OpenXR device + through exactly those, so it cannot present under Lepton. What can: binding Dawn's own device to + the session, as the Windows Vulkan backend (`openxr_vulkan_win32.cpp`) does, so the eyes are + copied into the swapchain on Dawn's queue with no sharing at all. That backend is also the core + of a native SteamOS build ([below](#a-native-steamos-build)). - **Finding the runtime.** An app inside Lepton reaches SteamVR's OpenXR runtime through the system runtime file, not a broker. The Khronos loader the game links statically (`DYNAMIC_LOADER OFF`) tries the runtime brokers first, then reads `/{product,odm,oem,vendor,system}/etc/openxr/1/active_runtime.json`,