Skip to content

feat(vk): add owned asynchronous presentation and queue selection - #2172

Open
mikaba-eu wants to merge 33 commits into
NotRexed:mainfrom
mikaba-eu:pr/native-present-slots
Open

mikaba-eu wants to merge 33 commits into
NotRexed:mainfrom
mikaba-eu:pr/native-present-slots

Conversation

@mikaba-eu

@mikaba-eu mikaba-eu commented Nov 11, 2026 •

Copy link
Copy Markdown
Contributor

A slow external Present can stall native frame production even when another queue could submit useful work. This adds opt-in bounded native presentation with three owned source images, explicit timeline ownership and real Vulkan Present results. Implemented with GPT-6 Astra medium & xhigh.

This PR is stacked on #1541 (renderer diagnostics/capture/present-result groundwork). Until that lands, the base diff also includes its changes. The native-only scope is vk_framegen.cpp/.h, vk_replay.cpp, vk_main.cpp and their presentation/capture tests; no material tables, packet encoding or visibility changes are required.

  • RX_VK_ASYNC_PRESENT=1 enables three owned source-image slots, bounded backpressure, ready/read-complete timeline values, resize draining and direct/interpolated mode transitions.
  • RX_VK_PRESENT_QUEUE=2 optionally uses a second queue in the graphics family; existing surface/queue fallback remains.
  • Accepted-present CSV telemetry uses the host clock epoch and separates source cadence from worker acceptance. It does not measure physical scanout.
  • WSI tests retain capture ownership, geometry, semaphore and device-loss assertions after the additional submission path.

Prior integrated Linux/NVIDIA gameplay covered normal output, helper recovery and real swapchain resize/restore. Matched same-artifact A/B/A with the corresponding external DLSS5VKLayer transport and unchanged 576x324 model workspace measured 52.37 / 62.21 / 52.63 FPS (+18.50% versus the bracketing mean). This supports the complete opt-in combination, not a standalone native gain or 120 FPS. New rebase gameplay acceptance is separate. Added buffering may increase latency.

Validation: all 380 eligible Linux source checks passed, with 14 documented platform/tool skips, across the initial full suite and corrected-environment resumed/follow-up checks. Refreshed to upstream ddafc1f9; the native-only diff can be reviewed against the renderer prerequisite. All runtime options remain off by default. External layer changes belong to bmitch87/DLSS5VKLayer and are not vendored here.

The final isolated Linux renderer also compiled and linked successfully (60 seconds, zero compilation failures).

The final source includes upstream 2e62a977; its release-only changes passed both affected release/update checks.

The external transport counterpart is DLSS5VKLayer #39.

codex added 30 commits November 10, 2026 08:28
Preserve submitted-memory and texture-generation validation while reusing stage lowering, descriptor state and resolved shader handles. Restore Linux synchronous presentation affinity, order overlapping uniform writes, and preserve capture geometry. Include authored regression tests and opt-in timing tools without changing upstream compute preloading or presentation recovery.

Assisted-by: GPT-6-Astra (medium and xhigh)
Co-Authored-By: OpenAI Codex <codex@openai.com>
Assisted-by: GPT-6-Astra (medium and xhigh)
Co-Authored-By: OpenAI Codex <codex@openai.com>
# Conflicts:
#	gpu/vk/vk_texture.cpp
#	host/hos_thread.c
…esh-20261111

# Conflicts:
#	gpu/vk/vk_draw.cpp
#	tests/test_present_semaphores.py
#	tests/test_program_answer_domains.py

@Joey-Magnus Joey-Magnus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The native-present part is careful work. I read it in isolation: #1541's head 131b0a34 against this PR's head is 20 files, +761. Each slot has its own timeline, and the values are ordered so no submit ever waits on a value that hasn't been submitted yet. That matters, because present_image's own comment warns that this has hung the queue before. Here it holds: submit_recording skips batching and flushes before the handoff, the worker only gets the job after that submit, and the replay only reuses a slot once the worker has submitted its read or present_async_release. A resize drains and idles before images are replaced. The changed tests are updated rather than loosened, and test_present_device_loss is actually stricter now. At the PR's head, async_present, present_queue_selection, present_device_loss, present_clock_epoch, present_aspect and present_semaphores pass locally. In its current shape, though, this can't be merged:

blocking: the PR is #1541 plus this feature. #1541 is still open, so this diff is 79 files and +3,365 lines covering renderer CPU work, stage traces, thread affinity, guest-import changes in vk_memory.cpp and the analysis scripts. Merging this would merge #1541 without its own review. CONTRIBUTING asks for one topic per PR. Please let #1541 land (or be dropped) first, then rebase so this PR's diff is the native-present part alone. I reviewed only that part here.

blocking: as hckrman101 said, it conflicts with main in gpu/vk/vk_draw.cpp, vk_main.cpp, vk_memory.cpp, vk_replay.cpp, vk_shader.cpp, vk_texture.cpp, tests/present_geometry_trace_test.cpp, tests/test_antilag.py and tests/test_present_aspect.py. Most of that comes from the #1541 part, so the rebase above should shrink it.

should fix, gpu/vk/vk_replay.cpp:3824: if (res != VK_SUCCESS) device_lost(); is in present_image for every present, not only the async ones. Today, for every player, an out-of-memory or other non-device-lost submit failure becomes the device-lost report and exit. The reasoning may be right (the frame fence was already reset), but it contradicts "all runtime options remain off by default". It's a behaviour change for all hardware tiers, so it deserves its own small PR, or at least a line in the description and in docs/design.md's present notes. The == VK_ERROR_DEVICE_LOST line just above it becomes redundant.

should fix (docs): RX_VK_ASYNC_PRESENT, RX_VK_ASYNC_PRESENT_LOG and the new RX_VK_PRESENT_QUEUE=2 aren't in the switch table in docs/development.md, which is where CONTRIBUTING asks new switches to be documented. Neither is RX_VK_PRESENT_QUEUE itself. NATIVE_PRESENT_IMPLEMENTATION.md at the repository root reads like design notes; it belongs in gpu/vk/VULKAN.md or under docs/.

question (testing): the only measured gain is with the external DLSS5VKLayer, and the description says itself that this "supports the complete opt-in combination, not a standalone native gain". Gameplay after the rebase is still pending, and only Linux/NVIDIA was run. Since the switch is off by default it can't regress anyone who doesn't set it. Still, before merge it would help to have one run of RX_VK_ASYNC_PRESENT=1 without the layer, on NVIDIA and on an AMD card and ideally on Windows, showing frame pacing and latency against the direct path. That lets players who try the switch know what to expect.

@Joey-Magnus Joey-Magnus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About 2,600 of the ~3,365 lines are #1541's, which is still open and conflicting, so this can't be reviewed or merged on its own until it's rebased onto that. The native-present part (20 files, +761) has sound synchronization: odd/even timeline values per slot, captures flushed before handoff, early returns releasing the slot, and a resize draining the present thread and idling before teardown.

Two things for everyone even with the switches off:

  • vk_replay.cpp:3824 adds if (res != VK_SUCCESS) device_lost(); to every present's submit, so out-of-memory and other errors exit through the device-lost path.
  • RX_VK_PRESENT_QUEUE=2 silently does nothing with a single-queue graphics family (vk_main.cpp:301), which is likely RADV and much of Intel. Please log it.

Also: the switches aren't in docs/development.md, and the design notes file sits at the repo root.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants