Re: An EGLStreams backend for KWin

Hi Roman,

Sorry for taking a while to follow up. I'm looking forward to working with the 
community on this and am glad the response sounds generally receptive. See 
inline for some responses to your questions.

On Tuesday, November 13, 2018 12:23:58 AM UTC Roman Gilg wrote:
> On Mon, Nov 12, 2018 at 10:44 PM Erik Kurzinger <[email protected]> 
wrote:
> > Hi Everyone,
> > 
> > ...
> > 
> > Cheers,
> > Erik
> 
> Hi Erik,
> 
> thanks for the heads up and in general thank you and Nvidia for
> contributing to KWin. I'm looking forward to you sharing the code.
> 
> One aspect to not forget is that our current screen sharing solution
> in KWin/KWayland is based on GBM buffer sharing (and subsequent
> Pipewire). So long-term there needs to be an additional code path for
> EGLStreams or a replacement in some way.
>
> Short-term there are currently some soon to be merged patches
> abstracting DrmOutput properties onto an higher level
> (https://phabricator.kde.org/D16794). They don't touch the GBM/EGL
> code paths very much and are probably therefore not that relevant to
> your EGLStreams implementation, but better still take a look to make
> sure you don't need to do large changes to your branch after they
> landed.
> 
> At the end some questions:
> 
> Do you and Nvidia plan on maintaining the EGLStreams code path
> afterwards? This does not mean it's all upon you then, just if you
> will be still around after the code has been merged. In the past there
> were some Nvidia-specific issues with KWin on X, which took way too
> long to be fixed. So more contributions by Nvidia engineers would be
> very welcomed.
> 

We definitely don't intend to abandon KDE after this work is done. We'll be 
willing to triage any non-trivial bug reports related to the new code path 
going forward, and of course will still be looking into NVIDIA-specific issues 
in general as they come up. We know that historically there have been some 
stability issues with our driver and KWin but we're interested in working 
toward improving things.

> At some point we want to implement multi-GPU support in our Wayland
> session. Is this with EGLStreams still possible? I.e. to drive an
> Nvidia card together with an Intel or AMD graphics chip?
> 

We'd need to know more about your planned design.  I imagine going from 
NVIDIA -> AMD / Intel there would necessarily be a copy that would have to run 
on our GPU to get the data from the stream to a GBM buffer on the AMD / Intel 
side for compositing if the AMD / Intel card was driving a given Wayland 
output, and vice-versa if the NVIDIA card is driving the output, but we should 
be able to architect something that allows that with some forethought.

> Is Nvidia despite EGLStreams then being available in KWin and Mutter
> still willing to look into creating a cross-vendor solution, which is
> attractive to Mesa based drivers as well? Competing APIs can be a good
> idea from time to time to drive progress, but on a larger time scale
> converging to a unified solution is also important. I'm asking this
> because at XDC this year there was no new info about the Unix Device
> Memory Allocator library, which had been proposed by Nvidia at some
> point in the past.
> 

James Jones is our engineer primarily driving this effort and while he's not 
actively working on it at the moment, we're still interested in developing a 
unified solution and intend to resume progress one a few other projects are 
wrapped up.

We don't think we're ready to commit to a timeline yet, but acknowledge that 
it's taken longer than perhaps initially hoped. That's mainly what has raised 
the priority of this EGLStreams KWin backend so at least our KDE-using 
customers aren't totally left hanging in the meantime.

> Cheers,
> Roman





-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------