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:
1 parent
db0a41a7cd
commit
af7d5f3782
1 file changed
+53
-5
+53
-5
@@ -7548,12 +7548,15 @@ back to, not the preferred one. Measured here:
|
||||
|---|---|---|---|
|
||||
| `Vulkan` Virtio-GPU Venus (RX 7900 XT) | 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
|
||||
3.2). The only no-compute machine in this project is the Android
|
||||
emulator's **SwiftShader 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.
|
||||
So **the GL fallback already has compute everywhere it is measurable**
|
||||
-- virgl reports ES 3.2 on the desktop and ES 3.1 inside the emulator
|
||||
(measured in the guest, "What the emulator gives a GPU app" below). The
|
||||
only no-compute machine in this project is the emulator's **SwiftShader
|
||||
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
|
||||
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
|
||||
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)
|
||||
|
||||
**Settled 2026-09-04: the guest gets Vulkan from SwiftShader, and the
|
||||
|
||||
Reference in new issue
Block a user