Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by oleid View Post

    If I recall correctly, I installed some Gnome-shell plug in. Can look up its name, if you're interested.
    Originally posted by zxy_thf View Post
    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?

    Comment


    • #12
      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.

      Comment


      • #13
        Originally posted by brent View Post
        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.

        Comment


        • #14
          Originally posted by timofonic View Post
          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
          Code:
          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.

          Comment


          • #15
            Originally posted by ssokolow View Post

            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.

            Comment


            • #16
              Originally posted by zxy_thf View Post
              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
              Code:
              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.

              Comment


              • #17
                Originally posted by timofonic View Post

                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.

                Comment


                • #18
                  Originally posted by timofonic View Post



                  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.
                  Code:
                  $ 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
                  Last edited by oleid; 18 September 2020, 12:11 PM.

                  Comment

                  Working...
                  X