Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Mesa DRI PRIME Support Comes To Wayland

  1. #1
    Join Date
    Jan 2007
    Posts
    13,474

    Default 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. #2

    Default Wayland > Mir

    Another nail in the Mir coffin.

  3. #3
    Join Date
    Apr 2012
    Posts
    229

    Default

    Quote Originally Posted by halfmanhalfamazing View Post
    Another nail in the Mir coffin.
    It begins.

  4. #4
    Join Date
    Feb 2013
    Posts
    16

    Thumbs up

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

  5. #5
    Join Date
    Dec 2012
    Posts
    136

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

  6. #6
    Join Date
    Dec 2012
    Posts
    136

    Default

    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.


    Quote 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)

  7. #7

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

  8. #8
    Join Date
    Aug 2011
    Posts
    434

    Default

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

  9. #9
    Join Date
    Apr 2012
    Posts
    229

    Default

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

  10. #10
    Join Date
    Aug 2011
    Posts
    434

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •