docs: Android VK extension survey for pre-Lume-Pad bring-up#349
Open
leaiss wants to merge 1 commit into
Open
Conversation
leaiss
force-pushed
the
ci/android-emulator-smoke-test
branch
from
0358093 to
e390c66
Compare
leaiss
force-pushed
the
docs/android-vk-extension-survey
branch
3 times, most recently
from
df89261 to
58a19dc
Compare
Inventories every Vulkan device extension the runtime requests at
xrCreateVulkanDeviceKHR on Android (from oxr_vulkan.c with the
AHardwareBuffer + FD-sync platform flags). Cross-references each
against:
- what swiftshader/gfxstream provides on the emulator (observed via
today's smoke runs)
- what Adreno 6xx/7xx on Lume Pad is expected to provide (per
vulkan.gpuinfo.org reports for Snapdragon 845/888)
Predicts which xrCreate* call should advance past the emulator wall
on real hardware vs which steps will be the first hardware-specific
behavior. Includes a step-by-step expectation table for first
Lume Pad bring-up, mapping each log line to the emulator/Lume Pad
expected outcomes.
Key prediction: extensions #6 (VK_ANDROID_external_memory_android_
hardware_buffer), #7 (VK_KHR_sampler_ycbcr_conversion), and #10
(VK_EXT_queue_family_foreign) are the three swiftshader doesn't
provide — all AHardwareBuffer-related — and all three are standard
on Adreno's Android Vulkan ICD. So Lume Pad should clear the
emulator wall at first device creation.
If the prediction is wrong, the doc's "How to update" section
points at the exact code change to make.
leaiss
force-pushed
the
docs/android-vk-extension-survey
branch
from
58a19dc to
2b8ba7d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stacked on PR #347. New doc at
docs/getting-started/android-vulkan-extension-survey.md— a pre-Lume-Pad reference that inventories every VK device extension the runtime requests on Android, predicts which ones swiftshader (emulator) vs Adreno (Lume Pad) provides, and gives a step-by-step expectation table for first hardware bring-up.Why
Today's emulator runs hit
VK_ERROR_EXTENSION_NOT_PRESENTat bothnull_compositor::vk_create_deviceANDxrCreateVulkanDeviceKHR. The questions everyone will ask on Lume Pad day-1 are:xrCreate*step is expected to be the first hardware-specific behavior?This doc answers all three in advance.
Key prediction
Three of the runtime's required extensions are AHardwareBuffer-related — swiftshader doesn't implement them, but they're standard on Adreno's Android Vulkan ICD. So Lume Pad should clear the emulator wall at first VkDevice creation without any code change. If it doesn't, the doc names the exact
oxr_vulkan.cline to edit (move the missing extension from required to optional).Stacking
Based on PR #347 (sentinel + smoke script). Rebase onto main after #347 lands.
Test plan
scripts/android-smoketest.shand walk through the step-by-step expectation table.🤖 Generated with Claude Code