The current state of EGL in KDE/Plasma

[Kevin Krammer]

Hi Martin,

On Thursday, 2016-01-28, 10:04:22, Martin van Es wrote:
> Hi,
> 
> I want to raise a question about the current state of EGL in plasma? I ask,
> because recenlty I've been experiencing severe instability issues using
> EGL, although I was under the impression that EGL was "the way forward"?
> (It turned out "Vulcan" is, but that's a different story).

Different things really.

EGL is a means of getting OpenGL integration with the system, basically one 
option of the system specific bits and pieces below the cross platform OpenGL 
API.

Vulkan is a low level API for having graphics hardware do stuff, mostly for 
doing hardware accelerated graphics.

So EGL is to OpenGL what Vulkan WSI (window system integration) is to Vulkan, 
the connector between the things that are system specific to the things that 
are the same across systems.

GLX, as mentioned later, is another one of these, for systems that run X.

> After Googling around for the differences between GLX and EGL I came to the
> conclusion that besides EGL being newer, it is the only road to wayland and
> thus worth the switch.

Right. GLX is tied to X while EGL can be used on an X server based system but 
can also be used with just a framebuffer or Wayland or Mir or SurfaceFlinger 
(and the respective technologies on non-Linux platforms).

> https://blog.martin-graesslin.com/blog/2015/08/should-we-target-egl-as-the-d
> efault/
> 
> However, to use EGL reliably I had to enable DRI3 in my intel driver.
> 
> https://bugs.kde.org/show_bug.cgi?id=352427
> 
> This works, but results in many faced strange lockups (greeter locks up,
> chrome locks up, external monitor disconnect is instable etc.).

Change in software usage patterns often leads to discovery of until then 
hidden problems.
Code paths in the drivers and libraries that have previously not or only very 
selectively been exercised get used more for a wide range of values and system 
states and can exhibit faulty behavior that has so far been unknown.

> I attributed these problems to my unresponsible need for cutting edge
> plasma packages using kubuntu-backports and a composited desktop. But since
> changing back to GLX/DRI2 I have yet to see any problems. My desktop is as
> stable as it ever was under 4.*

Then my suggestion would be to use that for the time being :)
E.g. I am using the XRender backend for historic reasons and I personally 
don't see any cause for changing it as long as it works.

> In hindsight, having to deliberately enable DRI3 in xorg.conf for my intel
> GPU should have been a sign on the wall that it might not be ready yet?

Indeed, Intel probably thinks it needs more time to make that the default.

> So, my questions are: what's KDE's offficial stand on EGL? Is Martin
> (Graesslin)'s Blog still valid? Should we be worried GLX will be deprecated
> before intel driver is ready for DRI3 by default? Should we worry about
> wayland integration on intel hardware? Is EGL a dead end, etc. etc?

I think it is in Intel's best interest to provide a well working EGL way 
before GLX is being phased out.
GLX is basically only relevant for desktop Linux, while EGL is also needed for 
any Intel based Andriod systems, embedded Linux and for non-Linux on Intel 
where OpenGL is required (but Intel doesn't share any code between e.g. Linux 
and Windows drivers, so EGL improvements on another platform won't help much).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20160128/bdd29f0c/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.