Mesa DRI PRIME Support Comes To Wayland

[phoronix]

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

[halfmanhalfamazing]

Wayland > Mir

Another nail in the Mir coffin.

[ElderSnake]

Another nail in the Mir coffin.

It begins.

[nslqqq]

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

[mannerov]

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.

[mannerov]

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.

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)

[stativ]

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.

[Ancurio]

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.

[ElderSnake]

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.

[Ancurio]

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.