GNOME DMA-BUF Screencasting Now Limited To Intel Drivers Due To Bugs Elsewhere

[oleid]

I want to use that. I'm unable to make Screen Sharing under Gnome+Wayland to work on ArchLinux. I have a LG Smart TV and still unable to put another GPU plus an HDMI cable, so screensharing/screencasting as a secondary display for movies and some gaming can be an alternative if I were able to make it work.

Can someone help me, please?

Sorry it took a while. The power supply of that PC broke down.

The following is the package I'm using (together with community/obs-studio). Works fine on my Radeon R470.

$ pacman -Qo /usr/lib/obs-plugins/gnome-mutter-screencast.so
/usr/lib/obs-plugins/gnome-mutter-screencast.so is owned by obs-gnome-screencast 0.1.0-1
$ pacman -Qi obs-gnome-screencast
Name : obs-gnome-screencast
Version : 0.1.0-1
Description : GNOME Screen Cast OBS Studio plugin
Architecture : x86_64
URL : https://github.com/fzwoch/obs-gnome-screencast
Licenses : GPL2
Groups : None
Provides : None
Depends On : gnome-shell obs-studio gtk3 gstreamer gst-plugins-base-libs
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 17.62 KiB
Packager : Unknown Packager
Build Date : Mon May 4 13:20:00 2020
Install Date : Mon May 4 13:20:15 2020
Install Reason : Explicitly installed
Install Script : No
Validated By : None

[zxy_thf]

I built ArchLinux AUR's obs-studio-git and obs-xdg-portal-git. I tought that had the equivalent stuff.

No it's not. You need the latest build, and the arch package hasn't been updated since Jul if I read it correctly.

[timofonic]

My choice is to build OBS from source with flatpak.
For now only the beta branch has all needed features (including the performance fix). If you read this post a few months later you could try use the flathub version directly

The following should work

git clone https://github.com/flathub/com.obsproject.Studio
cd com.obsproject.Studio
git checkout beta # Important
flatpak-builder --force-clean build-dir com.obsproject.Studio.json --user --install # Only to get what SDK you need
flatpak install flathub org.kde.Sdk/x86_64/5.15 # Install the correct SDK promoted in the previous step
flatpak-builder --force-clean build-dir com.obsproject.Studio.json --user --install # Actual compiling and installing step, after getting the right SDK installed
# Grab a cup of coffee, a sandwich or something else. It takes really a while... even on 3900X

flatpak run --user com.obsproject.Studio # You're good to go.

I built ArchLinux AUR's obs-studio-git and obs-xdg-portal-git. I tought that had the equivalent stuff.

There's obs-studio-wayland.

I'm not a fan of Flatpak, Snap and such. But I'll yse it if there's no other choice.

Makes me wonder if they'll have to blacklist Xe or come up with a proper way to detect IGPU vs. DGPU once it comes out.

Yeah, either they'll have to be iGPU/dGPU agnostic, or find out which is which and use different methods to access memory.

[zxy_thf]

I want to use that. I'm unable to make Screen Sharing under Gnome+Wayland to work on ArchLinux. I have a LG Smart TV and still unable to put another GPU plus an HDMI cable, so screensharing/screencasting as a secondary display for movies and some gaming can be an alternative if I were able to make it work.

Can someone help me, please?

My choice is to build OBS from source with flatpak.
For now only the beta branch has all needed features (including the performance fix). If you read this post a few months later you could try use the flathub version directly

The following should work

git clone https://github.com/flathub/com.obsproject.Studio
cd com.obsproject.Studio
git checkout beta # Important
flatpak-builder --force-clean build-dir com.obsproject.Studio.json --user --install # Only to get what SDK you need
flatpak install flathub org.kde.Sdk/x86_64/5.15 #  Install the correct SDK promoted in the previous step
flatpak-builder --force-clean build-dir com.obsproject.Studio.json --user --install # Actual compiling and installing step, after getting the right SDK installed
# Grab a cup of coffee, a sandwich or something else. It takes really a while... even on 3900X

flatpak run --user com.obsproject.Studio # You're good to go.

[MrCooper]

Bad way: Just map the VRAM frame buffer and access its memory.

And that's exactly the reason for this change. The problem isn't in mutter or in the drivers, it's in other components (I've heard of gnome-remote-desktop & gstreamer, there might be others) using direct CPU mappings for reading the dma-buf contents. If the buffer is located in VRAM, that trickles down at on the order of tens of MB/s, which translates to single-digit frames per second. If it's "just" uncacheable system memory, it might break into low double-digits.

Once the worst offenders have been fixed to use a more efficient method, this can be re-enabled again. Until then, mutter itself reading the frame contents with glReadPixels is the lesser evil. In the meantime, users of more efficient capturing components (e.g. the OBS portal plugin being developed) can force-enable it via the experimental feature added in the same MR.

[brent]

Downloading VRAM to host memory on a DGPU is slow, but not THAT slow. You don't really need much bandwidth for the frame buffer. However, you need to do it asynchronously with a staging buffer for good performance. I'm not sure what gnome-shell is doing, but if it is doing a synchronous copy (by simply mapping the VRAM), it is no surprise that it is slow. You have to starve the whole pipeline for that. This isn't how you are supposed to do it!

Correct way: Kick off a copy from VRAM frame buffer memory to GART-mapped buffer, continue and wait until it is finished (e.g. wait until next frame), then use it.
Bad way: Just map the VRAM frame buffer and access its memory.

[timofonic]

If I recall correctly, I installed some Gnome-shell plug in. Can look up its name, if you're interested.

The official OBS studio does not offer the screen sharing function in Wayland, and you need a special plugin obs-xdg-portal.

Unfortunately this is not the end of the story. This plugin was initially released mainly for demo purpose rather than for production use, and only the gbsneto/pipewire branch provides good performance. Not sure if Arch ships the latest version but in Fedora I have to build OBS from source (in flatpak, the rpmfusion one is broken from the beginning)

I want to use that. I'm unable to make Screen Sharing under Gnome+Wayland to work on ArchLinux. I have a LG Smart TV and still unable to put another GPU plus an HDMI cable, so screensharing/screencasting as a secondary display for movies and some gaming can be an alternative if I were able to make it work.

Can someone help me, please?

[oleid]

The official OBS studio does not offer the screen sharing function in Wayland, and you need a special plugin obs-xdg-portal.

Unfortunately this is not the end of the story. This plugin was initially released mainly for demo purpose rather than for production use, and only the gbsneto/pipewire branch provides good performance. Not sure if Arch ships the latest version but in Fedora I have to build OBS from source (in flatpak, the rpmfusion one is broken from the beginning)

If I recall correctly, I installed some Gnome-shell plug in. Can look up its name, if you're interested.

[zxy_thf]

Hmm, interesting. OBS studio works fine here on Arch with amdgpu driver. It's there no need to improve Radeon performance or an i missing something?

The official OBS studio does not offer the screen sharing function in Wayland, and you need a special plugin obs-xdg-portal.

Unfortunately this is not the end of the story. This plugin was initially released mainly for demo purpose rather than for production use, and only the gbsneto/pipewire branch provides good performance. Not sure if Arch ships the latest version but in Fedora I have to build OBS from source (in flatpak, the rpmfusion one is broken from the beginning)