[joshuaswarren]

Current status: landing held

Head: a8960b752b385a7872285993ed657cfa1df41ee6.

The VA test now gets the NIR header it needs. The target failed to build before that fix. It now builds, and all nine test cases pass.

This head also rejects zero alignment. The new test raised SIGFPE before the guard. It now passes. These are CPU checks, not proof of device results.

Landing waits for #10 and the fixed, qualified #8. The older results below apply only to their stated heads. They do not prove that a later fix works.

Earlier description and evidence

READY TO MERGE after #10 and #8.

Head: 11ae82d8d8c379c2ae895806b4409537c5ceb25b.

GitHub reports MERGEABLE against main: no text conflicts. This is not a test pass.

The main-based head built and passed nine allocator checks.

Device result at this exact head, 13-inch M1, one boot, same CTS binary for both arms, dEQP-VK binding_model chunk 0 (1,000 cases):

	main 7cda7850ed	main + #10 + #8 + #9 (local merge of the three heads, tip 59c25f62c9d)
Pass	340	462
NotSupported	538	538
ResourceError	122	0

All 122 differences are ResourceError to Pass. No case gets worse. Before the run, each arm was checked to load its own driver file. The table shows the three PRs together, not #9 alone. It is one targeted chunk, not full CTS, and the CTS binary's source commit is not independently verified. An Aurora #18 result does not stand in for this one. Landing order: #10, #8, then #9.

Earlier review, source and test notes are kept below with their original bindings. The line below that says the main-based build was not run on a device is superseded by the result above. They do not change this status otherwise.

---

What this fixes

A buffer created with VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT cannot be replayed. In the first 1000 cases of the conformance group binding_model, every capture and replay case fails. vkCreateBuffer returns VK_ERROR_OUT_OF_DEVICE_MEMORY for a buffer that the test created with a captured address.

The cause is in the address heap. Capture and replay buffers take their addresses from the same heap as every other allocation. In the old code the capture device hands out addresses from the top of the heap. The replay device later asks for the same addresses. In the meantime it gives the same kind of addresses to other allocations. The trace does not say which ones. When one of those sits on a captured address, the replay of the buffer that owns that address fails.

I traced three conformance cases with a throwaway patch that logs every address allocation. In each one the failing request was the last address allocation of the run. It was a fixed-address request on the replay device. It came after 68, 73 and 2 earlier fixed requests had succeeded. The range it asked for overlapped a range that a non-fixed allocation had taken a moment before. No replay buffer was in the way. In the smallest case the request was for 0x8000 bytes at 0x2ffff7c000. The call just before it was a non-fixed allocation of 0x8000 bytes at exactly that address.

What this changes

• The lowest 4 GiB of the read-write user address window is reserved for capture and replay buffers. It has its own heap, and no other allocation uses it, so a captured address is free when it is replayed.
• The range is a fixed part of the window, so a capture made in one process replays in another on the same machine and kernel.
• Each buffer keeps its guard page. The allocation stores a flag, and free returns the range to the heap it came from.
• The read-only shadow of an address stays at the same offset, because the range is inside the read-write half of the window.
• An address that cannot be in the range, or that is in use, returns VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS. The reference page for vkCreateBuffer lists this code. A capture request with no address that finds the range full returns VK_ERROR_OUT_OF_DEVICE_MEMORY.
• agx_va_alloc refuses a fixed capture request outside the range without calling the heap code, which asserts on a range that wraps.
• A test of the allocator that needs no GPU is added as test-agx-va.c.

Limits of this change

• The 4 GiB range is a cumulative limit for all live capture and replay buffers on a device, guards included. An application that creates more than 4 GiB of buffers with the capture and replay flag now gets VK_ERROR_OUT_OF_DEVICE_MEMORY where it did not before. Buffers without the flag are not limited. The ordinary heap is 4 GiB smaller.
• A capture address works only on the same machine and kernel. The window start comes from the kernel's VM start, so it can differ between kernels and chips.
• An address captured by an earlier driver lies in the ordinary window. Its replay is now refused with VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS.

Test results

The allocator test is plain C and I ran it by hand with assertions on. All 9 cases pass. On a model of the old behavior, with the reservation turned off, 6 of the 9 cases fail.

A small test program, run on the 16-inch M1 Max, the new arm as a native build and the control as the built package, one boot. It captures 100 buffers in one process and replays them in a fresh process, in reverse order, with a memory allocation between replays, as the conformance test does.

	Main with #8	This change
