[PR #21] [MERGED] feat: CPU optimizations for CUDA-path #24

New issue

Closed

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/21
Author: @DatCaptainHorse
Created: 10/12/2025
Status: ✅ Merged
Merged: 10/12/2025
Merged by: @ABeltramo

Base: cuda-interop ← Head: woof

📝 Commits (2)

a7d2287 feat: CPU optimizations for CUDA-path operations
398ba0e fix: properly using RAII for EGLImage and avoid using eglGetCurrentDisplay()

📊 Changes

7 files changed (+165 additions, -133 deletions)

View changed files

📝 Cargo.lock (+15 -15)
📝 gst-plugin-wayland-display/src/waylandsrc/imp.rs (+6 -7)
📝 wayland-display-core/src/comp/mod.rs (+13 -0)
📝 wayland-display-core/src/lib.rs (+3 -2)
📝 wayland-display-core/src/utils/allocator/cuda/ffi.rs (+52 -51)
📝 wayland-display-core/src/utils/allocator/cuda/mod.rs (+35 -33)
📝 wayland-display-core/src/utils/allocator/mod.rs (+41 -25)

📄 Description

Profiling with flamegraph showed that some resource allocations were eating plenty of CPU cycles each frame, those are now cached, as the pointer location stays same things work out, but without recreating the resource each time 🙂

Secondly, settings.cudabuffer_pool = Some(pool); was set in decide_allocation, which happened later when settings were already communicated to wayland-display-core, so I added extra command to send the buffer pool later on separately, this works out from my testing just before gstreamer pipeline starts rolling.

Thirdly, now that buffer pool is set and available during runtime, I changed alloc_copy_gst_memory to return straight buffers instead and separated copy-op to it's own method. Syncing the CUDA stream after unmap was also eating some CPU cycles from simply waiting, as the CuMemcpy2DAsync is async, it seems to be fine to let the CUDA runtime handle the unmap later after the async-op is done.

I might've misplaced some comments from original locations, and I'm not sure if UpdateCUDABufferPool command is what you'd want so I marked that as TODO 😅

Let me know of any issues 🙏

_{🔄 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/21 **Author:** [@DatCaptainHorse](https://github.com/DatCaptainHorse) **Created:** 10/12/2025 **Status:** ✅ Merged **Merged:** 10/12/2025 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `cuda-interop` ← **Head:** `woof` --- ### 📝 Commits (2) - [`a7d2287`](https://github.com/games-on-whales/gst-wayland-display/commit/a7d228711aad9fe79b4608bf3b029e86015cfd7a) feat: CPU optimizations for CUDA-path operations - [`398ba0e`](https://github.com/games-on-whales/gst-wayland-display/commit/398ba0e8589eb6a1ff40d5132d2139851fc21854) fix: properly using RAII for EGLImage and avoid using `eglGetCurrentDisplay()` ### 📊 Changes **7 files changed** (+165 additions, -133 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+15 -15) 📝 `gst-plugin-wayland-display/src/waylandsrc/imp.rs` (+6 -7) 📝 `wayland-display-core/src/comp/mod.rs` (+13 -0) 📝 `wayland-display-core/src/lib.rs` (+3 -2) 📝 `wayland-display-core/src/utils/allocator/cuda/ffi.rs` (+52 -51) 📝 `wayland-display-core/src/utils/allocator/cuda/mod.rs` (+35 -33) 📝 `wayland-display-core/src/utils/allocator/mod.rs` (+41 -25) </details> ### 📄 Description Profiling with flamegraph showed that some resource allocations were eating plenty of CPU cycles each frame, those are now cached, as the pointer location stays same things work out, but without recreating the resource each time :slightly_smiling_face: Secondly, `settings.cudabuffer_pool = Some(pool);` was set in `decide_allocation`, which happened later when settings were already communicated to wayland-display-core, so I added extra command to send the buffer pool later on separately, this works out from my testing just before gstreamer pipeline starts rolling. Thirdly, now that buffer pool is set and available during runtime, I changed `alloc_copy_gst_memory` to return straight buffers instead and separated copy-op to it's own method. Syncing the CUDA stream after unmap was also eating some CPU cycles from simply waiting, as the `CuMemcpy2DAsync` is async, it seems to be fine to let the CUDA runtime handle the unmap later after the async-op is done. I might've misplaced some comments from original locations, and I'm not sure if `UpdateCUDABufferPool` command is what you'd want so I marked that as TODO :sweat_smile: Let me know of any issues :pray: --- <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:37 +00:00