high VRAM usage during gtk4 `gtk:compare vulkan lots-of-offscreens-nogl`

System information

• OS: Fedora Asahi Remix
• GPU: agx G13D
• Kernel version: 6.12.4-400.asahi.fc41.aarch64+16k
• Mesa version: Mesa 25.0.0-asahi20241211

Describe the issue

Several gtk vulkan tests show a high (single test 7-8GB on t6020) VRAM use. These tests have a command buffer with a command count of ~32768. This caused the related issue #47 (closed) in hk's queue_submit. Running the same tests with lavapipe doesn't use more than 850M.

steps for reproduction:

• apply mesa fixes (if applicable)
  • mesa/mesa!32822 (merged)
  • !310 (merged)
• build gtk 4.* with following fixes (if still applicable)
  • https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8058
  • https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8073
  • patch from https://gitlab.gnome.org/GNOME/gtk/-/issues/7146
• meson setup _builddir . && cd _builddir
• VK_DRIVER_FILES=/usr/share/vulkan/icd.d/asahi_icd.aarch64.jsonmeson test -j1 'gtk:compare vulkan lots-of-offscreens-nogl*'
• VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.aarch64.json meson test -j1 'gtk:compare vulkan lots-of-offscreens-nogl*'

assigned to @asahilina

marked this issue as related to #47 (closed)

comment from @alyssa

Hmm, wait. Let's assume each of those commands is nonempty
That means we have 32768 control streams and for perf reasons we allocate control streams in like 256KiB blocks or something
== 8GiB
so this doesn't really seem like a bug in the case of a pathological input
the better question is how we're ending up with 32768 control streams
My guess is over-barrier'ing causing us to split control streams wayyy too much which is the actual bug and probably responsible for at least some perf problems we have with honeykrisp