Vulkan Throughput Candidates

Vulkan Throughput Candidates

Reviewed: November 1, 2026. Fork source: b7140848 (full SHA b71408480a3a979a9c584663e1d1f400904c8bb7). Latest stable checked: v0.8.136-0-g458730bf5373, September 30, source 458730bf5373f1f0d027450fef7443e3af7a3ae1. GitHub state, branch recommendation, source presence and release availability are separate facts. See current status and release versus main.

Current lifecycle and scope

The six architectural proposals remain separate work items. Their original source-backed candidate map is preserved below, but a blanket “never implemented or measured” label no longer describes their foundations or branch experiments.

Candidate area	Current source / branch state	Availability and evidence boundary
Submission and retirement	Existing color-download folding and transient-buffer growth are delivered mechanisms; a general asynchronous retirement redesign remains research.	Existing mechanisms do not establish the broader design or its game benefit.
Native Vulkan presentation	A native-presenter replacement remains a proposal; GPU identity/cross-adapter handling and Windows DXGI are distinct existing mechanisms.	No complete native Vulkan presenter is promised in main or stable.
Dynamic uniform descriptors	Uniform update plans and dirty-row work are distinct from dynamic descriptors.	No complete dynamic-descriptor conversion is claimed.
PVIDEO lifetime	Resource lifetime and GPU conversion remain distinct proposed changes.	Existing display reuse does not establish this conversion.
GPU-resident consumers	Depth foundations/ownership tests landed; runtime consumer #290 and small-color child #291 remain open/HOLD.	Consumer code absent from main/stable. Historical Conker findings do not resolve reset/load, restored-progress and surface-oracle gaps; the six-arm campaign is stopped.
Adaptive buffer placement	Placement policy remains distinct from capacity/growth and allocation recovery.	Smaller allocations alone establish no throughput improvement.

The later depth foundations are main only at this review; their merged helpers do not activate #290/#291. Both consumer branches retain historical useful measurements, but current integration/lifecycle and applicable per-test timing qualification remain required. See research and retired work and the current feature register for exact implemented boundaries.

Related occlusion-query fork #318 is closed unmerged/SKIPPED for the current Deck effort. One fresh pair’s +2.305% guest cadence and mixed tails preserve an opportunity; they establish neither zero benefit nor a broad gain. Upstream #2995 remains open. Persistent SPIR-V, learned-family history and driver pipeline caches are delivered mechanisms distinct from the six proposals; their component savings must not be presented as general FPS gains.

No new native or XISO measurements were made by this page refresh. Read source presence, release availability, activation and evidence as separate fields rather than one Unproven/Implemented switch.

Historical candidate map — September 2026

The original analysis follows unchanged at 322986f4c5502b3fa887a9605ac8cd88e9b2c579. Its present-tense source and unmeasured labels apply to that snapshot; the current lifecycle above supersedes them.

Lifecycle: Performance - Unproven
Reviewed source: 322986f4c5502b3fa887a9605ac8cd88e9b2c579
State: The code paths exist. Their workload impact has not been measured in xemu.

These candidates target synchronization, descriptor churn, object lifetime, representation changes, and memory placement. They are broader than micro-optimizations and remain Unproven until release-build evidence exists.

Vulkan throughput pages: Overview · Submission & retirement · Native presentation · Dynamic uniforms · PVIDEO lifetime · GPU-resident consumers · Buffer placement

Candidate map

Candidate	Type	Work that may disappear	Existing overlap
Submission and Resource Retirement	Submission architecture	Fence waits caused only by immediate object reuse	Extends Color-Download Folding and Transient-Buffer Growth
Native Vulkan Presentation	Presentation architecture	Vulkan-to-OpenGL synchronization and fallback readback/upload	Distinct from Unchanged Scanout
Dynamic Uniform Descriptors	Descriptor design	Texture-descriptor rewrites caused only by new uniform offsets	Distinct from Uniform Update Plans
PVIDEO Resource Lifetime	Resource reuse / GPU conversion	Per-upload image objects, CPU YUY2 conversion, separate upload wait	New
GPU-Resident Surface Consumers	Coherency architecture	Surface readback followed by GPU re-upload	Extends Direct Surface Sampling
Adaptive Buffer Placement	Memory policy	Transfers or poor fetch placement that do not fit the host memory architecture	Distinct from buffer capacity/growth policy

Promotion flow

flowchart LR
    A[Source-backed candidate] --> B[Cheap route counters]
    B --> C[Focused correctness test]
    C --> D[Release A/B with fixed guest progress]
    D -->|Useful evidence| E[Performance - Researched]
    D -->|No useful effect| F[Stop and record result]
    E -->|Lands in main| G[Performance - Implemented]

Loading

Scope notes

• Combining the existing upload and draw command buffers into one submit batch is a probe inside the submission page, not a separate candidate.
• Suppressing host presentation is a diagnostic mode for measuring presentation cost, not a playable optimization.
• ARM64 build availability is a platform topic, not a performance mechanism. Any host-specific optimization still needs its own backend implementation and validation.
• Lower allocation size alone is not evidence of better performance. Capacity, placement, lifetime, and synchronization are separate questions.

Shared evidence

Collect the same base signals for all six candidates:

finish and queue-idle time by reason
command batches submitted and in flight
descriptor writes and descriptor-pressure finishes
upload and readback bytes by purpose
object creation/destruction counts
CPU preparation time
GPU idle gaps
fixed guest progress and p95/p99 frame time

Related

• Performance - Unproven
• Vulkan Renderer
• Vulkan Performance
• Performance Methodology
• Debugging Lag & Hot-Path Analysis