Yell a "WARNING: YOU'RE ON SOFTWARE ONLY OPENGL" ?

On affected hardware his makes the whole desktop run at approximately 2 fps unless the user somehow knows to change compositing settings.
I get the benefit for testing, but why not just use an environment variable to force llvmpipe in the tests?
A slight gain in testing convenience doesn't seem to be worth sacrificing the user experience on older hardware so badly. I still sometimes use two older Thinkpads that otherwise run Plasma 5 okay, but they only do OpenGL 1.4 so no hardware compositing.

In D2184#42374, @ahartmetz wrote:

I still sometimes use two older Thinkpads that otherwise run Plasma 5 okay, but they only do OpenGL 1.4 so no hardware compositing.

If they do OpenGL 1.4 KWin would fall back to XRender. There is no mechanism to switch to llvmpipe if the OpenGL version is not sufficient.

If Plasma works fine with the hardware, so should KWin. I consider this a bug which then needs to be fixed. My fair guess is to try disabling blur and contrast effects. If it's fine afterwards we can disable those effects on llvmpipe.

In D2184#43294, @graesslin wrote:

If they do OpenGL 1.4 KWin would fall back to XRender. There is no mechanism to switch to llvmpipe if the OpenGL version is not sufficient.

XRender performance is good because it's hardware accelerated well on older hardware. If you don't use it, you leave the optimal hardware for blitting unused.

If Plasma works fine with the hardware, so should KWin. I consider this a bug which then needs to be fixed. My fair guess is to try disabling blur and contrast effects. If it's fine afterwards we can disable those effects on llvmpipe.

The shell is usable but you wouldn't want to have everything at its frame rate.
When I experimented with llvmpipe, by far the most important factor for performance was pixel count. There wasn't even much of a difference between trivial and nontrivial pixel shaders. But, given that the desktop background should also be part of the shell, that makes me wonder. I'll need to experiment again.
So best case 2 fps (what I remember from weston with llvmpipe) was greatly exaggerated and it would be more like 15-20 with llvmpipe, which is still significantly worse than 60 with XRender. Let's give this a rest until I have the numbers.

XRender performance is good because it's hardware accelerated well on older hardware. If you don't use it, you leave the optimal hardware for blitting unused.

Point taken. Though since the development of glamor+xorg-modesetting-driver we don't have a guarantee that Xrender is actually accelerated.

Let's give this a rest until I have the numbers.

ack

Okay, I've compiled KF5 etc master on a Thinkpad R60e, which has only OpenGL 1.4 in hardware. kwin does not automatically enable OpenGL software rendering there, so this change does not do much in that situation. But it's easily forced by exporting LIBGL_ALWAYS_SOFTWARE=1 and then replacing kwin from that shell.
The frame rate overlay effect shows a frame rate of 22 fps while doing nothing. Frame rate is about 5 while typing in konsole. Frame rate is about 3 (moving the cursor, thus causing movement in the windows) to 8 (not moving the cursor) while the "present windows" effect is active.

So this change happens to do nothing if the hardware supports any kind of OpenGL, but if it doesn't, the resulting frame rates are rather painful.

we all know that showfps is not telling us useful information. In fact it's to be expected that with showfps effect on llvmpipe the performance will suffer a lot: It's triggering constant repaints (which is bad) and it forces shader switching multiple times which is really expensive when running llvmpipe given my tests with callgrind.

8 (not moving the cursor) while the "present windows" effect is active.

For the present windows effect I just pushed a change to disable the lanczos filter which probably was on by default: http://commits.kde.org/kwin/2a41229e938848b7f9e975703e3d55b8d8a09d7c

But still: if you have fps effect enabled you significantly change the result of what you are looking at. It triggers full screen repaints in the case of Present Windows, it's like constantly moving all windows around which we don't want on llvmpipe. That's why now all animating effects are disabled by default on llvmpipe.

we all know that showfps is not telling us useful information.

You'll have to account for full scene repaints (video playback) nevertheless.

Afaiu this only affects vbox/vmware (for every IGP in the wild will have some HW GL support), so I wonder what's the point about adding yet another GL context which is sought to be featurewise limited to xrender capabilities anyway, notably since virtual machines will likely have restricted CPU (single core + quota) as well (beyond testing the GL implementation on virtual machines)