Replay in a fresh process	74 of 100 match, then VK_ERROR_OUT_OF_DEVICE_MEMORY	100 of 100 match
seed_0, seed_2 and one replay compute case	ResourceError	Pass

In the same program this change returns the expected code for an address in the ordinary window, a captured address moved up by 4 GiB, an address in use, a 5 GiB buffer with an address (VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS), and a second 3 GiB buffer without an address (VK_ERROR_OUT_OF_DEVICE_MEMORY). A buffer destroyed and created again at the same captured address on the same device gets the same address both times, and both memory binds succeed. That test used one size and one recreate. It did not access the recreated buffer from the GPU. I did not read the return value of the scratch bind, which the code ignores.

The first 1000 cases of the binding_model group (chunk 0 of 151), with the library bytes of built packages, one run per arm. The 16-inch M1 Max and the 13-inch M1 give the same table.

	Control	This change
Pass	340	462
NotSupported	538	538
ResourceError	122	0

Exactly 122 of the 1000 rows differ on both chips, all from ResourceError to Pass, and 878 are unchanged. No row gets worse. The 122 rows are the 10 capture_replay_stress seeds and 112 buffer_device_address replay cases.

The control is the package of main with the change from #8 added. The candidate package is built from the commit on top of #8. This branch carries the same change on main. git patch-id is equal for the two commits, and the main-based commit built natively without errors. I did not run the main-based build on a device.

What this does not show

• This is one chunk, 1000 of 3,253,584 cases. Later chunks of the group, which hold more buffer address cases, were not run.
• The 13-inch M1 ran only the chunk above. The other tests ran on the 16-inch M1 Max.
• The virtio path compiles but did not run.
• The Gallium driver was not built.
• The meson test target for the allocator test was not built.
• Opaque capture addresses of memory objects were not traced.

[joshuaswarren]

GREEN at 11ae82d, with two non-blocking notes. I read the full diff against main (7cda785) and ran no build.

Checked:

• The patch is the same change I reviewed on top of honeykrisp: map placed memory at the allocation size #8. git patch-id is equal for the two commits, so the earlier review and the device runs on the package build apply to this diff.
• The numbers in the body match the raw per-chunk results from both machines. 340 Pass, 538 NotSupported and 122 ResourceError on the control. 462, 538 and 0 on the candidate. The 122 differing rows are 10 capture_replay_stress seeds and 112 replay cases, all ResourceError to Pass, with no row getting worse. The case list has 3,253,584 cases and the group has 151 chunks.
• The capture range check cannot wrap. The guard is added before the size is used. hk_CreateBuffer and agx_va_alloc agree on the guard.
• The new heap is created in one place and torn down in one place. Free picks the heap from the stored flag, so a freed capture address stays reserved.
• The read-only shadow arithmetic is unchanged, because the range sits inside the read-write half of the window.
• This branch merges with main and with the honeykrisp: map placed memory at the allocation size #8 head without conflicts.

Notes:

1. The main-based commit built natively but did not run on a device. Only the commit on top of honeykrisp: map placed memory at the allocation size #8 ran, as the body says. The diff is the same patch, so I accept this.
2. Destroying a capture buffer and creating it again at the same address was tested with one size and one recreate, with no GPU access to the new buffer. agx_va_free unbinds only the read-write range. This is not a regression, and the body states the test limit.

Merging is the maintainers' call.

[joshuaswarren]

Both notes are open items, and the body already states both. I did not change the branch.

1. The main-based commit has not run on a device. Any change to the commit gives a new head id, and the library bytes carry that id. The result above is tied to the library bytes built from the commit on top of honeykrisp: map placed memory at the allocation size #8. I can run the main-based commit once main moves or on request.

2. The destroy and create test used one size and one recreate. I can add more sizes and a GPU access to the recreated buffer as a separate test if the maintainers want it.

[joshuaswarren]

Maintainer routing request for PR 9. This is a request for a merge contact, not a claim that review is finished.

It makes capture and replay buffers replayable in a fresh process. What was run on the head 11ae82d8d8c3 and what was not run is in the description and in the two review comments above; I have not changed it since. PR 9 belongs to a merge order of PR 8, PR 9 and PR 10, then PR 6, then PR 11. A whole-suite run of PR 6 and the PR 11 commit on top of PRs 8, 9 and 10, against PRs 8, 9 and 10 alone, is queued. Its results will be posted on the PR 6 thread.

