Announcement

Collapse
No announcement yet.

Mesa DRI PRIME Support Comes To Wayland

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

  • Mesa DRI PRIME Support Comes To Wayland

    Phoronix: Mesa DRI PRIME Support Comes To Wayland

    DRI PRIME that allows for secondary GPUs to provide rendering support to primary GPUs -- i.e. NVIDIA Optimus systems -- can now work under Wayland for allowing secondary GPUs to render games/applications even if they aren't the GPU used by the compositor...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Wayland > Mir

    Another nail in the Mir coffin.

    Comment


    • #3
      Originally posted by halfmanhalfamazing View Post
      Another nail in the Mir coffin.
      It begins.

      Comment


      • #4
        I hope there will be no tearing in prime windows, as it is in X.

        Comment


        • #5
          Little explanation



          If a drawing help understanding better the concept.

          The performance is the best for an application if it is above black arrows.
          Green arrows force the application above them to disable tiling, and the buffer location is shared between two card, in a location which can be slower to render to for a client.

          Instead of doing a hidden copy, which would make a client use black arrows, and the compositor receive green arrows,
          you use explicitly an embedded compositor to do this conversion when you want to use black arrows on a different card than the compositor.

          Comment


          • #6
            To get the id_path_tag associated with a graphic card, you need recent systemd, and the command:
            udevadm info /dev/dri/card0

            with /dev/dri/card0, the card you want to know the id_path_tag of.


            Originally posted by nslqqq View Post
            I hope there will be no tearing in prime windows, as it is in X.
            X dri2 prime support do not support vsync, which is used to reduce tearings in X.
            X dri3 prime support might improve that.

            Wayland can avoid tearings, even when the application doesn't use vsync (and all applications can use vsync, whatever they use to render)

            Comment


            • #7
              Fulscreen games handling

              Remember how Ryan Gordon proposed a new window manager hint for fulscreen games? This is very close to how I think it should be done, even for single-GPU systems ? I think the best solution would a some kind of fullscreen hint, that would cause a new compozitor to spawn with desired settings such as color depth and resolution, which would be responsible for running that application only.

              The great advantage of such solution is that it could newer mess your desktop. Now it sometimes happens that if a fullscreen application crashes, the desktop is left with whatever resolution the application was using (which means that eg. on KDE you may get you panels resized to fit the screen). And no, this is not just a plain "I told you so" post, I've actually proposed this on the wm-spec-list more than a year ago.

              Comment


              • #8
                Originally posted by stativ View Post
                Remember how Ryan Gordon proposed a new window manager hint for fulscreen games? This is very close to how I think it should be done, even for single-GPU systems ? I think the best solution would a some kind of fullscreen hint, that would cause a new compozitor to spawn with desired settings such as color depth and resolution, which would be responsible for running that application only.
                This has long been solved in SDL2 by using the FULLSCREEN_DESKTOP mode that basically resizes your window to the current desktop resolution and makes it fullscreen, which doesn't mess with the display mode at all. You just render to an offscreen buffer with the resolution the application expects, and do a scaled blit to the main framebuffer.

                Comment


                • #9
                  Originally posted by Ancurio View Post
                  This has long been solved in SDL2 by using the FULLSCREEN_DESKTOP mode that basically resizes your window to the current desktop resolution and makes it fullscreen, which doesn't mess with the display mode at all. You just render to an offscreen buffer with the resolution the application expects, and do a scaled blit to the main framebuffer.
                  Noob question here... does that interfere with Undirect Fullscreen Windows options we have in the likes of Compiz and Kwin etc? Because it feels like in Portal, HL2 etc that the compositor is still active (as tearing is eliminated even without vsync enabled ingame, but comes back if I disable the compositor). Those Source games run too fast/smooth for me to be able to tell any FPS impact.

                  Comment


                  • #10
                    Originally posted by ElderSnake View Post
                    Noob question here... does that interfere with Undirect Fullscreen Windows options we have in the likes of Compiz and Kwin etc? Because it feels like in Portal, HL2 etc that the compositor is still active (as tearing is eliminated even without vsync enabled ingame, but comes back if I disable the compositor). Those Source games run too fast/smooth for me to be able to tell any FPS impact.
                    I am not sure. In any way, the WM should be completely oblivious to this though, because it's really a SDL internal thing. To the WM it just looks like your fullscreen window is conveniently the same size as the current display mode.

                    Comment

                    Working...
                    X