Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Guest uploads into host-visible memory are slow when it is backed by NVIDIA's write-combined type (Windows/WHPX); a cached coherent type fixes it

Aperta
  • Qualcosa non va?
#198 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
computer-graphics, performance

Direzione di ricerca

Start at on_vkAllocateMemory, where the proposed change selects a cached host-visible type for eligible allocations. Reproduce the reported NVIDIA/Windows WHPX measurements, then check whether the behavior holds on other hosts and preserves imports, blobs, and image-dedicated allocations. Done means a justified upstream change or feature flag with benchmark results and platform limitations documented.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Setup

  • Android Emulator built from emu-main-dev (qemu + gfxstream), Windows 11 host with WHPX
  • Guest: Android 14 (API 34) x86_64 google_apis image with ndk_translation, 1280x720
  • Host GPU: NVIDIA GeForce RTX 4070 SUPER, driver 591.86
  • App: Honkai: Star Rail (Unity, arm64 through ndk_translation), with its Vulkan renderer and with GLES on the guest's ANGLE (-feature GuestAngle)

What we saw

In the open world the game's render thread (UnityGfxDeviceW) sits at 93–98% of a core while the host GPU is mostly idle. simpleperf on that thread shows 37% of the samples in a 64-byte ldp/stp copy loop that stores into a mapping of /dev/goldfish_address_space (Vulkan renderer); on ANGLE it is libc memcpy at 45%. The guest PAT entries for the address space BAR are write-back, so the guest mapping is not the cause.

The host-visible memory types on this host:

Index Flags
2 HOST_VISIBLE | HOST_COHERENT (system memory, write-combined)
3 HOST_VISIBLE | HOST_COHERENT | HOST_CACHED
4 DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT (ReBAR)

The game allocates its upload memory (about 160–176 MB) from the guest type that maps to host type 2. VulkanDisableCoherentMemoryAndEmulate does not help: the game only asks for HOST_VISIBLE and still lands on type 2. The added flushes made it slower: 52.0 → 45.1 fps at the same spot.

Experiment

The change is in on_vkAllocateMemory, about 30 lines. When the host type chosen for an allocation is host-visible but neither cached nor device-local, the allocation is made from a HOST_VISIBLE | HOST_COHERENT | HOST_CACHED type on the same heap instead. Imports, blobs and allocations dedicated to an image keep their type.

Measured at the same spawn point with the same camera:

Before After
Vulkan renderer: fps 60.9 61.9 (60 fps cap)
Vulkan renderer: render thread 93% 49.9%
Vulkan renderer: copy loop 37.3% of samples below 1.5%
ANGLE: fps 41.3–42.0 61.7 (cap)
ANGLE: render thread 98% 47.8%
ANGLE: libc memcpy 45% 5.9%

With the Vulkan renderer both runs are at the frame cap at this spot, so the gain there is render-thread headroom; in the open world the game feels smoother. Our builds have had the change on by default since 2026-10-01, with about 5 hours of scripted gameplay since and no emulator faults.

We have not worked out the effective memory type of these pages under WHPX, so we cannot say why write-combined system memory is this slow for the guest.

Questions

  1. Would you take this upstream, for example behind a feature flag? Or is there a reason to keep the write-combined type, such as the GPU's cost of reading snooped system memory, or other hosts?
  2. We have only tested NVIDIA on Windows. Should we check AMD, Intel or a Linux/KVM host before sending a PR?

I can send the patch as a PR if this looks useful.

This was investigated with AI assistance (Claude Code, Claude Opus 5.5). The measurements above were taken on my machine.

Lingua principale
C++
Stelle
62
Fork
41
Merge medio
1g 2h
PR unite (30g)
9

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di google/gfxstream

Tutte le issue di google/gfxstream

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.