From 18e9cecf213962318bbf7d6b0a36536860564763 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 18:28:47 +0000 Subject: [PATCH] re: WITHDRAW "the freeze requires the rasterizer" -- the control was not controlled Driving the null backend blind, using the memory screen-id as the guide, to the SAME screen the rendered run froze on (screen 4): guest churn 19 of 8,089,600 bytes in 4 s (0.000%) Main XThread 0 ms CPU / 4 s, state S, wchan futex_do_wait log AllocRange unable ... 134217728 bytes; guest throw Frozen identically with no rasterizer at all. The flaw is the comparison, not the data. The earlier "control" measured the null-GPU run while it was still in the MENUS and the lavapipe run AT the freeze, then reported the difference as a backend effect. The allocations I cited as proof it had walked through the content load (114 -> 120) were menu-time allocations. A control needs both arms verified to be in the same state -- and the memory screen-id built this same session is exactly what makes that checkable, which I failed to use on the arm that mattered. Withdrawn: "the freeze requires the rasterizer", "the fault is in the host rendering path", and the hardware-Vulkan blocker that followed from it. The rendering question is no longer load-bearing. Survives: the freeze happens on the first content load after the main menu, on every route and BOTH GPU backends, with Main XThread futex-blocked at zero CPU rather than spinning; and four runs froze with three different allocation outcomes, so the 128 MB refusal is correlated but not necessary. Also survives and is independently verified: the memory screen-id navigation, now reproduced on a third run. It is what exposed this error. Open again: what is Main XThread waiting on? Identify the futex and its holder, carefully -- gdb perturbs this measurement. --- docs/re/BACKLOG.md | 10 +++++ docs/re/mission-freeze-heap-exhaustion.md | 52 +++++++++++++++++++++++ 2 files changed, 62 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 56f4905..7b555fe 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -6,6 +6,16 @@ unknown, what evidence exists, and what the first step would be. Move an item in --- +## 🔴 ~~BLOCKER — the mission freeze is a software-rendering hang~~ WITHDRAWN (2026-08-26) + +> **Withdrawn the same day.** Driving the null backend blind to the *same* screen +> shows it freezes identically — 0.000 % guest churn, `Main XThread` futex-blocked +> at 0 ms CPU, same 128 MB refusal and throw. The earlier control compared a +> null-GPU run still in the menus against a lavapipe run at the freeze, i.e. two +> different game states, and reported the difference as a backend effect. **The +> hardware-Vulkan blocker below does not apply** — rendering is not what is +> blocking this. The text is kept for the reasoning. + ## 🔴 BLOCKER — the mission freeze is a software-rendering hang (2026-08-26) The freeze that blocks every dynamic measurement is in the **host rendering diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md index 3f54d6f..8a5fb6e 100644 --- a/docs/re/mission-freeze-heap-exhaustion.md +++ b/docs/re/mission-freeze-heap-exhaustion.md @@ -999,3 +999,55 @@ by guest memory instead of by screen.** The menu state must be readable — the cleared-stage mask at `0x828F40C0` is already known and pokeable, so the menu layer keeps its state somewhere findable. A memory-driven `nav_to_flight` would make `--gpu=null` a complete oracle for every measurement on the backlog. + +--- + +# 🔴🔴 "The freeze requires the rasterizer" is WITHDRAWN — the control was not controlled + +**2026-08-26.** The section above concludes `--gpu=null` does not freeze. It is +wrong, and the flaw is in the comparison rather than the data. + +Driving the **null** backend blind, with the memory screen-id as the guide, to +the *same* screen the rendered run froze on (`screen = 4`): + + guest churn: 19 of 8,089,600 bytes in 4 s (0.000%) + Main XThread: 0 ms CPU / 4 s, state S, wchan futex_do_wait + log: AllocRange unable ... 134217728 bytes + Guest attempted to throw a C++ exception! + +**Frozen, identically, with no rasterizer at all** — same futex block, same +128 MB refusal, same throw. + +## What went wrong with the comparison + +The earlier "control" measured the null-GPU run while it was **still in the +menus**, and the lavapipe run **at the freeze**, then reported the difference as +a backend effect. The two arms were at different points in the game. The +allocations I cited as proof it had "walked through the content load" +(114 → 120) were menu-time allocations; the content load had not happened yet. + +**A control needs both arms verified to be at the same state.** The memory +screen-id built this same session is exactly what makes that checkable, and I did +not use it on the arm that mattered. + +## What this costs, and what survives + +🔴 **Withdrawn**: "the freeze requires the rasterizer"; "the fault is in the host +rendering path"; and the ⚠️ blocker on hardware Vulkan that followed from it — +the rendering question is no longer load-bearing, so it is not what is blocking +this. + +✅ **Survives**: the freeze happens on the first content load after the main menu, +on every route, on **both** GPU backends, with `Main XThread` **futex-blocked at +zero CPU** rather than spinning. And the earlier observation stands that four +runs froze with three different allocation outcomes — so the 128 MB refusal is +*correlated* but not necessary. + +✅ **Also survives, and is independently verified**: the memory screen-id +navigation ([`menu-state-in-memory.md`](menu-state-in-memory.md)), now reproduced +on a **third** run. It is what exposed this error. + +❔ So the open question returns to: **what is `Main XThread` waiting on?** It is +blocked on a host futex with the GPU excluded as the cause. The next lever is the +one not yet tried — identify the futex and its holder — and that needs care, +because gdb perturbs this measurement.