Remote display with 3D acceleration using Wayland/Weston

[Christian Stroetmann]

On19.Dec.2016 09:48, Pekka Paalanen wrote:

> On Fri, 16 Dec 2016 11:35:48 -0600
> DRC<dcommander at users.sourceforge.net>  wrote:
>
>> On 12/16/16 3:06 AM, Pekka Paalanen wrote:
>>> I should probably tell a little more, because what I explained above is
>>> a simplification due to using a single path for all buffer types.
>>> ...
>> Thanks again.  This is all very new to me, and I guess I don't fully
>> understand where these buffer types would come into play.  Bearing in
>> mind that I really don't care whether non-OpenGL applications are
>> hardware-accelerated, does that simplify anything?  It would be
>> sufficient if only OpenGL applications could render using the GPU.  The
>> compositor itself doesn't necessarily need to.
> I do not know of any OpenGL (EGL, actually) implementation that would
> allow using the GPU while the compositor is not accepting hardware
> (EGL-based) buffers. The reason is that it simply cannot be performant
> in fully local usage scenario. When I say this, I mean in a way that
> would be transparent to the application. Applications themselves could
> initialize GPU support on an EGL platform other than Wayland, render
> with the GPU, call glReadPixels, and then use wl_shm buffers for
> sending the content to the compositor. However, this obviously needs
> explicit coding in the application, and I would not expect anyone to do
> it, because in a usual case of a fully local graphics stack without any
> remoting, it would make a huge performance hit.
>
> Well, I suppose some proprietary implementations have used wl_shm for
> hardware-rendered content, but we have always considered that a bug,
> especially when no other transport has been implemented.
>
> A bit of background:
> http://ppaalanen.blogspot.fi/2012/11/on-supporting-wayland-gl-clients-and.html
>
> Oh, this might be a nice reading before that one:
> http://ppaalanen.blogspot.fi/2012/03/what-does-egl-do-in-wayland-stack.html
>
>>> Lastly, and I believe this is the most sad part for you, is that NVIDIA
>>> proprietary drivers do not work (the way we would like).
>>>
>>> NVIDIA has been proposing for years a solution that is completely
>>> different to anything explained above: EGLStreams, and for the same
>>> amount of years, the community has been unimpressed with the design.
>>> Anyway, NVIDIA did implement their design and even wrote patches for
>>> Weston which we have not merged. Other compositors (e.g. Mutter) may
>>> choose to support EGLStreams as a temporary solution.
>> I guess I was hoping to take advantage of the EGL_PLATFORM_DEVICE_EXT
>> extension that allows for off-screen OpenGL rendering.  It currently
>> works with nVidia's drivers:
>> https://gist.github.com/dcommander/ee1247362201552b2532
> Right. You can do that, but then you need to write the application to
> use it...
>
> Hmm, indeed, maybe it would be possible if you are imposing your own
> EGL middle-man library between the application and the real EGL library.
>
> That's definitely a idea to look into. I cannot say off-hand why it
> would not work, so maybe it can work. :-)
>
> To summarize, with that approach, you would have the client send only
> wl_shm buffers to the compositor, and the compositor never needs to
> touch EGL at all. It also has the benefit that the read-back cost
> (glReadPixels) is completely in the client process, so the compositor
> will not stall on it, and you don't need the stuff I explained about in
> the compositor. And you get support for the proprietary drivers!
>
> Sorry for not realizing the "wrap libEGL.so" approach earlier.
>
>
> Thanks,
> pq
>

Yeah, and how does this look like when put in context with Waltham?



Regards
Christian Stroetmann