diff --git a/docs/RUST.md b/docs/RUST.md
index 4efa412..6feaaff 100644
--- a/docs/RUST.md
+++ b/docs/RUST.md
@@ -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