dtourolle/DarkRoom
1
0
Fork 0
Code Issues 39 Pull Requests Actions Packages Projects Releases 21 Wiki Activity

Say that FR-DSP-2 is waiting on S6, not that it was rewritten

Browse Source 
R5's note said FR-DSP-2 "was rewritten rather than implemented". It was
not: the clause still demanded viewport tiling, the matrix listed it
unbuilt, and frame-budget.md's rewrite had been proposed and never
applied. Decided 2026-09-19 to keep it as written until S6 runs on a
mid-range Android device, because the measurement that argues against
tiling was taken on a discrete desktop GPU and the clause exists for the
device whose memory the image exceeds. Both notes now say that.
This commit is contained in:
dtourolle
2026-09-19 12:25:03 +02:00
parent 95458356da
commit d259c0d4bb
1 changed files with 16 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/requirements.md
+16 -2
View File
@@ -83,8 +83,11 @@ results.
**On R5's tiling.** An earlier draft added two clauses to R5's criterion: *"only visible tiles are **On R5's tiling.** An earlier draft added two clauses to R5's criterion: *"only visible tiles are
computed; panning recomputes only newly exposed tiles"*. They have been struck, and the reason is computed; panning recomputes only newly exposed tiles"*. They have been struck, and the reason is
the same one FR-DSP-2 was rewritten for rather than implemented: the one [frame-budget.md](frame-budget.md) measured — the same measurement that argues FR-DSP-2
[frame-budget.md](frame-budget.md) measured it. should be rewritten rather than implemented. FR-DSP-2 itself has **not** been rewritten: it
stands as written until spike S6 has run on constrained Android hardware, because the desktop
measurement cannot speak for a device whose GPU memory the image exceeds (decided 2026-09-19;
see the note under FR-DSP-2).
R5's actual demand is met and tested. The display pipeline works at viewport resolution: R5's actual demand is met and tested. The display pipeline works at viewport resolution:
`Framing::view` shrinks the sampled region while the render target keeps its size, so zooming raises `Framing::view` shrinks the sampled region while the render target keeps its size, so zooming raises
@@ -563,6 +566,17 @@ processes approximately 2000px of data, not 60MP.
intersecting the viewport are computed. Panning computes only newly exposed tiles; already-valid intersecting the viewport are computed. Panning computes only newly exposed tiles; already-valid
tiles are reused. tiles are reused.
> **Status, 2026-09-19: as written, unbuilt, and waiting on S6.** The interactive path does not
> tile, and [frame-budget.md](frame-budget.md) argues it should not on the reference desktop: a
> fused pass over a 4K viewport costs 4.5 ms of a 16 ms budget, a tile cache could save at most
> that, and the one stage over budget is a convolution that tiling makes worse. That argument is
> a desktop measurement. The case this clause was written for — an image larger than the GPU
> memory of a mid-range Android device (NFR-RES-2, ARCH §6.2) — has not been measured, and S6 is
> the spike that measures it. Until it runs the clause stands, so that a decision is taken on a
> number from the device the clause is about rather than from the one it is not. If S6 finds the
> fused pass inside budget there too, FR-DSP-2 becomes a scheduling concern for export and
> thumbnailing as frame-budget.md proposes; if not, S6 names the stage to tile.
**FR-DSP-3 — Interactive latency.** Moving a slider updates the visible region within one frame **FR-DSP-3 — Interactive latency.** Moving a slider updates the visible region within one frame
budget at proxy resolution. When a full-resolution result is needed it is computed budget at proxy resolution. When a full-resolution result is needed it is computed
asynchronously, and the proxy result remains on screen until it is ready. asynchronously, and the proxy result remains on screen until it is ready.