Performance Research G10 Batched and Parallel Command Recording

Batched submissions and multithreaded command recording

G10 — Implementation and validation notes

Field	Value
Evidence state	Architectural hypothesis; prior neutral/slower batching must be retained as negative evidence
Inspected source	322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment	Attribute serial recording cost before parallel dispatch
Scope	Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

Do not revive a rejected result by renaming it. The repository explicitly retains a batched-submit synchronization repair whose neutral/slower performance result remains rejected. Correctness repair is not evidence that the original batching idea became faster. Research history.

Production precedent with limits. Khronos' command-buffer sample reports a 15% improvement for approximately 1,800 draws split over eight threads/buffers in its test. It also warns that many small secondary command buffers can hurt. That result motivates a workload-specific experiment, not an xemu forecast. Command-buffer sample.

Implementation. The guest method stream is ordered and stateful. Parallelize only immutable prepared work with explicit dependencies, retaining ordered effects and completion. Each recording worker needs correctly owned pools/resources. Submissions, reports, readbacks, render-pass transitions, and ring pressure limit batching opportunities.

Expected gain and tests. Measure record/build CPU separately from GPU execution and host waits. Require enough work per task to exceed dispatch/secondary-buffer overhead. Preserve pending vertex ownership and all guest-visible synchronization. Include low draw count, high draw count, report-heavy, capacity-heavy, and shader-transition workloads.

First patch boundary

Do not parallelize mutable guest method interpretation. A new experiment must explain why its task/dependency model differs from rejected batching.

ordered guest methods -> immutable eligible tasks -> bounded recording -> dependency-ordered submission

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'submit|command_buffer|finish|report|vertex' -- hw/xbox/nv2a/pgraph/vk

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID	Setup / deliberate control	Required oracle
G10.01	Capture high-level ordered draw/report/readback events from serial and candidate paths.	Guest-visible ordering and outputs match even when host command buffers are partitioned differently.
G10.02	Delay one recording task while later state, reports and readbacks arrive; force small capacity.	Dependencies block only legal successors; memory stays bounded and no mutable state leaks between tasks.
G10.03	Compare serial, capacity-only and parallel variants for identical guest work.	A scheduling/recording saving survives total waiting, memory and tail accounting.

Counters and rejection criteria

Collect: record_cpu_ns, dispatch_cpu_ns, tasks_per_batch, queue_depth, submit_count, total_wait_ns, gpu_idle_ns, memory_high_water. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: A synchronization repair does not prove speed. Stop if more queueing merely moves waits or increases latency/resource pressure.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.