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...

    http://www.phoronix.com/vr.php?view=MTUwNzM

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


                    • #11
                      Originally posted by Ancurio View Post
                      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.
                      That's another reason why I think it should be done using a separate compositor, because drawing of a desktop can be completely suspended in the "main" compositor (therefore it wouldn't affect the performance at all). The other thing is that the SDL approach will likely require scaling even for native screen resolutions, eg. if I have a desktop that is 1680x1050 and I run a game in 640x480, the game will be rendered in 640x480 and then upscaled to fit 1680x1050, even though the screen can handle 640x480, which means a performance loss (small one, but still...). You can try to look up that ML message, I think I wrote all of this there.

                      Comment


                      • #12
                        Originally posted by stativ View Post
                        The other thing is that the SDL approach will likely require scaling even for native screen resolutions, eg. if I have a desktop that is 1680x1050 and I run a game in 640x480, the game will be rendered in 640x480 and then upscaled to fit 1680x1050, even though the screen can handle 640x480, which means a performance loss (small one, but still...). You can try to look up that ML message, I think I wrote all of this there.
                        Of course, as the logical size you're rendering at and the actual framebuffer size will differ, you'll need to upscale the final frame, but with modern cards this isn't really a very costly operation (especially considering you can straight up skip the fragment pipeline on modern drivers). Another reason why this is very nice is because you can just Alt-Tab to messenger windows, web browsers etc. without having your monitor going through a mode switch every single time.

                        Comment


                        • #13
                          /OT

                          I've always found that weird, alt-tabbing away to something. When I play, I play - it means at least 2 hours of dedicated gaming time with zero distractions, preferably more.

                          Perhaps needing to check something in the middle is a symptom of ADHD?

                          Comment


                          • #14
                            Originally posted by curaga View Post
                            /OT

                            I've always found that weird, alt-tabbing away to something. When I play, I play - it means at least 2 hours of dedicated gaming time with zero distractions, preferably more.

                            Perhaps needing to check something in the middle is a symptom of ADHD?
                            I certainly won't sit there for 5 minutes and stare at the screen while Dota2 is searching for a match.

                            Comment

                            Working...
                            X