When we started the compositing work in KWin the only way to initialize an OpenGL context was by using GLX. In fact GLX is even part of the OpenGL library on Linux. Being an X11 window manager and an X11 compositor it was not a big problem.
Years later we started the effort to get KWin using optionally OpenGL ES in addition to normal OpenGL. One of the differences is that OpenGL ES doesn’t use GLX, but rather EGL. So we gained code to setup compositing using EGL. But this was still a compile time switch and only supported together with using OpenGL ES. If I remember correctly the option to create on OpenGL context on top of EGL was not yet available in our drivers back then.
But there was a time when the FLOSS drivers started to support it and since the 4.10 release in beginning of 2013 we can provide a normal OpenGL context over EGL. This option was not really exposed and only bound to an environment variable. Very few users knew about it and this was also wanted. Using EGL was a good way to shoot yourself in the foot given that not all drivers support it and that we had much more testing on the GLX backend.
Now the situation has changed. With 5.x we expose EGL also through a config interface, but more importantly EGL is the only way to get OpenGL on Wayland. The assumption that every user is using GLX doesn’t hold any more. The assumption that we don’t need to spend so much time (as it’s only relevant in the reduced feature set of mobile devices) on the EGL backend is wrong. It must reach the same quality as the GLX backend, otherwise our Wayland experience suffers.
So this raises an important question: should we try targeting EGL as the default? In the past one of the main reasons to not even think about EGL as default is the reason that the NVIDIA driver didn’t support it. If we would have switched to EGL by default it would have meant dealing with the situation that EGL doesn’t work and we need to fall back to GLX. It would have complicated the startup significantly and would have resulted in our user base using different rendering paths.
Now this one road blocker seems to resolve itself. While I haven’t tested it yet, the latest NVIDIA beta driver supports OpenGL over EGL, so we should be able to have the majority of our user base on the same backend after all. Given that it is only a beta driver and the feature is marked as “experimental” it’s probably still some time till we can default to it.
Nevertheless it’s time to start thinking about it. I encourage NVIDIA users to give EGL now a try and to report issues. Also I encourage all other users to report issues they see with the EGL backend. If we get the EGL backend into a good state maybe 5.6 might be a good point in time to default to it and then start to slowly deprecate the GLX backend with the aim to get it removed in the distant future.
Without looking at the question too hard, does the userbase relying on nvidia-legacy drivers for old hardware support complicate the issue of migration? Perhaps these people should be using nouveau, but at the same time there are plenty of machines with more than enough graphics grunt to run a desktop for a relative using email that are on legacy drivers list now.
well for them we need to keep the option of using GLX. But old hardware goes away, we dropped for example ATI r300 support with 5.x without two many problems. In the end we always have XRender support to fallback to.
Woah! What do you mean you dropped r300 support in 5.x?
The previous statement I saw was that OpenGL 2 was required, the OpenGL 1.x compositing support was gone in KWin5. That said nothing about r300 and now I wonder what the real requirements are. r300 hardware supports OpenGL 2.1 and is still widely used. Not only in many still good laptops but also in many alternate platforms where Randon was the default or only choice. These are all systems where GPU replacement is not practical.
I have not tried KDE5 yet but I guess I won’t need to bother. If it’s dropping everything then maybe it’s time to switch to Enlightenment. I can’t fathom why the “modern” UI that looks so 80s suddenly needs top of the line hardware. Come on, you can draw flat color boxes with 90s hardware faster than some of these new GPUs that lack a 2D engine.
What are the real hardware requirements for KWin5?
No, the r300 does not support OpenGL 2.1 fully, see https://wiki.freedesktop.org/xorg/RadeonFeature/#note_16 – that requirement is biting us. It’s extremely difficult to test whether our code supports this feature or not as you cannot install r300 based cards into modern systems any more. It’s not like we purposely break the feature, it’s just impossible to test and fix if we broke it.
Overall I don’t think it’s our job to ensure that new software is working on old hardware. Plasma 5 is the second generation of KDE software released after r300 ended. At some point it’s no longer feasible to keep support up for it.
But of course: if you want to use the system without OpenGL you can do so.
I’m KDE4 user and I have GeForce 7025 / NVIDIA nForce 630a (officially this model supports OpenGL 2.1). This is legacy graphics card (8 year old). I don’t work comfortable with Plasma 5. Driver nouveau made on my hardware crash entire of system (when Plasma is starting – tested in NetRunner, Kubuntu), so from my point of view (using Plasma 5) its support of legacy graphics cards is very poor. Of course it works in other DE. Using XRender in Plasma 5 I have about 80% usage for 2 cores (from 4) even if I do nothing. OK. There is only working plasmoid watching cpu usage. Anyway Plasma5 is even responsible in this case, but I don’t need heater in my PC :/. Problem reported here: http://kaosx.us/phpBB3/viewtopic.php?t=1027
About support of EGL in my drivers I can only dream (and never get). Mentioned nvidia driver version 355.6 beta is not intended for legacy hardware like mine.
So what choice I have to be able enjoy Plasma 5? Buy new graphics or move to newer Intel platform?
I’m sorry, but I doubt that we still support 8 year old hardware. I doubt you would be able to run Windows 10 on that either. Sorry about that, but that’s just old.
Actually, Windows 10 does _appear_ to support that graphics card, and its minimum requirements match even CPUs from 10 years ago. (Desktop computers have been good enough to match our needs for the last 10 years, and probably will be good enough for the next decade, now that sequential performance has stalled — there’s now much less of a reason to upgrade.)
Source: http://www.microsoft.com/en-us/windows/compatibility/CompatCenter/ProductDetailsViewer?Type=Hardware&Name=Nvidia+GeForce+7025+nForce+630a+Graphics+Card&ModelOrVersion=&Vendor=NVIDIA&Locale=1033%2C2057%2C3081%2C4105%2C16393&LastSearchTerm=nvidia&BreadcrumbPath=nvidia&TempOsid=Windows+10
Sorry, but this is not the issue how old is my graphics, but what standard it supports. I mean OpenGL and closed drivers from NVIDIA. As far as I know it supports OpenGL in version 2.1 –
https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units
As mentioned “woah there” it was required for Plasna 5.
And based on drivers in version 304.108 (latest is 304.125, but I found link referring only this version) OpenGL 2.1 is almost fully supported:
http://feedback.wildfiregames.com/report/opengl/device/GeForce%207025%20/%20nForce%20630a
There are missing following 2 features:
– GL_WIN_swap_hint
– WGL_EXT_swap_control
I assume that the list OpenGL functions given on above site is completed.
Is this the reason that I meet low performance?
And by th way. When I select OpenGL 2.x in settings of Plasma (I guess it’s referring Compositor) then I get the same high CPU usage. OK now is a bit better. Yesterday I was testing Plasma 5 in Kubuntu 15.04 with latest updates (including Plasma 5.3.2) and only one core was loaded with about 80%, other with a couple or a dozen percents, but still this is not acceptable. In KDE 4 in the same situation a have max 1-2% overall load.
I don’t care the Windows 10 and I’m not going to work with this system. OK, to be honest in my job I have to work, because I don’t have other choice, but In home I have, and I choose Linux with KDE 4, so I work on it and use to entertainment. And reading below post from Anon you might to be wrong.
Please note that the high CPU issue might just be a bug and not a “hardware requirement”.
The problem has been fixed in Plasma 5.4 (actually this happened in 5.3.95). Process plasmashell is using about 1% CPU. Hence I’m very happy :). Now I can think about using new Plasma every day and no worries about buying new graphics. 🙂
Tested in Kubuntu 15.04 with latest updates and Mageia Cauldron (unstable Mageia).
You can probably get a new (and much better) graphics card for 30 to 50 EUR now. You might even get one with passive cooling!
So there is a relatively inexpensive solution for legacy HW 😛
It’s not an option for many laptops with integrated GPU’s that still working great with real life tasks and not going to die anytime soon. In my case there is two laptops with 7300/7400 Go that work fine with nouveau but only in EGL mode coincidentally. GLX mode just gives frozen picture on display as soon as compositing get enabled, that probably some regression in the driver (as I remember GLX works fine on this GPU’s few years ago with nouveau). Unfortunately, nouveau have another issue with this GPU’s – broken support for external displays attached via VGA (in my case – projector attached via VGA).
Well, on first laptop I have to use nvidia 304 (newer releases doesn’t support 7300/7400 Go; sad story by the way, with 304 there is unresolved tearing issues) because Gnome Shell uses GLX and I doesn’t know how to switch it to EGL (hopefully I could get rid of nvidia driver on this laptop as soon as Gnome Shell will be stable enough in Wayland session). On second laptop with KDE I have to use nvidia driver because this laptop is used with projector attached VGA (this projector has no digital inputs, just VGA, S-Video, etc.).
I huge nouveau proponent, but sometimes using it just not an option. Just like replacing GPU. If that would be possible I obviously would replace it with Radeon.
Yes you can get a GT 210 for 25 € and a GT 610 for 34 €. I bought my dad a 210, because he also had an old NVIDIA 7025 in his PC and couldn’t upgrade to Windows 10.
Yes. You are right. I can, but why I need to spend money for new graphics card to work in new desktop? This is only desktop. I don’t play, I’m programmer amateur (not games) using Qt, so I don’t need high performance for graphics. I would rather buy new CPU.
BTW. Turning off compositor effects nothing change.
And what is minimum requirement for graphics card to be able to run Plasma 5 without high load of CPUs?
It’s not matter anymore. I found GT210 even for 20€. So when I really need to work with Plasma 5 then I just buy it. In this moment KDE4 is enough.
And If adaptation Plasma 5 to be able work with legacy graphics cards is a problem then better would be that developers will focus on stability and better EGL support.
Remove the paperweight from your machine and use LLVMpipe.
The problem is that llvmpipe also needs rather “new” hardware. SSE4 extension, ideally multiple cores. Mostly if the GPU is too old, the CPU is also to old to provide a decent experience with llvmpipe. It’s a nice solution if you have a new system and drivers are still lacking or you don’t want to use proprietary drivers.
Maybe a bug report would be a better place to put this, but on my hardware, EGL gives more more trouble than GLX.
I’m running Fedora 22, with latest updates, running the version of KDE 5 that comes with that distro (I think it’s 5.3). I have a haswell desktop and an Arrandale laptop.
On both machines, EGL has re-painting issues. Often the K menu will not update properly, without hovering the mouse over specific menu items, if you just scroll parent menus, they children don’t get repainted properly. If I switch back to GLX that goes away.
The other culprit is Google Chrome, often entire tabs will not repaint properly unless you keep switching them or their contents change, so you can have half the page repaint and half doesn’t.
EGL Should probably eventually be the default, but from my experience it’s still a bit buggy. Assuming it’s not the Intel drivers that’s to blame.
Perhaps the appropriate place for this discussion will be the bug tracking system but I think the issue you’ve reported is rather new – I used to use OpenGL ES on KDE 4.XX and for a time on plasma and KDE frameworks 5 and it worked rock solid but about a month or so (I actually read an article where these issues were tracked to a specific update in the intel driver) I started experiencing the same problem. One fix seems to be to set the accelaration method to UXA instead of SNA (which is the default) and you will be able to use EGL (my current set-up). If you use SNA you will have to set KWIN to use GLX.
Regarding the topic – before these latest issues KWIN seemed to work really well using OpenGL ES in KDE 4.XX and using the EGL setting in 5.x. I can’t think of any major or minor issues. In fact when I used GLX I had a small issue with the tool-tips in System settings which flickered a lot when appearing while there were no problems if I used OpenGL ES/EGL. So from my (rather limited) experience I’d definately say that swithich to EGL will be a good idea (providing enough testing has been done).
Martin – since this is my first post on your blog I’d like to thank for the wonderfull job you’re doing. KDE is a joy to use and in no small part this is due to KWIN. And I also find the insight you’re providing in your blog very interesting.
I would also like to send my thanks to Martin for his work on Kwin. For the most part it works really well.
I had wondered if these were to do with the SNA issues which I’ve heard of. Do we know if these issues have been fixed yet in upstream, as for the most part, I’m willing to wait with GLX.
If this is what’s necessary to get Wayland into the mainstream, I think it’s a good idea.
The Nvidia 355.06 beta driver may have experimental support for EGL… but, most annoyingly, it does not expose the GL_OES_EGL_image, even if it implements it, so EGL is not currently an option for me, unfortunately… unless I use Nouveau, but it still seems rather lacking for high-end gaming. And I am not sure about it’s fan support, because my laptop has a poor air circulation design as it is.
I have posted on the Nvidia devtalk forums about this, in the meanwhile.
Regardless, keep up the great work, Martin! 😀
Maybe you could update the post with steps needed to be taken to test this?
I deliberately kept them out as I currently only want to target users who are able to handle problems well. That is they know which knobs to tweak 😉
Thanks for the update Martin. I’ll give the NVIDIA beta driver + EGL a spin later today.
YES.
I just tested plasma-desktop 5.3.2 on Arch Linux with the latest NVIDIA Beta driver. The only thing I notice when I switch between GLX and EGL for OpenGL 2.0 and 3.1 is that with EGL that is tearing when I move a window around. I also tried other Vsync methods and even with Fullscreen Repaint there is tearing when using EGL.
I just tried and I have the same issue, I’m on Arch Linux as well with the NVIDIA Beta driver. I see tearing when moving windows around with EGL.
I have just tried to test this on Kubuntu 15.10 – Nvidia 450 GTS, new beta driver
It did not work however, if I switch to EGL its goes to Xrender.
If I select EGL, then run in a console ‘kwin_x11 –replace &’ I get some feedback though.
I see -> kwin_core: Egl Initialize succeeded – kwin_core: EGL version: 1 . 4
but then -> kwin_core: Creating the OpenGL rendering failed: “Required extension GL_OES_EGL_image not found, disabling compositing”
Same as this person
https://devtalk.nvidia.com/default/topic/864738/355-06-does-not-expose-gl_oes_egl_image/
Is Nvidia not compatible with EGL using the new driver – 355.06 ?
EGL doesn’t plan nicely with the current nVidia driver:
kwin_core: Initializing OpenGL compositing
libEGL warning: DRI2: failed to authenticate
kwin_core: Egl Initialize succeeded
kwin_core: EGL version: 1 . 4
OpenGL vendor string:
OpenGL renderer string:
OpenGL version string:
OpenGL shading language version string:
Driver: Unknown
Driver version: 0.139.62576
GPU class: Unknown
OpenGL version: 0.0
GLSL version: 0.0
Linux kernel version: 4.1.3
Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: no
Virtual Machine: no
kwin_core: Creating the OpenGL rendering failed: “Required support for binding pixmaps to EGLImages not found, disabling compositing”
kwin_core: Failed to initialize compositing, compositing disabled
$ dmesg | grep NVIDIA
[ 2.567135] nvidia: module license ‘NVIDIA’ taints kernel.
[ 2.592943] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 355.06 Tue Jul 28 21:26:50 PDT 2015
By 5.6 what’re you referring to?
KWin’s version number
You can bind EGL_OPENGL_API as the current API for your thread, via the eglBindAPI(EGLenum api); a subsequent eglCreateContext will create an OpenGL rendering context.
https://bugs.kde.org/show_bug.cgi?id=345511
EGL still have problems.
@Martin
I really appreciate your work for Plasma 5. I think this is “a chunk of good work”. Keep it up!
I’m reading with interest each of your post on planetkde.org.
I was a bit disappointed that new desktop (Plasma) needs so good hardware. I hope there is not so many users with such old hardware like mine.
With Vulkan coming, there will be WSI integration for Wayland (to replace EGL). Do you have any plans for adding support for it to KWin? And are any compositor developers participating in the Vulkan Khronos group?
I have not yet looked at Vulkan and don’t have any plans for it in the near future. I do not know about other compositors.
I think Vulkan support will be deployed quite rapidly, i.e. it won’t take years, but literally months after it will be released this year, and it will be uniform on all drivers. So you probably should at least take a look at it when it will come out. WSI will be positioned as a replacement for EGL, and it’s probably a good idea for compositors to switch to it when it will come out it for two reasons.
First, WSI will be an uniformly implemented open API, i.e. there won’t be a need for Nvidia EGL, Mesa EGL, or etc. and all the mess that comes from the difference. WSI will be the same (and FOSS) across all drivers.
Secondly, Vulkan will offer better performance across the board, and especially on mobile it will result in better battery life which is I’m sure important for Plasma Mobile efforts which use KWin as well.
You can check out this presentation which mentions some plans for WSI and Vulkan:
http://www.ustream.tv/recorded/70729406
Watchable with mpv:
[code]mpv ‘http://www.ustream.tv/recorded/70729406′[/code]
I copied some slides relevant to KWin and Wayland here:
* https://i.imgur.com/ib2hyrd.jpg
* https://i.imgur.com/LJhMdFB.jpg
* https://i.imgur.com/kJCr8hE.jpg
I can’t of course evaluate your situation directly, but I’d say WSI will be a good option going forward.
I don’t think that Vulkan will provide any performance improvements for KWin. Why I think that should be clear in an upcoming blog post. Also I’m not thrilled at all at yet again another OpenGL version. I had too many incompatible changes over the last years, so I want to sit back and wait whether it’s a truly good thing or just like all the other iterations.
I’m sure reworking is not something to be thrilled about, but the benefit is huge – you get one implementation of Vulkan across all drivers. It literally will solve tons of nuanced differences which plague OpenGL at present. And all fixes will go to the same upstream, so it will improve for everyone at the same pace.
There is no point in assuming we can drop OpenGL in favor of Vulkan. Think of all the legacy drivers which will never get Vulkan.
I don’t think dropping OpenGL right away will be an option anyway, since Vulkan has recent minimal hardware requirements (to be precise, it needs hardware with compute shaders capabilities), and KWin is still used on some older hardware as well which doesn’t have those features.
So ideally both EGL/OpenGL and WSI/Vulkan can be supported. But eventually old hardware where Vulkan doesn’t run will become obsolete enough, then you can consider dropping EGL altogether, but I agree that it’s early for that yet.
Yes and so Vulkan gives us nothing except of lots of work. It would require a port of everything which is currently OpenGL to Vulkan. So more complexity, less shared code, etc. etc. And what do we gain? If we are honest: nothing, because those areas where Vulkan would be good, we don’t use anyway. Threaded rendering? Nice idea, KWin doesn’t use it. So what’s the point?
Firstly, why not start using threaded rendering? Secondly, on mobile Vulkan benefits are more apparent (as I said above), since it does offload the CPU more which results in noticeably longer battery life. I suppose mobile Wayland compositors like Lipstick used in Sailfish, which don’t need to worry much about legacy hardware support will want to adopt Vulkan as soon as it will come out.
Given that KWin on mobile is not widely used yet, that may be isn’t a big issue, but going forward I suppose it might be important.
Either way, OpenGL is being deprecated for Vulkan, so sooner or later switching to it makes sense. It’s a question of resources. If possible, I’d say it’s better to add WSI/Vulkan integration in KWin sooner, and those who can would benefit from it. But if it’s too much burden to maintain it (in addition to GLX/OpenGL and EGL/OpenGL), then it will have to wait.
Because it’s not a trivial task to make the renderer threaded 🙂
Who said we want to do OpenGL/Vulkan rendering in the compositor on mobile at all? Maybe it would be better to just always bypass the OpenGL compositor? More on that in a soon to be written blog post.
And thinking of it, since Vulkan is FOSS, it can be easily used and exposed in virtual GPU drivers (in VirtualBox, KMS and so on), as the same and standard implementation. So may be finally I’ll see KWin with proper compositing working in virtual machines 🙂
Sorry, I meant KVM specifically (more precisely Virgil3D driver and the like).
And by the way, I tried Plasma 5 with Nvidia closed driver and EGL in Debian testing, and apparently it failed to work properly. How exactly can I report bugs about it (i.e. where to look for logs and such).
Thanks!
I do not know how and where to report bugs for the proprietary driver.
By the way, I’m testing Plasma 5 / KWin with EGL on Intel / Mesa now, and it works very nicely!
Thanks a lot for your very informative posts, which constantly update us on your great work.
Now that Plasma 5.4 has been packaged by distros (I use Arch Linux), I gave EGL a try. My system is an Intel Haswell Desktop. EGL works quite good, except for a very annoying bug, which seems to affect other users, too:
https://bugs.kde.org/show_bug.cgi?id=351865
Maybe you might help identify which component is the culprit 😉
Is there any benefits of using EGL on X11 over GLX?
Actually I had to switch back to glx on intel since for some reason after a fedora update my panel fails to update with egl (clock stays same, new openened programs not appearing in taskbar, etc).
That, and kde deciding that suspending instead of disabling compositors for full screen came is the best way (which is not supported on intel, not that it actually tells you that clearly), actually made me disable compositing by default.
Do not take me wrong, I appreciate all the work that goes into this. But it just does not seem ready for broad usage…
This entry probably isn’t being read anymore, but just in case. Martin, you blogged a couple years ago about having a Sandy Bridge laptop, and I’m curious what knobs someone more informed than myself used. Did you set QT_OPENGL_NO_SANITY_CHECK? Disable SNA? Anything else? I only ask since using EGL works great on my Haswell desktop at the lab but is unusable on my Sandy Bridge laptop (frequent delays in rendering and items not being repainted).