The Costs of Supporting Legacy Hardware

The interesting IT news of last week is probably that the next Mac OS X version will drop support for some legacy hardware. Looking back at the history of Apple we see that this is not the first time, but that the company dropped support for old hardware quite regularly by changing the CPU architecture. This time it is different as the GPU is the reason for the drop of support.

This made me wonder what are actually the costs to support legacy hardware in KWin? While it is completely acceptable that new Windows versions and new Mac OS X versions do not run on legacy hardware, there seems to be the demand that free software has to support all kind of legacy hardware. So what does supporting legacy hardware cost for KWin?

What’s important to remember when asking this question is that supporting legacy hardware has nothing to do with supporting low end hardware. That is supporting OpenGL ES 2.0 hardware is in fact an improvement as most of the code is shared with the OpenGL 2 backend, but supporting OpenGL 1.x hardware really requires different code paths. So optimizing for low end hardware improves the overall system while optimizing the legacy hardware might in fact decrease the quality of the overall system.

So what is the legacy hardware we are facing with KWin? Well basically anything not supporting at least OpenGL 2.0 and not supporting non-power-of-two (NPOT) textures. The latter ones are really causing headaches as we are unable to develop for it and have broken support for it during the last release cycles.

Up until recently Mesa did not support OpenGL 2, but this is nowadays no problem any more, so we can be sure that if OpenGL 2 is not supported, the hardware is lacking features. On ATI/AMD OpenGL 2 has been supported since the R300 (with limitations in NPOT support) which got released in 2002. On NVIDIA OpenGL 2 has been supported since NV40 which got released in 2004. On Intel OpenGL 2 has been supported since I965 which got released in 2006. (All this information is taken from KWin code)

This means if I talk of legacy hardware it means hardware which is at least six years old. Supporting such hardware comes with some costs. E.g. on Intel you have the problem that you cannot buy the GPUs, that is you have to get a six year old system just to test. With ATI I faced the problem that even if I wanted to test an old R200 I cannot install it in my system because my system does not come with an AGP socket anymore – the same holds true for old NVIDIA systems.

So the only possible solution to test on real hardware which is not OpenGL 2 capable means to use hardware as old as the GPU to test. As there is the saying that free software development is about “scratching his own itch”, I must admit that I cannot scratch any itch with running legacy hardware. Especially not when I want to develop. I have a rather powerful system to not have to wait for compile jobs to finish. Developing on a several year old single core system with maybe a gigabyte of RAM is nothing I want to do.

So in fact we cannot develop for the legacy hardware. Now let’s have a look at the costs for us to have legacy hardware support. In KWin this comes as the OpenGL 1.x backend and to a certain degree also as the XRender backend. XRender has a some usefulness without considering legacy hardware as it provides translucency for virtual systems. Nevertheless we should consider it as a legacy support system. According to SLOCCount the XRender backend has a size of about 1000 lines of code. But I can only count the discrete source files for XRender. It does not consider the branches in other code pathes and so on.

Getting an overview of the OpenGL 1.x related code is rather difficult. SLOCCount cannot help as the code just uses different code branches in the same files. Looking at the code it is clear that there are several hundred lines of code dedicated to OpenGL 1.x. This is unfortunately also scattered around many files. Overall about 5 % of our core code base  is dedicated for supporting legacy hardware. All OpenGL 1.x related code is also ifdefed to hide it from the gles backends. So each dedicated OpenGL 1.x call comes with an additional ifdef and in many effects there is a branch for OpenGL 1 and for OpenGL 2.

To sum it up: we have increased complexity, increased maintenance costs and lots of code just for OpenGL 1.x related hardware which we cannot really test. So a rather bad situation. Additionally it is nothing which we can continue to support in the future. Neither Wayland nor Qt 5 will make sense on such hardware (XRender based compositing might still make sense with Qt 5, but as the name says not with Wayland).

Given this the logical step would be to remove the OpenGL 1.x related code completely. This would of course clash with the demand of some user groups thinking we have to run on old legacy hardware. In the case of Intel GPUs it might be in fact true that there is still a larger number of users around – this is of course difficult to judge.

Another real issue for removing is that the proprietary ATI driver (aka Catalyst/fglrx) only provides a decent compositing performance with indirect rendering restricting the available API to OpenGL 1.x. So removing OpenGL 1.x support would mean removing OpenGL compositing support for all fglrx powered systems even if the GPU supports OpenGL 4. But to be honest: given that the radeon driver has no problems with OpenGL 2 on the same hardware, I would not mind removing support for proprietary drivers.

What might be a nice solution to this problem are the llvmpipe drivers in Mesa which hopefully provide a good enough experience without hardware support. At least Fedora wants to use llvmpipe drivers for GNOME Shell. As soon as Mesa 8.0 hits my Debian testing system I will evaluate the usage of llvmpipe drivers for KWin as this will hopefully improve our experience on virtual machines. If I am satisfied with the performance, I will be tempted to remove the OpenGL 1.x based legacy code…