nb. that XRender has (had?) some "optimizations" to cover its shortcomings, eg. the central shadow elements are tiled and not stretched (I sent Lubos such patch because kwin/xrender performed terribly in comparism to xcompmgr and this was more or less the only reason)

In D2184#47782, @luebking wrote:

we all know that showfps is not telling us useful information.

You'll have to account for full scene repaints (video playback) nevertheless.

yes, but we don't have shader switches then (that was really expensive in callgrind. Most time was spent on the simple color shader for doPaintBackground, The rendering of the textured windows was comparable unimportant).

Afaiu this only affects vbox/vmware (for every IGP in the wild will have some HW GL support), so I wonder what's the point about adding yet another GL context which is sought to be featurewise limited to xrender capabilities anyway, notably since virtual machines will likely have restricted CPU (single core + quota) as well (beyond testing the GL implementation on virtual machines)

nb. that XRender has (had?) some "optimizations" to cover its shortcomings, eg. the central shadow elements are tiled and not stretched (I sent Lubos such patch because kwin/xrender performed terribly in comparism to xcompmgr and this was more or less the only reason)

That assumes that XRender on such hardware is not emulated using glamor.

Anyway we already found two major performance issues which we just never saw on real hardware. I rather optimize the hell out of it :-)

Martin, please try it yourself on a pre-Core 2 CPU and you'll see how painful to use it is. No numbers seems to be able to convince you that the experience is unbearable. 20 fps are awful, 3 fps stuttering is awful, leaving no CPU time for other useful work is awful, and the battery drain is awful. All that for what? Also, the suggestion that XRender may use Glamor on old hardware is way off. For a long time, 2D hardware acceleration in X was a big deal and everything supported it at the time. That is the generation of hardware that may still realistically run a full desktop environment.
I recently told a friend who was setting up an old laptop for someone to try KDE (kwin with XRender...) because he was getting about 5 fps in Unity, and that solved the problem.

Martin, please try it yourself on a pre-Core 2 CPU and you'll see how painful to use it is.

Such hardware is irrelevant. Sorry to say so. Either it has a GPU which is working or Plasma won't work either. In fact not even sddm will allow you to start the session then.

Sorry, I'm not going to discuss theoretic "might suck on that hardware". I'm only caring about real situations. And here the only relevant question is "will it perform better or worse than XRender".

Such hardware is irrelevant. Sorry to say so.

What makes me wonder about the actual use case - any system of the past 10 years (and more) will provide GL acceleration - just not GL 2.0 or up but 1.4 (and sometimes not even that w/o emulation - did intel meanwhile find the T&L instructions on the GMA 900?? ;-)

Afaiu in this case one would still use xrender (obviously, since the supported GL is insufficient) - yesno?

So llvmpipe is mostly for virtual machines, isn't?
And virtual machines will have limited cpu - single core and/or quota.

Instead of loading such systems (which are only for testing and not for actual usage) next to the QML contexts in plasmashell etc., compositing should probably default to "off" and use whatever is the fastest CPU emulation backend if activated.

KWin doesn't exist to test virtual GPU implementations and it doesn't have to. So it should not. *shrug*

In D2184#47887, @graesslin wrote:

Martin, please try it yourself on a pre-Core 2 CPU and you'll see how painful to use it is.

Such hardware is irrelevant. Sorry to say so. Either it has a GPU which is working or Plasma won't work either. In fact not even sddm will allow you to start the session then.

Plasma actually does work on my R60e test machine, and performance is good enough for the shell. The shell renders quite few pixels most of the time. kwin renders many more pixels, both more area and more often. Pixels are expensive with llvmpipe, even if you do next to nothing with them.

Afaiu in this case one would still use xrender (obviously, since the supported GL is insufficient)

Yes, exactly. That's the reasoning I had for saying that such hardware is irrelevant.

So llvmpipe is mostly for virtual machines, isn't?

Not only, I'm also thinking here of the high end system which doesn't have a driver yet. Think of the latest NVIDIA hardware added to an older system, something like that. The problem with virtual machines is that they also don't have accelerated xrender, so switching to xrender won't help you and in worst case you are dropped to xorg-modesetting driver which uses glamor (llvmpipe). The reasoning is that on a modern system you will run on llvmpipe anyway if you don't have a working driver.