[PR #49] [MERGED] fix(vulkan): complete the GLES render fence before the Vulkan conversion reads it #50

New issue

Closed

opened 2026-10-15 12:47:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:47:55 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/49
Author: @salty2011
Created: 7/26/2026
Status: ✅ Merged
Merged: 8/16/2026
Merged by: @JBailes

Base: feat/vulkan-encode ← Head: fix/gles-vulkan-fence-order

📝 Commits (1)

979ba9e fix(vulkan): complete the GLES render fence before the Vulkan conversion reads it

📊 Changes

2 files changed (+11 additions, -4 deletions)

View changed files

📝 wayland-display-core/src/comp/mod.rs (+0 -4)
📝 wayland-display-core/src/comp/rendering.rs (+11 -0)

📄 Description

The NV12 / VulkanImage output paths render the scene into a GLES RGBA dmabuf and then import that same allocation into Vulkan for the RGBA→NV12 conversion.

The render fence is waited in the caller, after State::create_frame() returns — but create_frame() has already called to_gs_buffer(), which submits the Vulkan read. So the wait only orders the later GStreamer hand-off, not the GLES→Vulkan ownership seam: the GLES write and the Vulkan read end up ordered only if the driver happens to serialize the two APIs, which nothing guarantees.

This moves the existing wait to immediately after render_output(), before any readback or to_gs_buffer() conversion, and drops the now-redundant late wait from the caller.

No new synchronization is introduced — the same fence is waited, just at the point where it actually protects the consumer. Net diff is 2 files, +11/−4.

Independent of the encoder and of any downstream element: it concerns only the GLES-producer / Vulkan-consumer seam inside the compositor.

On attribution

I found this while chasing NVIDIA device-loss reports (Xid 13/32 → VK_ERROR_DEVICE_LOST) on an RTX 5090. To be straight with you: that symptom turned out to have a different, separately proven cause, so I am not claiming this fixes device loss. It is offered as a correctness/ordering fix on its own merits — the current code depends on undocumented driver behaviour for the seam to be safe.

Verification

cargo build --release clean and cargo test -p wayland-display-core green (18 passed, 0 failed) on this branch's head; cargo fmt --check clean. This fix has been running in my deployment on both NVIDIA and AMD hosts.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/gst-wayland-display/pull/49 **Author:** [@salty2011](https://github.com/salty2011) **Created:** 7/26/2026 **Status:** ✅ Merged **Merged:** 8/16/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `feat/vulkan-encode` ← **Head:** `fix/gles-vulkan-fence-order` --- ### 📝 Commits (1) - [`979ba9e`](https://github.com/games-on-whales/gst-wayland-display/commit/979ba9ead43030fb8cf219f3de0c23bd3839b288) fix(vulkan): complete the GLES render fence before the Vulkan conversion reads it ### 📊 Changes **2 files changed** (+11 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/mod.rs` (+0 -4) 📝 `wayland-display-core/src/comp/rendering.rs` (+11 -0) </details> ### 📄 Description The NV12 / VulkanImage output paths render the scene into a GLES RGBA dmabuf and then import that same allocation into Vulkan for the RGBA→NV12 conversion. The render fence is waited in the caller, **after** `State::create_frame()` returns — but `create_frame()` has already called `to_gs_buffer()`, which submits the Vulkan read. So the wait only orders the later GStreamer hand-off, not the GLES→Vulkan ownership seam: the GLES write and the Vulkan read end up ordered only if the driver happens to serialize the two APIs, which nothing guarantees. This moves the existing wait to immediately after `render_output()`, before any readback or `to_gs_buffer()` conversion, and drops the now-redundant late wait from the caller. **No new synchronization is introduced** — the same fence is waited, just at the point where it actually protects the consumer. Net diff is 2 files, +11/−4. Independent of the encoder and of any downstream element: it concerns only the GLES-producer / Vulkan-consumer seam inside the compositor. ### On attribution I found this while chasing NVIDIA device-loss reports (Xid 13/32 → `VK_ERROR_DEVICE_LOST`) on an RTX 5090. To be straight with you: **that symptom turned out to have a different, separately proven cause**, so I am not claiming this fixes device loss. It is offered as a correctness/ordering fix on its own merits — the current code depends on undocumented driver behaviour for the seam to be safe. ### Verification `cargo build --release` clean and `cargo test -p wayland-display-core` green (18 passed, 0 failed) on this branch's head; `cargo fmt --check` clean. This fix has been running in my deployment on both NVIDIA and AMD hosts. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:47:55 +00:00