Some days ago I prepared a patch which moves the decision which compositor to use inside the driver detection code. This allows us to remove hacks we currently have inside the compositor initialization code to move specific drivers (e.g. the software rasterizer) to a better suited compositor. The base idea is that we always give a user the compositor which is best suited for her system. It’s in my opinion not a good idea to push users on the OpenGL 2 compositor, just because the hardware supports the required extensions, if we know that the hardware is actually not capable of performing well. For such users the OpenGL 1 based compositor is better suited or maybe even the XRender based compositor.
As well for rather old hardware it’s a better idea to not provide any OpenGL based compositing even if theoretically the driver supports it.
But automatism is not always the best solution. Yes giving from experience the best suited compositor is a good idea, but still it makes sense to allow the user to overwrite it. In this case the “user” is mostly myself and other developers who have to be able to easily switch the compositor. For me this is most easily done using an environment variable as I am restarting KWin all the time anyway and is faster than going into a UI and changing the settings and afterward changing them back. Of course although this is controlled through an environment variable, there are also settings to control the chosen compositor. E.g. you can select XRender or disable the OpenGL 2 based compositor. But there is no UI option to enforce the OpenGL 2 compositor if our driver recommendation is to use OpenGL 1 or XRender (we don’t want to provide users the option to destroy their system).
One of the side-effects of this driver based recommendation is that the hack to switch to XRender for software based rasterizers has been removed in the patch. Instead these drivers now recommend to use the XRender based compositor. And in combination with the changes in the handling of the KWIN_COMPOSE environment variable this results in the possibility to run OpenGL based compositing with the llvmpipe driver.
But as you can see one has to manually enforce it through an environment variable and I would not recommend anybody (or any distribution) to use it. OpenGL based compositing over llvmpipe is considered as a fallback approach for other OpenGL based desktop environments like GNOME Shell and Unity. But I do not consider it as a solution for the KDE Plasma Workspaces. I think we have better solutions for fallback (XRender or no compositing).
Let’s have a look on the use cases for llvmpipe based compositing:
- Outdated hardware not providing OpenGL
- Too new hardware without driver yet
- Embedded hardware without driver yet
- Virtual machines
- RMS not like binary drivers
If your hardware is too old to provide the requirements for OpenGL based compositing, it is quite likely that your CPU is also rather old. We can assume a single-core CPU of either the Pentium era or an early Atom. You don’t want your CPU which is not suited for this task to spend all the time rendering the desktop. If I enable llvmpipe for KWin on my system (quad core) it puts about one core under full steam.
The case that there is new hardware without drivers available on Linux has luckily become a very rare case. Basic modesetting support for NVIDIA’s latest hardware (Kepler) was available on the same day as the announcement of the hardware. And the blobs do support also their latest hardware. So in most cases all that is needed is installing the latest driver or upgrading the distribution. If you spend lots of money for new hardware you probably want to use it and not have the CPU emulate what your expensive hardware is supposed to do.
In the case of embedded hardware it’s unfortunately still rather common that there are no drivers available. But ARM based systems are also not known for having extreme power. If you don’t want your high-end system to use llvmpipe based OpenGL compositing you even less want your low-end system to do it. You bought your Raspberry Pi hopefully for more useful things than running at full-steam to render the desktop.
If you run a virtual machine your resources are rather limited. It needs to share the resources with other virtual machines and your host system. If you run in a cloud you probably don’t want to pay for rendering the desktop through llvmpipe. You have a task to solve and the more CPU that task gets the less you have to pay. In case of a local system you also don’t want to have the virtual system run at full-steam just to render the desktop. There are really better things to do with a VM.
Last but not least there are the users who don’t want to run binary drivers. Sorry I cannot help you there. If you really think you want to spend lots of money for hardware that you don’t use, that’s fine with me. But I would suggest to only buy hardware which has free drivers available and there are nowadays options from all of the three big GPU providers.
Overall we see that llvmpipe as a backend for OpenGL based compositing is actually not needed in the case of the KDE Plasma Workspaces. We have working fallbacks like XRender or no compositing at all and those do not put the system under full-steam.
Given that I am not considering to turn llvmpipe into an option for KWin. I think that most users who would need llvmpipe are better suited with XRender based compositing even if a few effects are missing then. For me as a developer on the other hand llvmpipe is a very interesting target as it can help to optimize our rendering stack.
Of course what I considered in this blog post is only relevant for OpenGL based compositing of the KDE Plasma Workspaces. We do have proper fallbacks like XRender or no compositing which is not available in other environments which decided to use llvmpipe as a fallback. They have to do a different evaluation and I cannot provide it for them as my evaluation result would be: use KWin 😉
Just as a tangential comment: there are artists like David Revoy who have started to use kde especially because it’s the only modern window manager that has a non-opengl option. They feel, whether they are right or not, that their opengl-based apps like blender and krita lose performance when running on an opengl-compositor based window manager.
they are right on that one. Running an OpenGL based compositor introduces quite some overhead especially when running an application which really needs the GPU. That’s what I discussed in my posts about benchmarking compositors with OpenGL games – proper solution: turn it off
http://gifs.gifbin.com/1233928590_citizen%20kane%20clapping.gif
3 days ago I had to repair a laptop, the Master Boot Record had some problems.
I knew that Gnome has a nice “Disk” tool that can rewrite the MBR.
First, the laptop configurations:
Intel Core 2 Duo 2.2 GHz, 2 GB Ram, Integrated Video.
I decided to put Ubuntu 12.10 beta2 on a stick and to boot it and use the Disk tool from there. The background had some serious artifacts while the launcher loaded OK. It was lagging very bad, I managed to open in a few minutes the application but it wasn’t rendering normally, I was seeing some randomly placed small gray squares without the window decorations. It wasn’t looking like a window, I just imagined that it should be the application.
Then I decided to download Ubuntu 12.10 the gnome-shell remix. Gnome-shell was lagging a bit but at least it was usable, opened the Disk application and the same artifacts… No window decoration, just some gray squares.
I managed to repair the MBR, he had Windows 7 installed, I booted in it and it was working all good with Aero activated…
I had a worse laptop a year ago and it was running KDE 4.7 just great…
For what it’s worth, you can install gnome-disk-utility on a live session of Kubuntu 12.10 beta 2 without too much trouble. It mostly worked for my purposes, although it seemed disinclined to tell me which SATA ports my drives were attached to. The version of gnome-disk-utility on Ubuntu 12.04 does provide that information, so I don’t know if it’s yet another case of GNOME killing off functionality or if it was because udisks2 wasn’t present when udev started or something like that.
Martin, which frame rate do you get with llvmpipe? From my experiments with it (using it with Wayland and some QML2 demos) I’d expect less than 60 fps…
don’t remember exactly, running the unadjusted KWin is unbearable slow. But I have here some adjustments (e.g. disable all effects) which makes it kind of usable but I don’t remember the exact framerate or better said: I cannot get to it if all effects are disabled.
But from how KWin feels I would say less than 40 fps.
Depends on a lot of factors. But see e.g. http://www.youtube.com/watch?v=V83mChc-hQE, a qtwayland-based compositor using eglfs and SHM buffers plus a bunch of QtQuick2 clients in a VM, all pushing 60FPS from what I remember.
(ignore the jerky startup, from what I remember, that’s bad interaction with fbcon. and granted, the clients aren’t exactly playing to the hard parts of hardware – they’re just rotating and scaling an image)
I’m fairly sure that recent Fedora also uses llvmpipe for the fallback case for no hardware acceleration when using GNOME Shell, and performance there is good (in a VM also, in my case) though I don’t have any exact measurements.
tl;dr you can get fairly reasonable performance, at least compared to swrast. But it’s certainly not comparable to hardware acceleration.
I think llvmpipe would probably make sense for automated tests in a VM but for now not regular use, as you wrote.
However: What when Wayland comes? There is and will be no XRender in Wayland.
We will keep the option to run an X-Server based system. That’s the solution for that. Not every hardware will be capable of running a Wayland system (currently e.g. the proprietary drivers)>
Note that the Wayland protocol does not mandate OpenGL rendering; it’s just the only “backend” that is really used. Not sure if anybody checks that protocol changes keep non-OpenGL working.
Martin, I think you’re absolutely right here. My 7 year old laptop with ATI Mobility performs much better using XRender than OpenGL while in power savings mode (lowered clocks). Turning off power savings on the GPU, then the opposite is true. The laptop gets too hot and burns through too much battery power to never use power savings mode on the GPU. So the PC regularly uses both XRender and OpenGL for KWIN.
KWIN really makes the desktop experience a lot better. I love the textured window resize as turning that on means turning off “show window contents during resize” which saves me a whole ton of CPU while resizing windows. Even when the system is under very heavy CPU load, the window resizes are always very smooth, which really beats the snot out of Windows 7 where the whole desktop gets choppy as heck on old hardware. I can’t even compare Windows XP because window resizes in XP while the system is under heavy CPU load is horrendously ugly on the eyes, with window repaint problems everywhere.
Keep up the amazing work on KWIN. I was very surprised with it when I finally upgraded to KDE 4
Finally someone who thinks straight!
+1
Do you imagine any way to get the Blur effect working with XRender? I can not live without that effect 🙂
Anyway, with my current nVidia GT430 I almost did not notice performance difference between using OpenGL or XRender.
Thanks Martin for clearing that !
Martin,
Thank you for the understanding of not forcing things on users. OpenBSD doesn’t have the relevant graphics drivers. In OpenBSD, we are trying to bring KDE to modern standards, we will hopefully continue to provide a choice to users with KDE, Xfce, and numerous other WMs. I don’t know if recent behaviour of GNOME will be tolerated by the broader open source community. This looks more and more like the former Xfree86 situation. Atleast, KDE3 -> KDE4 transition was technical issues (strigi, nepomuk, akonadi, virtuoso which is slowly being addressed, kudos guys we love progress!).
Relevant articles from a recent thread on tech@openbsd.org
http://lwn.net/Articles/520892/
https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/
Thanks
I just read through the thread on tech@openbsd.org and just want to point out that if e.g. KWin works with OpenBSD it is pure chance. There are (almost) no users from OpenBSD (or any non Linux) and that means no bug reports in case something breaks. And even if there is a bug report (happens perhaps once a year) we cannot fix it because we don’t use those “exotic” systems and I would not set them up. I don’t install a Linux distribution if there is a distro specific problem – in most cases I don’t need, because there are enough users around which can apply a patch.
Long story short: I do not like the attitude on that thread as it puts the blame to the upstreams while it’s the downstream which needs to interact more. Yes I can understand that the time of the *BSD devs is limited, but so is ours. And if I have to maintain code which is literally not used by anyone, it becomes difficult. If I change code which would require features not available on non-Linux it’s not because I’m evil, but because in most cases I just don’t know that this would be non-Linux. I have no idea what Mesa versions are currently supported by non-Linux, nevertheless we require the second-latest version. And you know what? I asked on the kde-packagers mailing list prior to version update, whether it’s fine: nobody complained.
Also recently I announced on the same mailing list that we will start including Wayland features (which are currently Linux only) and asked people to get in contact with me if there are problems with that: no response so far.
How should we then know that it is not supported on non-Linux?
>>> And even if there is a bug report (happens perhaps once a year) we cannot fix it because we don’t use those “exotic” systems and I would not set them up.
Cool, but I hope you would accept patches to make it work on our “exotic” systems.
From http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/3RDPARTY
The Mesa version in OpenBSD is 7.11.2
You innovate on whatever you like. But just know there are people who are progressing slower than you guys in Linux. Other distros and OS will catch up or give up.
I do accept patches, but I have made bad experiences with non-Linux (don’t remember which one) to be honest. E.g. just dumping a patch to compile and when asking for a small change no reply.