mirror of
https://github.com/games-on-whales/gst-wayland-display.git
synced 2026-10-15 12:51:57 +00:00
[GH-ISSUE #14] DMABuf negotiation fails on Intel B580 #7
Labels
No labels
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/gst-wayland-display#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @anonymix007 on GitHub (Jul 24, 2025).
Original GitHub issue: https://github.com/games-on-whales/gst-wayland-display/issues/14
@DatCaptainHorse commented on GitHub (Jul 24, 2025):
Known issue with
xedrivers (I have A770 where both i915 and xe driver can be used), I'll try to look into things again after update PR is done, maybe it will help solving this issue.Edit: Seems you're also in the know :)
@anonymix007 commented on GitHub (Jul 29, 2025):
I got it to somewhat succeed by removing
DrmModifier::Unrecognized(0x0100000000000009)hack indrm_to_gst_format.At least I see an extra cursor (not just the system one) on the glimagesink window until it disappears a few seconds later.
Are you sure that hack is neccesary? As per
gst-inspect-1.0 vapostprocoutput (see above), this modifier is already supported with some formats.There still seems to be something wrong though:
It seems that DMA bufs are allocated via libgbm. I think the only sane way forward is to actually use GstVaDmabufAllocator if downstream caps suggest that there are other VA elements in a pipeline and not bother with handling modifiers manually.
@DatCaptainHorse commented on GitHub (Jul 29, 2025):
🤔 it's needed for DG2 + i915 atleast, without the workaround/hack this is what I get on A770:
I'll update this comment after trying with
xedriver again, maybe stuff got better last time on that driver's side.Update: No luck for me, same errors. Can you share your
gst-inspect-1.0 vah264encformats @anonymix007 ? - For me only "LP" (Low Power) encoders are available (i.e.vah264lpenc)@ABeltramo commented on GitHub (Jul 29, 2025):
That means everything is working.
For quickly testing via the CLI you can pass
mouse="/dev/input/eventX" keyboard="/dev/input/eventY"(with the right devices from your host) towaylanddisplaysrc. And to display something, you can simply runWAYLAND_DISPLAY=wayland-1 firefox(the name of the Wayland socket is allocated automatically, check the logs).We'll have to see if and how that works, ultimately the buffer must be turned into an
EGLImagein order for Smithay to use it in theGLESrenderer, this is what we end up calling. A buffer created fromvacan be imported viaCreateImageKHR?P.S. I'm planning on adding support for Vulkan buffers, given that Smithay should support it and the recent advances in Gstreamer I'd really like to explore that in the near future. It would be nice to finally have a cross-platform encoding pipeline without all these kinds of issues..
@anonymix007 commented on GitHub (Jul 29, 2025):
@DatCaptainHorse:
Does it print something different for you? I guess it could be that vaCreateSurface uses a different modifier on DG2 by default (and this is how GStreamer "queries" the supported modifiers), but using VA allocator should be enough to make it happy.
It should be, this is a standard DMA buffer and these are not Nvidia GPUs after all.
This actually works, cool! BTW, have you considered handling navigation events in the element? This would make testing with
gst-launch-1.0easier.I think it's a bit early for Vulkan, but it would be really cool to get something not tied to a specific hw encoder API. But it'll be a long time until vulkan video encoding will reach feature parity with VA-API and NVENC. Currently
vulkanh264encdoesn't seem to be enabled on B580.@DatCaptainHorse commented on GitHub (Jul 29, 2025):
@anonymix007 hm, I have same modifiers, so it's weird that for me it just errors out without the workaround.. DG2 bug maybe? 🤔
Also I can probably answer some of things:
You mean these events? Or you need something more?
ABeltramo has been thinking of supporting Vulkan buffers, not only for encoding necessarily, but so
gst-wayland-displaycould output Vulkan buffers which could then be imported to CUDA to hopefully allow less overhead within the pipeline. Would require new custom element "cudavkupload" or so.@ABeltramo commented on GitHub (Jul 29, 2025):
There are some specific Navigation events in Gstreamer that are used by some plugins (most famously
webrtcI guess?) to propagate mouse/keyboard events. I believe GstNavigation is the main interface. I haven't really looked into it but yeah, it would be nice to add support for that, anyone up for a PR? 😉I know, right?
Yeah, as @DatCaptainHorse said I'm dealing with a few issues when having multiple OpenGL plugins in different pipelines in Wolf, so I would like to get rid of the intermediate
gluploadstep that is required and instead import a Vulkan buffer in CUDA which seems to be possible from the light testing that I've done using cudaImportExternalMemory. Plus, the ability to potentially have support for a fully cross-platform Vulkan pipeline makes it worth the effort IMHO.Definitely early days, but that has been the case for every single part of this project, I wouldn't be here if I didn't like a good challenge.. 😅