Question: who can merge into this repository's main branch, and in which of these PRs would you like to start? My account has pull access only.

[joshuaswarren]

Second routing request for PR 9, about 14 hours after the first. It is still a request for a merge contact, not a claim that review is finished.

Nothing on the head has changed since my first note above. The review notes and the list of what was run are in the description and the two review comments.

Question: who can merge into this repository's main branch? If there is a different place to ask, a link is enough. My account has pull access only, so I cannot merge or mark anything ready.

[joshuaswarren]

Status, 25 Oct: unchanged since 16 Oct, no review yet. It is in both arms of the #6 whole-suite run (main plus #8, #9, #10), so the binding_model capture and replay cases are counted equally on both sides. The #12 notes ask for an integration review against the native and Air allocation reservations; I will do that once the suite is running. It can land right after #8, independent of #6.

[joshuaswarren]

Status, 25 Oct, for the landing order (#10 first, then #8, then #9, then #6).

Head 11ae82d8d8c3. It merges cleanly after #10 and #8 on main 7cda7850ed. It does not merge on integration/aurora: four files conflict (agx_bo.h, agx_device.c, agx_device.h, agx_va.c), because that branch has its own capture and replay heap. I have a reconciled version for that branch in preparation. It reuses that heap and adds the range check and the error codes of this PR.

MEASURED: this change is in the control arm of the whole-suite CTS of the #6 stack (16-inch M1 Max and 13-inch M1), with no Pass to Fail change.

NOT measured: the capture and replay CTS groups with only this change.

[joshuaswarren]

The version of this change for integration/aurora is ready: branch aurora-va-check in the fork, head fba14a0b25ea, one commit on 147a62f6190.

That branch already has a capture and replay heap, so this keeps it. The commit records the range, adds agx_va_capture_valid (the guard page counts as part of the allocation, and nothing wraps), refuses an invalid fixed request inside agx_va_alloc, and returns VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS from vkCreateBuffer for an address outside the range or already in use. The unit test covers the range, the validity cases, the in-use case, and that ordinary allocations never land in the range.

MEASURED, native arm64 build of this head on a 16-inch M1 Max:

• hk_va passes. meson test gives 121 pass (the base gives 120; the new test is the difference) and the same 19 failures as the base.
• The driver links and the AGX compiler unit tests pass.

NOT measured: a GPU run and the capture and replay CTS groups on this head.

[joshuaswarren]

Batch 1 for main: #10, then #8, then #9, in that order.

All three apply to main at 7cda7850ed with no conflicts. They touch different code and git applies them in any order. The order is the agreed landing order. The #9 device run below is on top of #10 and #8. The #10 and #8 results below were measured on each branch alone. We checked the three together as a local merge (tip 59c25f62c9d). #19 went into integration/aurora, not main, so this base has not moved.

PR	Head	Change	Device result at that head
#10	b87e7456	accept a NULL array of transform feedback counter buffers	three transform_feedback chunks, 2,719 cases, on a 16-inch M1 Max and a 13-inch M1: the 18 former crashes pass, no other change
#8	ddfb4cf1	map placed memory at the allocation size	memory chunk 0, 1000 cases, both chips: 4 Fail and 1 Crash become Pass, no other row differs
#9	11ae82d8	give capture and replay buffers their own address range	binding_model chunk 0, 1000 cases, 13-inch M1, run at this exact head: 122 ResourceError become Pass, no case gets worse

Stack check, one boot on a 13-inch M1, binding_model chunk 0: main gives 340 Pass, 538 NotSupported and 122 ResourceError. Main with #10, #8 and #9 gives 462 Pass, 538 NotSupported and 0 ResourceError. The 122 changes are all ResourceError to Pass. This shows the three together. It does not isolate #9 from #8 and #10.

These are targeted checks, not the full conformance suite. The CTS binary's source commit is not independently verified.

#6 is not part of this batch. Its run over the touched test groups at its current head has not finished, and three shader_object.performance timing cases still need a decision. We will post that result separately. #3, #4 and #5 are superseded by #6 and will be closed after it merges.

The author account on these PRs has pull-only access, so a maintainer has to merge. Tell us if you want a different order or a different check first.

[joshuaswarren]

@maralcbr could you review this current head for landing after #10 and #8? The exact-head test evidence and remaining scope limits are in the PR body. The requested landing order is #10, then #8, then #9. Our account cannot assign formal reviewers or merge here; please route this to a main-branch maintainer if needed.

[chriskearney]

The new libasahi_va_tests target does not compile at 11ae82d, so any build of this head with -Dbuild-tests=true fails.

FAILED: src/asahi/lib/libasahi_va_tests.p/meson-generated_.._.._libagx_libagx.cpp.o
src/compiler/glsl_types.h:399:10: fatal error: builtin_types.h: No such file or directory

The same error comes for the generated libpoly.cpp.o.

Cause, in src/asahi/lib/meson.build:

• The target lists idep_libagx and idep_libpoly. These dependencies carry the generated libagx.cpp and libpoly.cpp as sources, which Meson compiles into every consumer.
• Those sources include glsl_types.h, which needs the generated builtin_types.h from src/compiler.
• The target does not list idep_nir, which provides that include path. libasahi_lib (line 67), with the same two dependencies, does list it.

Reproduced in two builds:

• a fresh x86_64 build of only this target, from this head alone on main 7cda7850ed;
• an aarch64 package build of main with #10, #8 and this PR merged, whose build stage uses -Dbuild-tests=true. In that tree, src/asahi/lib/meson.build and tests/test-agx-va.c are this head's files byte for byte.

The description already says the meson test target was not built.

Fix tested in a local copy (this branch is unchanged):

• Adding idep_nir to this target's dependencies works. The target builds, and the test prints 9 PASS lines and 0 failure(s) (x86_64 host).
• Removing idep_libagx and idep_libpoly instead does not work: agx_device.h includes libagx_dgc.h.

Please add idep_nir (or an equivalent dependency) and confirm with meson test libasahi_va_tests in a build with tests enabled. This review covers the build only. Results for the allocator change itself are reported separately.

[chriskearney]

This target needs idep_nir. The generated libagx.cpp/libpoly.cpp sources that idep_libagx and idep_libpoly add include glsl_types.h, which needs the generated builtin_types.h. libasahi_lib (line 67) lists idep_nir for the same reason. With it added, this target builds and its 9 cases pass.

[joshuaswarren]

Confirmed: the VA test target consumes generated libagx/libpoly sources but omits the idep_nir dependency that supplies builtin_types.h. I am reproducing the target-only build failure, then adding that dependency and running the registered test with build-tests enabled. This does not qualify the allocator or the future stack with the #8 mapping correction; the landing hold remains.

[joshuaswarren]

Fixed the test-target dependency at 93f94c8ccf4235a3e4a2bbb426783c9d9acbcd0c: added idep_nir without changing driver source. I reproduced the target-only builtin_types.h failure first; the corrected target now builds and meson test libasahi_va_tests reports all nine cases PASS and 0 failure(s) with build-tests enabled. The failed build and the separate passing test output are retained. This is CPU build/test evidence, not allocator/device qualification; landing remains held for #10 and corrected/qualified #8.

[joshuaswarren]

Source review at 93f94c8 (second commit, asahi/tests: supply the NIR dependency to the VA test target). Not a merge GREEN: landing is held for #10 and the corrected #8, and no device qualification was run.

Result: no defect found in the fix.

• The commit changes one line of src/asahi/lib/meson.build: it adds idep_nir to the dependencies of the libasahi_va_tests executable. libasahi_lib in the same file already lists idep_nir, so the test target now gets the generated NIR headers (builtin_types.h) the same way. No driver source changes in this commit.
• I reproduced the nine cases without Meson. I took this head, generated agx_pack.h and u_format_gen.h, and compiled test-agx-va.c, agx_va.c and the util heap sources with a stub for agx_bo_bind (the tests free with unbind false, so it is never called). Output: PASS: range shape, ordinary stays out, ordinary stays out when full, capture inside with guard, replay in fresh device, invalid requests, occupied request, exhaustion and reuse, freed capture range stays reserved, then 0 failure(s), exit 0. This matches the nine PASS lines in the proof comment.
• I changed agx_va.c seven ways to check the test reaches the code. Five are caught: dropping the guard from the final range check, removing the range check in agx_va_alloc, dropping the alignment check, dropping the wrap check, and allocating capture buffers from the main heap. Two survive. addr >= end made addr > end is an equivalent change, since the final inequality rejects the same address. Removing the user_size / 4 cap in agx_va_init_user survives: the test window is 64 GiB, so the cap never applies. A small-window case would cover it.

Nits in the first commit, not new:

• agx_va_capture_valid divides by align_B and subtracts guard_size from the range size without a check. Callers pass an alignment of at least 16384 and the range is 4 GiB, so neither can happen today; the same function in the replay-heap change guards align_B == 0.

Not checked: a Meson build of this tree (my build used the generated headers by hand), any device or CTS run, and #8 or #10.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] No new code issue blocks these changes; the PR's stated dependency and device-qualification hold still applies.

Summary

The PR gives capture/replay buffers a separate address range. Since the previous review:

• Capture/replay buffers keep their addresses free for replay.

No new actionable issues were found. Tests were not run during this review. The stated landing hold for #10 and a corrected, qualified #8 remains unchanged.

_{Reviews (2) · Last reviewed commit: "asahi: reject zero capture replay alignm..." · Reviewed by Greptile}

[chriskearney]

Independent successor check at a8960b7: the missing-NIR test dependency finding is resolved by 93f94c8, and the zero-alignment guard has a real failing-before control.

The exact registered allocator-test source linked with the actual allocator/VMA/futex code passes all nine cases. The same new test with parent 93f94c8 raises SIGFPE; the old test with that parent passes. Candidate and parent retain those respective outcomes with the allocator compiled under NDEBUG. This focused host check uses an aborting substitute only for the unused hardware-bind edge.

The full registered-build integration is also verified: the native aarch64 union of #10 b87e745, #8 4e269c5 and this head (local tip 9460a17b877, tree c0404e39) compiles and links the generated libagx and VA-test targets. libasahi_va_tests passes all nine cases; the complete registered suite is 49/49 with check exit 0. Production and test payloads are byte-identical, independently checked. No local dependency overlay was used.

This validates the two-fix delta and registered build, not new-head capture/replay device behavior. No Mac/GPU or CTS run of this successor is claimed, and the stated landing dependency on #10 and qualified #8 remains.

[maralcbr]

Reviewed at a8960b752b385a7872285993ed657cfa1df41ee6. Requesting changes: please close rather than merge.

• Wrong base. main mirrors stock Mesa, per the fork policy in AGENTS.md on integration/aurora.
• Superseded upstream, with a different design. b467490b ("hk: Allocate capture/replay VA with a separate heap", mesa!45582, 2026-10-29) fixes the same binding_model.buffer_device_address failures. Its capture heap overlaps the whole user range and allocates from the bottom (alloc_high = false). Each reservation is mirrored into the main heap, which allocates from the top. It sets no size cap. If this PR landed, main would conflict with upstream on every sync.
• Behaviour change that needs a maintainer opt-in. Reserving min(4 GiB, user_size/4) for capture/replay caps the VA that live capture-replay buffers can hold. Addresses captured by earlier drivers are refused with VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS. RenderDoc sets the capture-replay bit on BDA buffers while it captures, so large captures could start failing. That needs a deliberate decision. It shouldn't ride in on a CTS fix.
• Aurora already has this. integration/aurora has its own AGX_VA_CAPTURE_REPLAY heap, and omacom/mesa#18 covers it there.

If VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS for an in-use or out-of-range fixed address, and the wrap guard before util_vma_heap_alloc_addr, are still worth having, they'd make a small follow-up on top of upstream's design, sent upstream first.

[maralcbr]

Correction to my review above: drop the suggestion that a follow-up be "sent upstream first".

Upstream Mesa's AGENTS.md puts src/asahi under the Asahi Linux LLM policy, which broadly forbids generative AI for material contributions, so AI-assisted changes here can't go upstream. If the VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS handling is still wanted, it belongs on integration/aurora, alongside Aurora's capture/replay heap (omacom/mesa#18).

The rest of the review stands.

[joshuaswarren]

Closing this proposal at a8960b752b385a7872285993ed657cfa1df41ee6, as requested in the exact-head review. It is dropped, not merged.

The upstream replacement is b467490b84d006845d5da9a01f8b2e1af512b1f9. I read its patch: it uses an overlapping capture heap with reservations mirrored into the ordinary heap. This proposal instead carves out a capped range. It also targets the stock mirror branch.

The integration-branch work is tracked in #18. This closure does not qualify that PR or waive its heap and device holds. Existing tests and results remain historical evidence.