Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread Martin van Es 
Hi Kevin,

Thx for your insightful reply!

On Thu, Jan 28, 2016 at 11:18 AM, Kevin Krammer  wrote:

> 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.
>
>
For laymen, like me, this is an unpenetrable labyrinth ;) although I try to
catch-up as you can see.


> Then my suggestion would be to use that for the time being :)
>

True, but my concerns were about being taken over by progress and KDE
developers not being aware their efforts cause harm in "the field"
currently.

Besides, there is a warning when enabling EGL in Compistor System Settings,
but it only warns about disabling compositor if EGL is not available. I
think a warning about maturity and stability would be appropriate?


> I think it is in Intel's best interest to provide a well working EGL way
> before GLX is being phased out.
>

You make it sound like it is the (lack of) maturity of Intel's driver
that's responsible for my experienced plasma's instabilities?
Is there no chance of it being buggy EGL implementation in plasma?


Best regards,
Martin
___
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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread 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


signature.asc
Description: This is a digitally signed message 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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread Kevin Krammer 
On Thursday, 2016-01-28, 10:52:32, René J.V. Bertin wrote:
> I'd add one (or rephrase): is eye-candy more important than supporting
> anything but the most recent hardware.

That's and othrogonal question as both mentioned access technologies provide 
the same thing, which can the be used for the same things.

It is hard to find good analogies for technologies such as these, but a very 
rough one would be different means to transform electrical power from a 
powerline to be suitable for an eletronics device: what kind of eletronics you 
power is mostly independent on how your power adapter transformed between the 
source and the target voltage.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message 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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread René J . V . Bertin 
On Thursday January 28 2016 10:04:22 Martin van Es wrote:

>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'd add one (or rephrase): is eye-candy more important than supporting anything 
but the most recent hardware. And that is ultimately a question about the 
targeted user population. Is it first and foremost a toy for KDE devs 
themselves and the Phoronix-fanboy category of users, or does it seriously aim 
to provide a desktop alternative for people who use Linux to get their work 
done (and thus need a stable, feature-rich and self-effacing desktop that 
doesn't get in the way)?

R.
___
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.

[kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread Martin van Es 
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).

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.

https://blog.martin-graesslin.com/blog/2015/08/should-we-target-egl-as-the-default/

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

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

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?

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?

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator
___
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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread Kevin Krammer 
Hi Martin,

On Thursday, 2016-01-28, 11:45:09, Martin van Es wrote:
> Hi Kevin,
> 
> Thx for your insightful reply!

Thanks, but I don't really have that much insight myself really :)

> On Thu, Jan 28, 2016 at 11:18 AM, Kevin Krammer  wrote:
> > 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.
> 
> For laymen, like me, this is an unpenetrable labyrinth ;) although I try to
> catch-up as you can see.

Since this whole area isn't something I deal with myself, I also only have a 
very high level view on things.

In a lot of these cases a "new thing" is most often not a replacement for 
something, but a specialization for a certain group of use cases.

E.g. in the case of Vulkan, it mostly targetting developers who provide 
graphics middleware for application developers, like game engines or like Qt's 
QtQuick.
The "old" technology, in this case OpenGL is still the thing application 
developers will use when they are not using any of these middlewares.

We see these kinds of "new lower level" all over our software stacks, when 
things that traditionally have been done by every single application developer 
are now taken care of by dedicated library/framework developers, who can be 
bothered with more complexity or require deeper understanding but will get 
better control or more options in return.

> > Then my suggestion would be to use that for the time being :)
> 
> True, but my concerns were about being taken over by progress and KDE
> developers not being aware their efforts cause harm in "the field"
> currently.
> 
> Besides, there is a warning when enabling EGL in Compistor System Settings,
> but it only warns about disabling compositor if EGL is not available. I
> think a warning about maturity and stability would be appropriate?

EGL has been around for quite some time already (more than a decade, EGL 1.0 
is from 2003) and has become *the* OpenGL system integration on basically any 
platform.

So it is certainly mature and considered stable (the newest version is about 
two years old) as a technology, but each vendor's implementation might not or 
might even change.

> > I think it is in Intel's best interest to provide a well working EGL way
> > before GLX is being phased out.
> 
> You make it sound like it is the (lack of) maturity of Intel's driver
> that's responsible for my experienced plasma's instabilities?

I am only guessing based on having to enable something that is not a default 
yet.
It could very well be that Intel changed its implementation to require newer 
internals, i.e. older drivers providing EGL on top of DRI2 but currently 
transitioning to DRI3.

> Is there no chance of it being buggy EGL implementation in plasma?

I don't know enough to rule things out, but as far as I understand EGL's role 
is very limited from the application developer's point of view.
It is basically just one of the ways to get OpenGL set up for work, the code 
that the developer then writes is the same as if they had used GLX for the 
base setup.

It is just more likely that the EGL implementations, e.g. the one provided by 
the Intel, are updated more often than the respective GLX implementation and 
thus prone to bugs caused by change rather than being new.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message 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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread René J . V . Bertin 
On Thursday January 28 2016 13:13:50 Kevin Krammer wrote:

> > Besides, there is a warning when enabling EGL in Compistor System Settings,
> > but it only warns about disabling compositor if EGL is not available. I
> > think a warning about maturity and stability would be appropriate?
> 
> EGL has been around for quite some time already (more than a decade, EGL 1.0 
> is from 2003) and has become *the* OpenGL system integration on basically any 
> platform.

Where does OpenGL ES fit in here (if it fits in at all)?

R
___
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.

Re: [kde] The current state of EGL in KDE/Plasma

2016-01-28 Thread Kevin Krammer 
On Thursday, 2016-01-28, 13:22:18, René J.V. Bertin wrote:
> On Thursday January 28 2016 13:13:50 Kevin Krammer wrote:
> > > Besides, there is a warning when enabling EGL in Compistor System
> > > Settings,
> > > but it only warns about disabling compositor if EGL is not available. I
> > > think a warning about maturity and stability would be appropriate?
> > 
> > EGL has been around for quite some time already (more than a decade, EGL
> > 1.0 is from 2003) and has become *the* OpenGL system integration on
> > basically any platform.
> 
> Where does OpenGL ES fit in here (if it fits in at all)?

That, again to my non-expert understanding, is a variant of OpenGL.
Something a developer would use for rendering, like "Desktop" OpenGL itself, 
but originally targetted at embedded/mobile devices, e.g. reduced but modern 
feature set.

It is used on top of the platform integration like "Desktop" OpenGL, i.e. a 
developer would equally be using EGL or GLX for getting the "thing to render 
to" but then using different calls to do the rendering.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message 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.