docs: what the emulator actually gives a GPU app, measured in the guest

`gpu-probe` cross-compiled with cargo-ndk and run inside a default
`emu up`: the guest's GL adapter is the host's real RX 7900 XT through
virgl, reporting OpenGL ES 3.1 with compute shaders, 1024 invocations per
workgroup and 64 KB of workgroup storage -- the same numbers the desktop
gets. `Backends::PRIMARY` still finds nothing, because the guest's only
Vulkan is SwiftShader.

So GPU acceleration in the emulator is not a thing to get working; it is
the default, and it is GLES. What is missing is GPU-accelerated Vulkan,
and the Venus retry on mesa 26.2.2 fails exactly as it did on 26.1.7 with
no newer emulator package to try.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
irisandClaude Opus 5 committed 2026-09-08 13:04:15 -04:00
1 parent db0a41a7cd
commit af7d5f3782
1 file changed
+53 -5
+53 -5
View File
@@ -7548,12 +7548,15 @@ back to, not the preferred one. Measured here:
|---|---|---|---| |---|---|---|---|
| `Vulkan` Virtio-GPU Venus (RX 7900 XT) | yes | 1024 | 64 KB | | `Vulkan` Virtio-GPU Venus (RX 7900 XT) | yes | 1024 | 64 KB |
| `Gl` virgl (RX 7900 XT, radeonsi) | yes | 1024 | 64 KB | | `Gl` virgl (RX 7900 XT, radeonsi) | yes | 1024 | 64 KB |
| `Gl` in the emulator, virgl through gfxstream (ES 3.1) | yes | 1024 | 64 KB |
So **the GL fallback on this VM already has compute** (virgl reports ES So **the GL fallback already has compute everywhere it is measurable**
3.2). The only no-compute machine in this project is the Android -- virgl reports ES 3.2 on the desktop and ES 3.1 inside the emulator
emulator's **SwiftShader software GL** at `EMU_GPU=software`, which (measured in the guest, "What the emulator gives a GPU app" below). The
reports ES 3.0 -- a software rasteriser used for one test configuration, only no-compute machine in this project is the emulator's **SwiftShader
not a device anything ships to. The phone has Vulkan. software GL** at `EMU_GPU=software`, which reports ES 3.0 -- a software
rasteriser used for one test configuration, not a device anything ships
to. The phone has Vulkan.
**DRM native context would not change any of this**, which is the answer **DRM native context would not change any of this**, which is the answer
to "would enabling drm without full passthrough get us to 3.1": it is to "would enabling drm without full passthrough get us to 3.1": it is
@@ -7658,6 +7661,51 @@ render-pass rewrite crashed identically. The 2026-09-05 "no compute"
finding is about the **Android emulator's SwiftShader GL path** reporting finding is about the **Android emulator's SwiftShader GL path** reporting
ES 3.0 -- a different machine entirely. ES 3.0 -- a different machine entirely.
### What the emulator gives a GPU app, measured in the guest (2026-09-08)
Asked directly rather than inferred from the host's flags: `gpu-probe`
cross-compiled with `cargo ndk -t x86_64 -P 26`, pushed to
`/data/local/tmp` and run inside a default `emu up` (which is `-gpu host
-feature -Vulkan` on a headless Xwayland).
$ adb shell WGPU_BACKEND=gl /data/local/tmp/gpu-probe
adapters: 1
Gl Android Emulator OpenGL ES Translator (virgl (AMD Radeon RX 7900 XT
(radeonsi, navi31, ACO, DRM 3....))
compute shaders: true (shader model Sm5)
max compute invocations/workgroup: 1024, workgroup storage: 65536 bytes
driver: OpenGL ES 3.1 (4.6 (Core Profile) Mesa 26.2.2-arch1.1)
IRIS DEVICE: ok
$ adb shell /data/local/tmp/gpu-probe # Backends::PRIMARY
adapters: 0
NO ADAPTER
So, in one place, because these three keep being confused:
- **GPU acceleration in the emulator already works, through GLES.** The
guest's GL is the host's real RX 7900 XT via virgl, and that is the
default `emu up`, not an opt-in. iris's `force-gles` build measures on
real hardware here.
- **It is ES 3.1 and it has compute shaders**, 1024 invocations per
workgroup and 64 KB of workgroup storage -- the same numbers the desktop
gets. The ES 3.0 "no compute" finding is **only** `EMU_GPU=software`,
SwiftShader's software GL.
- **There is still no GPU-accelerated Vulkan in the guest**, which is why
`Backends::PRIMARY` finds nothing. The guest's only Vulkan is
SwiftShader, i.e. software.
**Venus retried on Mesa 26.2.2 (2026-09-08): same fatal error**, exactly
as on 26.1.7 -- `Could not find support info for format:
VK_FORMAT_R8G8B8A8_UNORM`, `Failed to setup memory type index test
ColorBuffer`, `Failed to find memory type for ColorBuffers`, and the
emulator dies before adb sees it. The emulator package is unchanged at
**37.1.11** (`sdkmanager --list` offers no newer one) and its
`libgfxstream_backend.so` still has only `OpaqueFd`, `Metal` and `none`
as external-memory modes, so there is nothing to switch to. The retry
costs one boot; do it again when either the emulator package or Mesa
moves.
### Vulkan in the emulator (measured 2026-09-04) ### Vulkan in the emulator (measured 2026-09-04)
**Settled 2026-09-04: the guest gets Vulkan from SwiftShader, and the **Settled 2026-09-04: the guest gets Vulkan from SwiftShader, and the