Gräßlin: The Costs of Supporting Legacy Hardware [LWN.net]

On his blog, KWin hacker Martin Gräßlin describes the costs of supporting older graphics hardware. In particular, he looks at some of the maintenance and testing burdens for continuing to support OpenGL 1.x hardware. "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."

to post comments

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 1:14 UTC (Tue) by horen (guest, #2514) [Link] (50 responses)

Uh-huh... and there aren't any of these "legacy hardware" systems around? Funny; my user-built desktop is an eleven-year-old AOpen DX34RU motherboard, with dual Pentium III CPUs (1.4GHz) and 2GB RAM, displayed via an ATI Rage 128 PF/PRO AGP graphics card, running Linux Mint 11 (GNOME edition, themed for Mac OS X via Mac4Lin).

The hardware isn't difficult to find. I'm sure the LWN community would be glad to contribute... or trade.

OTOH, perhaps that's why I'm using GNOME, and not KDE...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 1:45 UTC (Tue) by Kit (guest, #55925) [Link] (49 responses)

Humorously enough, KDE 4, unlike GNOME 3, actually supports legacy hardware (by falling back to either XRender from OpenGL, or just disabling desktop effects). Maybe you should be switching to KDE ;)

At the end, the author suggests that llvmpipe might be a good solution for easing the development burdens of various weird code paths for systems that will only become harder and harder to find. I'd say another advantage of llvmpipe is that it would centralize the burdens of supporting increasingly old hardware (at the very least prevent duplication of effort by KDE and GNOME to support systems with archaic GPUs).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 1:57 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (48 responses)

"Humorously enough, KDE 4, unlike GNOME 3, actually supports legacy hardware (by falling back to either XRender from OpenGL, or just disabling desktop effects). Maybe you should be switching to KDE ;)"

It would be funny if it was true. However, GNOME 3 != GNOME Shell only. Fallback mode is part of GNOME 3 and supports legacy hardware just fine. Not to mention https://fedoraproject.org/wiki/Features/Gnome_shell_softw...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 3:02 UTC (Tue) by Kit (guest, #55925) [Link] (9 responses)

I'm familiar with Fallback Mode, it's the only mode supported in VirtualBox, as well as a laptop I tried to install Fedora 16 on (until a few days ago, it was the only way I had used GNOME 3!). Technically what you say is true, it's GNOME 3... but I can't help but feel that claiming it's "GNOME 3" is totally disingenuous (you know, being a totally different interface and all).

I'm also familiar with what that link says- the blog post and my post actually both reference it! The idea is to be able to eventually use llvmpipe for all the software rendering needs, under the assumption that modern CPUs should be fast enough to handle the GPU's work (how a Pentium 3, though, would handle GNOME Shell is anybody's guess).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 9:46 UTC (Tue) by mjthayer (guest, #39183) [Link] (2 responses)

Kit wrote:
> I'm familiar with Fallback Mode, it's the only mode supported in VirtualBox [...]

GNOME 3 with acceleration is supported in VirtualBox. (If you are interested in seeing why it isn't working for you feel free to give me a ping on one of the user support channels).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:18 UTC (Tue) by cortana (subscriber, #24596) [Link] (1 responses)

IME it doesn't work in practice. What's your IRC nick? :)

I find it really hard to debug the issues that I do have, because it's hard to say whether the problems are caused by VirtualBox, the host OS graphics drivers, or Mesa/DRI/Xorg on the Guest side. In practice I find gnome-shell unusable on my Radeon HD 4890 and 5850 systems. It's quite usable on my 2007-era laptop with an Intel GMA X3000 graphics chip, so I'm guessing the problems are mostly on the VirtualBox side, however.

It doesn't help that VirtualBox has been subsumed by Oracle and have made their bug filing process substantially worse (you now have to sign up for an Oracle account, that demands to know amongst other things your postal address, telephone number, profession and the name of your employer!). Off topic mini-rant over!

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 13:28 UTC (Tue) by mjthayer (guest, #39183) [Link]

My name with "vb" on the end. Though I'm not always online.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:27 UTC (Tue) by dgm (subscriber, #49227) [Link] (5 responses)

> how a Pentium 3, though, would handle GNOME Shell [using llvmpipe]is anybody's guess.

That's my guess: on a typical netbook you will get less than 1 fps, using 100% CPU (and a huge amount of memory, making the machine page like crazy). Oh, well.

Llvmpipe is a nice experiment, but its absolutely useless. It would be _much_ more useful to try to implement OpenGL on OpenGL (say, implementing OpenGL 2.0 using OpenGL 1.x hardware _and_ software to fill in the gaps).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 13:08 UTC (Tue) by airlied (subscriber, #9104) [Link] (4 responses)

thanks for bestowing your knowledge on us all about how useful llvmpipe is.

btw your idea is pointless and stupid. If GL1 hardware could do GL2 stuff then it would be called GL2 hardware. Falling back to a software mix means running both vertex and fragment shaders in software, which is exactly what llvmpipe does.

You can't use fixed function hardware to do shaders.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 17:04 UTC (Tue) by dgm (subscriber, #49227) [Link] (3 responses)

> Falling back to a software mix means running both vertex and fragment shaders in software, which is exactly what llvmpipe does.

AFAIK, llvmpipe is a _pure_ software renderer. A software mix should be able to use the hardware capabilities where available.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 19:03 UTC (Tue) by airlied (subscriber, #9104) [Link]

As I said if you read, the hardware can't support any of the operations for GL2 in GL1 hardware, so a mixture of hw and sw would be sw.

Like I think the 945GM/pineview might be the only one you could do some hackery on to force GL2.0 and I think Intel do that. But that chipset has programmable fragment shading. You can't emulate programmable frag shading on a GPU that has none.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 19:14 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

That's a lovely thought, but...

In reality with many types of graphical hardware doing mix mode rendering in that manner is actually slower. This is because of the context switching and pushing textures back and forth over AGP/PCI/PCI-E buses to render using both CPU and GPU has a lot of overhead. It's often going to be slower then just using the CPU and ignoring the GPU altogether.

(This is one of the reasons things like discrete video cards are going the way of the dodo bird. You'd get far better performance in a multiprocessor environment if they are in the same die sharing the same memory rather then one processor hanging on the far end of a PCI-E bus)

Then you have the fact that GPUs with fixed amounts of memory simply do not have enough RAM to support composting correctly on their own. It doesn't matter if you are using Xrender or OpenGL or whatever. With 8/16/32/64/128MB of fixed video memory you are going to run into issues if you try to do it all on the GPU.

And, in addition, the LLVMpipe renderer is a significantly different beast then the old Mesa software renderer. The two don't compare in terms of performance. The old Mesa was just a reference implementation that was intended to be taken and modified for individual drivers while llvmpipe is intended to be used directly by applications in a everyday setting.

In practice I expect that Gnome-Shell with llvmpipe on a pentium3 system will be usable if you have a large amount of RAM. If you don't have enough RAM then using gnome-shell vs fall back mode vs KDE vs whatever isn't going to matter.. it's going to suck no matter what.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 12:25 UTC (Wed) by dgm (subscriber, #49227) [Link]

> doing mix mode rendering in that manner is actually slower.

Do you have any numbers? I have done some research and found nothing.

> With 8/16/32/64/128MB of fixed video memory you are going to run into issues if you try to do it all on the GPU.

Take my netbook as a typical case. The machine is less than two years old. It has a 945GME chipset with 256 MB of VRAM (reported by X.org), that does not support OpenGL 2.0 (but supports OpenGL 1.4 with some shader extensions).

The screen is 1024 by 600. That's 0,6 mpixels, or about 2.5 MB of VRAM. you can put about 100 full screens in 256 MB of VRAM, that's the amount of memory you can find in my netbook, for instance.

> The old Mesa was just a reference implementation that was intended to be taken and modified for individual drivers while llvmpipe is intended to be used directly by applications in a everyday setting.

That's the main difficulty, I'm afraid. Llvmpipe has not been designed to be integrated with anything else, and making use of the hardware rendering pipeline may probably require tight integration with the driver. I'm not that much into shaders or the KWin codebase, but I assume that many of the shaders involved boil down to operations that could be performed by the fixed function pipeline as well, with certain compromises.

> In practice I expect that Gnome-Shell with llvmpipe on a pentium3 system will be usable if you have a large amount of RAM.

Apparently is more a matter of having a powerful multicore CPU rather than the amount of RAM involved. So, the trade off made by llvmpipe (GPU for CPU) is not really practical, not for the kind of hardware that needs software rendering: the low end laptop/netbook or aged desktop.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 3:08 UTC (Tue) by Sho (guest, #8956) [Link] (23 responses)

That's playing semantics. Yes, fallback mode is technically part of "Gnome 3", but in the sense that Gnome Shell is the new experience promised and advertised by Gnome 3, it is Gnome 3. In terms of what percentage of that complete/ideal experience is supported on systems without OpenGL, KDE 4 does a lot better than Gnome 3 does, and did so from day 1, whereas llvmpipe is only materializing now.

I know it's hard to concede any inch, but let's face it: This is a case where KDE made design decisions (a shell capable of doing its own compositing in software, a compositing manager supporting XRender) that serve legacy systems well and Gnome (a compositing manager requiring OpenGL support, the shell built into the compositing manager's scene graph) did not.

Now, I have my own beef with Martin's post: He's cutting corners by claiming that testing on older hardware would require building on it. This is of course not so, he could build binaries that run on older hardware on newer hardware. However, the overall point that there's additional cost and inconvenience to supporting older hardware is relatively unaffected by that.

However, note that he is not announcing any firm plans to remove the OpenGL 1.x codepath at this point, and no plans to remove the XRender code path at all. He is merely considering removing the OpenGL 1.x code path at some point if it turns out llvmpipe is an acceptable alternative performance-wise.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 3:14 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

"KDE 4 does a lot better than Gnome 3 does, and did so from day 1"

I don't buy that. GNOME 3 and KDE 4 have taken different approaches. Which is better is a matter of opinion

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 3:26 UTC (Tue) by Sho (guest, #8956) [Link] (6 responses)

You're ripping a half-sentence out of context and then replying to it with something of a non-statement, IMHO. Again, let me repeat: In terms of the experience they promote and advertise, KDE 4 did and does* better at delivering it to legacy systems than Gnome 3 does. And that's not a matter of opinion, it's simply a fact.

If you're on a system without OpenGL support, you still get the experience we show in our screenshots on http://www.kde.org&;. If you run KDE 4 in a virtual machine, you still get that experience as well.

Neither is the case for Gnome 3 and http://www.gnome.org/gnome-3/.

That's not saying that Gnome 3's fallback mode isn't usable, or that I disagree with the decision they made. They made a conscious decision to make Gnome Shell depend on a certain feature set and drop support for legacy hardware, betting that the installed base of the required hardware/drivers at release time would be sufficiently large, or that something like llvmpipe would come along sooner rather than later. And that those exiled from Gnome Shell would be served adequately by something derived from Gnome 2. It's not the design decision I would have made, and it's not the design decision KDE made, but I respect their choice and understand why they were compelled to make it from a development point of view.

But that doesn't change the fact that KDE made design decisions that enables legacy hardware to access its primary and newest user experience, and Gnome didn't.

* = Until llvmpipe is broadly available.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 4:41 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

"If you're on a system without OpenGL support, you still get the experience we show in our screenshots on http://www.kde.org&;;. If you run KDE 4 in a virtual machine, you still get that experience as well"

KDE 4.x in its earlier versions tried to detect OpenGL support and have a fallback without compositing. However this had various bugs and it took several revisions and rendering bugs had to be fixed and KWin had to maintain a long list of blacklists for various quirks. KDE 4.8 is much better in this regard. GNOME in its latest versions handles legacy hardware much better as well. Both approaches are valid. I don't consider one approach as necessarily better. It just involved a different set of tradeoffs.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:53 UTC (Tue) by aseigo (guest, #18394) [Link] (3 responses)

Rahul, you're playing the apologist and it's unbecoming.

for better or worse, Plasma Desktop always supported a non-composited fallback *code path* within the exact same shell and window manager. it included graphics for both modes and let one pick which mode to run in. iow, there was a runtime adaptability designed into the software.

Gnome Shell requires OpenGL and does not provide any fallback code path, it instead runs a completely different binary with different features and an uncertain future in terms of maintenance.

this is a general pattern that goes beyond composite management in both shells. it is a design pattern that lies at the heart of each project's chosen paths.

this is not a negligable choice and it has had repercussions. while Plasma Desktop has largely kept the KDE community together using a single desktop line (though we have Trinity and RazorQt for those who need / wish that, it's a tiny minority that use them), GNOME has undergone a series of popular forkings of their user community due to the "single path" design decisions being made. while it is a valid choice among many,it evidently has its downsides. the number of forks, spinoffs and people now using e.g. XFCE versus the % of KDE's downstream that remains happily using Plasma Desktop is a measurable sign of this.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 7:05 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I don't have any need to be a apologist for any desktop environment. I frequently switch between them just to check out the changes, maintained the Fedora Xfce spin in the past, released a remix of LXDE and currently running Cinnamon and also reviewing the package for official approval in Fedora.

All I am saying is that *both* approaches have their costs and anyone who points at the cost of GNOME Shell approach should recognize the cost of the KDE approach as well. KDE 4 and GNOME 3 (and Unity for that matter) have their share of detractors. You dismiss the fork of KDE 3 but claim that the fork of GNOME 2 is significant. That is not a supportable claim at all. Sorry.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 8:18 UTC (Tue) by Pawlerson (guest, #74136) [Link] (1 responses)

The point was what better supports older hardware. The fact is KDE allows you to switch compositions off while you can't do the same in Gnome. That's a fact KDE supports old hardware better. I don't buy your biased opinions, because I have noticed you're gnome evangelists which isn't surprising, because you work for Red Hat, don't you?

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 8:29 UTC (Tue) by Sho (guest, #8956) [Link]

Red Hat also pays people to work on KDE packages, and the distro that Rahul works on, Fedora, has excellent KDE support. I'm a happy Fedora user myself. Let's not make this a politics blame game, thanks.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 10:27 UTC (Tue) by mgraesslin (guest, #78959) [Link]

This is not correct. We never had a "blacklist" to support fallbacks to non compositing. We had in one release (4.5) a blacklist for certain OpenGL features incorrectly announced as supported by the driver. Thanks to fixes in the underlying stack we dropped the blacklist in the next version again.

Falling back to compositing always worked the same way since compositing has been enabled by default: try getting a GL context, if it fails (e.g. software rendering) use XRender. In case KWin crashes twice while trying to get a GL context or in case X crashes while getting a GL context, KWin won't try to use compositing any more.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 9:57 UTC (Tue) by mjthayer (guest, #39183) [Link] (13 responses)

Sho wrote:
> However, note that he is not announcing any firm plans to remove the OpenGL 1.x codepath at this point, and no plans to remove the XRender code path at all. He is merely considering removing the OpenGL 1.x code path at some point if it turns out llvmpipe is an acceptable alternative performance-wise.

Just an idle thought, but is it theoretically possible to use OpenGL 1.x support to partially accelerate shaders run by llvmpipe, rather than requiring software to have a shader-less code path? Obviously I am talking about doing it in a way that actually adds something beyond complexity.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:10 UTC (Tue) by Sho (guest, #8956) [Link] (1 responses)

I think kwin's OpenGL 1.x codepath is actually shader-less and purely fixed-function, only the OpenGL 2.0 / OpenGL ES codepath uses shaders AFAIK. And if that wasn't the case you'd still need to maintain separate shaders.

Martin can probably correct me here.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:34 UTC (Tue) by mgraesslin (guest, #78959) [Link]

correct, the OpenGL 1.x rendering path uses fixed functionality only. But there are two ARB shaders (one for blur, one for lanczos available) for OpenGL 1.x. Though lanczos shader is hard disabled for all Intel GPUs and fglrx anyway and blur defaults to not being enabled for all Intel GPUs.

So in summary: for most users OpenGL 1.x means no shaders.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 12:50 UTC (Tue) by drago01 (subscriber, #50715) [Link]

Mixing software and hardware rendering can end up being slower than just software due because you'd have to copy textures back and forth between vram and sysmem.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 23:00 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

Unfortunately not; the big jump from OpenGL 1.x to 2.x is the move from fixed function hardware, to programmable pipeline hardware. While it's easy to emulate OpenGL 1.x hardware with more modern hardware (you just write programs for the programmable pipeline that do what the fixed function pipeline did), it's impossible to go the other way (convince fixed function transistor blocks to accept programs).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 9:26 UTC (Wed) by mjthayer (guest, #39183) [Link] (8 responses)

> While it's easy to emulate OpenGL 1.x hardware with more modern hardware (you just write programs for the programmable pipeline that do what the fixed function pipeline did), it's impossible to go the other way (convince fixed function transistor blocks to accept programs).

Yes, after thinking for a moment it is pretty obvious. I was more thinking of running the shaders on the CPU and using fixed functions on the GPU as building blocks, but for a pixel shader the cost of scheduling a fixed pipeline function (or several!) for each pixel would probably be higher than the costs of using llvmpipe. Still wondering (idly) whether OpenGL 1.x feedback could be used to improve performance of software rendering.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 10:59 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

OpenGL 1.x really doesn't have enough to be useful; there's no feedback from later pipeline stages to earlier, so if you're emulating OpenGL 2.x on it, you need to do software rendering until you get to a point where the remaining operations are ones the fixed function hardware can do (a carefully chosen set of texture mapping operations, applied to software rasterized rectangles, as you can't normally use the fixed function vertex hardware).

There's quite a bit of work involved in getting this far, and in working out what the patterns are that let you leave the software world and enter hardware. Note also that you really, really don't want to ping-pong between GPU and CPU rendering - OpenGL 1.x hardware is typically reasonable at transferring data from CPU memory to GPU memory, but horrendously slow if the CPU works directly on GPU memory, and also horrendously slow at transferring data from GPU memory to CPU memory. AGP was a hack that exploited this - add a CPU to GPU direction high speed interface atop PCI.

On the other hand, it could be a fun project for someone with the time and with OpenGL 1.1 or later hardware - can you accelerate OpenGL 2.x software rendering at all, and if so, is the acceleration you can extract useful?

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 15:31 UTC (Wed) by dgm (subscriber, #49227) [Link] (6 responses)

Some OpenGL 1.x hardware does support shaders, as an extension.

Also, a couple of shortcuts could be taken here and there. I don't think anybody expects to see the latest first person shooter running smoothly with full detail and in HD. We are talking about compositing a typical desktop and a few transition effects.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 24, 2012 14:34 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

Hardware that supports shaders using an extension in OpenGL 1.x is usually exposed by the open source drivers as OpenGL 2.0 hardware - the other features of OpenGL 2.0 can be emulated well enough using software and shaders to be exposed as slow OpenGL 2.0 hardware instead of OpenGL 1.x hardware.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 27, 2012 16:22 UTC (Mon) by dgm (subscriber, #49227) [Link] (4 responses)

According to this, the 945GM part that powers my two netbooks is capable of pixel shading and some sort of "accelerated" software vertex shader.

Glxinfo says that the OpenGL version is 1.4, with extensions GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shader_objects and GL_ARB_ARB_vertex_shader, among others.

Yet no sign of OpenGL 2.0 support.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 28, 2012 8:37 UTC (Tue) by mjthayer (guest, #39183) [Link]

dgm wrote:
> According to this, the 945GM part that powers my two netbooks is capable of pixel shading and some sort of "accelerated" software vertex shader.
[...]
> Yet no sign of OpenGL 2.0 support.

For interest, see this Phoronix article [1], though it concerns AMD and not Intel drivers.

[1] http://www.phoronix.com/scan.php?page=news_item&px=MT...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 28, 2012 11:20 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I also have a 945 based machine here, running a recent Mesa git snapshot. It exposes OpenGL 2.0; I've had to set a special /etc/drirc (reproduced below) in place, as the hardware is technically non-compliant, and I've had to indicate that I'm OK with that non-compliance.

/etc/drirc:

<driconf>
  <device driver="i915">
    <application name="default">
      <option name="stub_occlusion_query" value="true" />
      <option name="fragment_shader" value="true" />
    </application>
  </device>
</driconf>

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 28, 2012 12:29 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

Awesome. If this is in the 8.1 branch of Mesa I think it would hit the major distros in a year or so. I have to test this right away.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Mar 2, 2012 16:59 UTC (Fri) by farnz (subscriber, #17727) [Link]

Don't quote me on this, but I think it's even in older versions of Mesa - I've had that configuration file around for a long time (certainly since 7.11 branched), and I'm sure I wouldn't have put it in without a good reason.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 12:41 UTC (Tue) by drago01 (subscriber, #50715) [Link]

https://live.gnome.org/GnomeShell/FAQ#What_led_to_the_dec...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 3:28 UTC (Tue) by jreiser (subscriber, #11027) [Link] (10 responses)

Fallback mode is part of GNOME 3 and supports legacy hardware just fine.

No, fallback mode does not support legacy hardware "just fine." The features are different, not just the visual presentation. Also, the performance sucks. My Radeon 9250 Pro (AGP), purchased new 5.5 years ago, runs visibly slower (a factor of 2 to 3) and consumes double the CPU resources (10% CPU running only gnome-system-monitor instead of 5%) under Gnome3 fallback mode than under Gnome2. This card was a mid-life kicker for a [then] 5-year old Pentium 4 system previously running RagePro cards, and was performing well until Gnome3 in Fedora 16 made it sluggish.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 4:33 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

It works just fine for me and is functional. If it doesn't for you, it is a bug and I am sure there are rendering bugs in every desktop environment,

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:09 UTC (Tue) by blujay (guest, #39961) [Link] (1 responses)

You know, WFM is rather meaningless...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:30 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

It is as meaningful or meaningless as saying I have a bug.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:15 UTC (Tue) by fest3er (guest, #60379) [Link] (1 responses)

Posted Feb 21, 2012 4:33 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] It works just fine for me and is functional. If it doesn't for you, it is a bug and I am sure there are rendering bugs in every desktop environment,

As there is in KDE 4.4.5 (Debian Squeeze), where the pop-up 'titles' of things in the 'taskbar' cause like-sized areas of the background to be displayed atop other windows. (At least on my install of Squeeze.) These areas remain until the window does something to change that area or that area is hidden by an overlapping window. Meh. Stuff happens. As long as there is continual forward progress to better code, all is as well as can be expected.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:43 UTC (Tue) by aseigo (guest, #18394) [Link]

that is actually a bug in x.org, one we reported as soon as we noticed it (~3-4 years ago now?). the good news is that it was fixed in x.org late last year and will be in releases making their way into distros this year :)

it wasn't, however, anything KDE code did or could avoid without simply not using the features advertised by x.org.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:51 UTC (Tue) by Cato (guest, #7643) [Link] (3 responses)

I have a Radeon 9250 in one system, which I installed mostly because it seems to have good open source drivers - the performance on 3D is bound to be quite poor as it's such a low-end card, but it is passively cooled which is good for noise levels.

I'm using it with GNOME 2 on Linux Mint 11 (based on Ubuntu Natty 11.04) and performance without Compiz seems fine - there was major lagging in Firefox with Compiz, probably due to Firefox using the GPU. Most importantly, it doesn't freeze every day or two, which the Intel GMA3100 (G33) suffered from on Ubuntu 10.04.

I can recommend this combination of 9250 and Linux Mint with GNOME 2 for those more interested in stability for 2D usage than in 3D performance, as it seems it's harder to get a stable KMS setup than with pre-KMS. Just get an old Radeon card like this (exists in AGP and PCI versions) and put it in almost any system, then run Linux Mint 11 (the last GNOME 2 version). Only supported till Oct 2012 but by then perhaps the GNOME 3 based MGSE/Cinnamon in Mint will be sorted out.

Might be better to get a slightly beefier Radeon card that can handle 3G better - if you have PCI Express then any card supporting that will do better of course.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:09 UTC (Tue) by jospoortvliet (guest, #33164) [Link] (2 responses)

Yeah, that thing is literally over 10 years old... I thought I was using ancient hardware with my Geforce 6600 from 2004 but that thing has no issue with openGL 2.0 ;-)

So that's what Martin is talking about - no longer maintaining compositing support for 3D hardware only capable of accelerating openGL 1.1. I hope he'll keep at least xrender support so such hardware can actually still look and work quite OK despite not having the full range of effects available... But I get why support would be dropped, this is ancient. GNOME did the same a while ago already - your card of course doesn't even begin to run a full GNOME Shell (something the 6600 does fine, btw).

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:58 UTC (Tue) by mgraesslin (guest, #78959) [Link]

> I hope he'll keep at least xrender support so such hardware can actually still look and work quite OK despite not having the full range of effects available

as mentioned in the blog post, XRender has other benefits than just supporting legacy hardware. So no plans there to drop for X11.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 16:32 UTC (Tue) by Cato (guest, #7643) [Link]

Ancient hardware is often donated to charities and the developing world with Linux on it - if there's a way to keep it working, it really helps Linux spread into niches that commercial OSes can't reach.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:03 UTC (Tue) by ovitters (guest, #27950) [Link]

GNOME 3 fallback is just the same metacity is in GNOME 2. Just because you see "GNOME 3" doesn't mean it is suddenly totally different. Suggest to just file a bug. I don't see how the performance could be any different though.. GNOME 3 metacity has version 2.34 and all...

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 12:48 UTC (Tue) by niner (guest, #26151) [Link] (2 responses)

> However, GNOME 3 != GNOME Shell only. Fallback mode is part of GNOME 3 and supports legacy hardware just fine.

Interestingly, GNOME developers seem to see it differently. To quote https://live.gnome.org/GnomeShell/FAQ

"To get the GNOME 3 experience, you need hardware acceleration."

To get the KDE 4 experience I don't. I can even turn it on and off at runtime which is rather nice in cases I need to squeeze a couple more minutes of runtime out of my battery.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 14:30 UTC (Tue) by jospoortvliet (guest, #33164) [Link] (1 responses)

Please see http://blog.martin-graesslin.com/blog/2011/10/correcting-... about saving power with(out) compositing ;-)

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 14:48 UTC (Tue) by niner (guest, #26151) [Link]

Interesting read, but it doesn't have too much to do with my posting. I usually know in advance when I will be off the power grid for prolonged time, so I turn off desktop effects using the hotkey while still running on AC power. The rest is personal experience with my own hardware. Like I said, it's not much, but measurable.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 6:44 UTC (Tue) by callegar (guest, #16148) [Link] (4 responses)

"The interesting IT news of last week is probably that the next Mac OS X version will drop support for some legacy hardware"

Looks like in these days whatever Apple does must be copied.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 10:29 UTC (Tue) by Pawlerson (guest, #74136) [Link] (3 responses)

Apple doesn't even count. In the Linux world things are being done right, so the answer is no. You still will be able to use kwin without compositions and it's probably possible to use llvm pipe, too.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 16:40 UTC (Wed) by callegar (guest, #16148) [Link] (2 responses)

I wonder why that incipit, then? It was surprising to me since I have always seen kde as more apple indifferent than say unity.

And it seemed to me a good thing. Indeed, I wonder whether not doing what apple does could be a win. Those wanting something applish will probably get an apple anyway and those unhappy with apples could have something different.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 22, 2012 18:19 UTC (Wed) by mgraesslin (guest, #78959) [Link] (1 responses)

If you read my blog post you will notice that I just made thoughts about what supporting legacy hardware actually means for us. This thinking process was triggered by the news about Apple dropping support for legacy hardware. That's all.

You will not find in the blog post any hints that I actually want to remove anything or that I plan to remove anything. All I wrote is that I would be tempted to remove it iff llvmpipe is a proper alternative. But even iff that turns out to be the case it's still a decision of the team whether we remove the code or not.

I clearly cannot see what this has to do with Apple. I just wanted to point out what triggered the thinking process.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 23, 2012 11:46 UTC (Thu) by callegar (guest, #16148) [Link]

Good to hear, thanks for the explanation and sorry for the noise, then!

GPU testing farms?

Posted Feb 21, 2012 7:00 UTC (Tue) by Cato (guest, #7643) [Link] (1 responses)

I'm sure lots of people have old graphics cards, and even old PCs, that they would be willing to donate to suitable open source projects.

Even better, such older kit could be run as a service - hook up the video output to separate monitoring PCs that capture the video output, then the developer can at least check the videos as part of regression testing (even automated testing) that checks for errors on a wide range of hardware. Anyone working on the project could get access to this "GPU testing farm".

I'm curious to know if anyone is doing this, outside commercial OS development.

Perl's CPAN Testers is a more distributed model that's perhaps easier to fit to open source - people download new CPAN packages and automatically test them on their hardware and OS version, the key being that it's highly automated so it's not too much hassle for the tester, and the results are collated so you can see problem areas easily. http://en.wikipedia.org/wiki/Comprehensive_Perl_Archive_N...

GPU testing farms?

Posted Feb 21, 2012 7:47 UTC (Tue) by jmayer (guest, #595) [Link]

Well there's the phoronix test system but I don't think it supports capturing live video - I may be wrong on this though. It does support monitoring the CPU usage etc during testing.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 8:23 UTC (Tue) by job (guest, #670) [Link] (7 responses)

Six years old? That's nothing. My main computer at home is eight years old (although it is time to upgrade soon) and I live in a European country. I hesitate to think what kids in poorer countries are stuck with and I would have thought open source is what should get them hooked on programming.

Frankly, I care a lot more for hardware support than I do for new KWin features. I'm sorry to say it out loud, and I guess it's kind of ungrateful for the great work the maintainers do, but it's the truth. I believe it's applicable to other areas too; Bug fixes over features, any time.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 8:56 UTC (Tue) by gowen (guest, #23914) [Link]

Mine too, but then again I run Ubuntu 10.04 LTS on it, with Gnome 2 (no 3D acceleration at all on my ancient videocard, plus thunar as a file manager. And there a plenty of other distros that could provide me with basically the same desktop experience.

I'm more than capable of matching my software to my old hardware; I don't expect people on the bleeding edge to keep supporting my niche computing needs. Absolutely none of Gnome 3/KDE4/Windows 8/OSX will run adequately on my PC - for me to expect that is completely unreasonable.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 9:32 UTC (Tue) by halla (subscriber, #14185) [Link] (3 responses)

"Frankly, I care a lot more for hardware support than I do for new KWin features. I'm sorry to say it out loud, and I guess it's kind of ungrateful for the great work the maintainers do, but it's the truth. I believe it's applicable to other areas too; Bug fixes over features, any time."

Well, that's exactly the point, isn't it? Support for different backends, like OpenGL 1 and XRender for compositing are _features_. Features that come at a certain cost, a cost you have to measure in a couple of ways:

* additional code complexity
* additional bugs
* additional time needed when refactoring/fixing bugs
* additional shelf space needed for old and obsolete hardware in your living room, den or student dorm if the "donate old hardware to Martin" project gets off the ground.

Hence the discussion on whether those features are worth it.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:17 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

>> Bug fixes over features, any time.
> Support for different backends, like OpenGL 1 and XRender for compositing are _features_

I think he meant _new_ features. It's really a shame, but it looks like nobody is capable of finishing anything anymore. Just keep adding half done new stuff until the whole thing collapses under its own weight. What then? call it "legacy", throw it all, and start over.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 11:48 UTC (Tue) by halla (subscriber, #14185) [Link] (1 responses)

Instead of posting rather insulting generalizations, let's just look at the facts of developing software, right?

As for all software, kwin users actually do ask for features. There are 356 bug reports and 366 feature requests in bugzilla. Bugs get fixed, features get implemented. In past week, six bugs and two features.

Then, software, especially if it touches hardware is never "finished". Hardware changes, making part of the code obsolete. Drivers change, and you previously working code now shows up bugs in the driver. User demands change. Libraries you depend on change. You will never be done.

And finally, kwin works pretty damn well. It is as closed to "finished" software as you can get -- it does what it says it does, it works for most people under most circumstances.

Some people might code like you describe, and if they're volunteers working on their own free software project they have a perfect right to do so and thumb their nose at your disapproval, but that's no justification for your sweeping generalization. Because most of us don't.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 12:03 UTC (Tue) by dgm (subscriber, #49227) [Link]

I was a bit of an over-generalization, yes. My sincere apologies.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 12:13 UTC (Tue) by Cato (guest, #7643) [Link]

I think the best solution, at least for old desktop PCs, is to buy an old but still supported graphics card - can cost as little as $50 and avoids having to throw out a serviceable PC. Most non-GPU hardware seems to be supported for a very long time (decade or more typically) once it's in the mainline kernel.

Or you could stick with GNOME 2 i.e. MATE, but that might be a bit more experimental than you want. Linux Mint may be a good option here if MATE proves stable. Or just switch to XFCE, LXDE, etc.

Or simply use an old distro that still works, and stop taking security updates, which works for a while if you only want web+email - Firefox and Thunderbird auto-update quite well from non-repository installations. Flash-Aid is quite good for updating Flash (Firefox addon). If you split your setup into a main OS (on older distro) and a virtual machine with a new distro, you could still use all the new stuff in the VM, but it's not as convenient and an older PC may struggle anyway.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 14:51 UTC (Tue) by Wol (subscriber, #4433) [Link]

On my PC that I use at home (our second PC, the wife pinches the first :-) make.conf contains the line (iirc) "VIDEO="mga""

It's a real pain when all the docu assumes an either/or choice of radeon or ati (or is that nvidia?). And then the developers assume it and something breaks ... :-( Usually gets fixed quick enough, but it's a pain. But I've been using Matrox since the Mystique 1 - damn nice cards.

Oh - and I can beat your 8 years - I upgraded my bios at some point and the upgraded bios has a 1999 copyright date :-)

Cheers,
Wol

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 16:07 UTC (Tue) by slashdot (guest, #22014) [Link] (3 responses)

Solution: have both a Cairo-based and an OpenGL-based path, and require either DX9 or DX10 hardware at least for the OpenGL path.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 17:01 UTC (Tue) by aleXXX (subscriber, #2742) [Link] (2 responses)

kwin uses Qt, cairo is not involved. It's not like cairo would be the only one existing standard API for drawing. Qt has all the features too.

Alex

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 21:32 UTC (Tue) by slashdot (guest, #22014) [Link] (1 responses)

Well, you can directly use XRender instead of Cairo, although obviously using Cairo is better since it runs on other systems too.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 22:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Dude, do you even read what other people wrote? To quote aleXXX:
"It's not like cairo would be the only one existing standard API for drawing. Qt has all the features too."

I still use legacy hardware

Posted Feb 21, 2012 16:59 UTC (Tue) by dskoll (subscriber, #1630) [Link] (10 responses)

On my workstation at the office, dmidecode says:

Release Date: 08/09/2002

in the BIOS information section. It's a decent-enough machine: 2.4GHz P4 with 2.5GB of RAM. It might even have new-enough 3D acceleration for the latest GNOME and KDE, but I don't care... I use XFCE which runs nicely without 3D acceleration.

It's a desktop, people. Get over it. The basic features of a desktop were settled 15 years ago. Why not just make them work nicely and efficiently instead of reinventing the desktop by adding tons of eye-candy and other useless cruft?

I still use legacy hardware

Posted Feb 21, 2012 17:58 UTC (Tue) by drago01 (subscriber, #50715) [Link] (2 responses)

> It's a desktop, people. Get over it. The basic features of a desktop were settled 15 years ago.

15 years is a very long time in this context. Progress is being made and making use of the available hardware (GPUs) is part of that.

> Why not just make them work nicely and efficiently instead of reinventing the desktop by adding tons of eye-candy and other useless cruft?

Because other desktops are moving on as well we want to have a modern desktop as too (and no using 3D is not just for "eye-candy and other useless cruft".

People seem to always expect the newest software to work on ancient hardware unless said software is a game which is kind of weird.

I still use legacy hardware

Posted Feb 21, 2012 18:10 UTC (Tue) by halla (subscriber, #14185) [Link] (1 responses)

Yes... Fifteen years, that's really a long time ago. Fifteen years, my desktop did not have sound, did not have a high-res true-color display (it maxed out at 800x600 with 256 colors), could not store hundreds of thousands of high-res images, could not play a full-screen movie, was not connected to the internet all the time it was on, could not run more than a few apps at the same time, couldn't search in an instant through all my documents (even though it stored far fewer back then) and so on...

There is so much more that I can with my current, 2011 vintage, desktop or my 2009 laptop that I'm glad the software has kept up with the hardware and lets me make efficient use of all that power. Now I can play with blender if I want, I can make an application that allows users to paint multi-layer, 7000x5000 HDR images, I can watch a movie while the compiler chugs away in the background, I can use my windowmanager to manage the twenty or thirty concurrently running applications, I can find in my 5 gb of mail the message I need to refer to -- in an instant.

And at the same time, my daughter is happy that KDE4 runs just fine, thank you very much, on her four-year old laptop which has _one-fifth_ of the memory of dskoll's desktop. If I were her, I'd switch off the desktop effects, but she thinks they're worth it, and they actually work pretty smooth even on that system.

I still use legacy hardware

Posted Feb 21, 2012 21:32 UTC (Tue) by dskoll (subscriber, #1630) [Link]

There is so much more that I can with my current, 2011 vintage, desktop or my 2009 laptop...

What you describe are applications that work under any kind of desktop (XFCE or KDE or whatever...).

...my daughter is happy that KDE4 runs just fine, thank you very much, on her four-year old laptop...

I have a similar laptop. I run XFCE, two daughters run GNOME 2 and the third daughter runs KDE 4. (Those are what ship with Debian Squeeze.) While all desktops work on the laptop, XFCE is considerably snappier than the other two. I prefer responsiveness to cool looks, hence my choice.

I still use legacy hardware

Posted Feb 21, 2012 20:18 UTC (Tue) by Sho (guest, #8956) [Link] (6 responses)

> I use XFCE which runs nicely without 3D acceleration.

Just to reiterate: So does the latest KDE, and the blog post under discussion does not propose to change this.

KDE presently supports all these modes for its primary desktop experience (i.e. no special fallback environments as with Gnome 3 needed):
* No compositing.
* Composoting using 2D-only XRender acceleration.
* Compositing using OpenGL 1.x 3D acceleration.
* Compositing using OpenGL 2.0 3D acceleration.
* Compositing using OpenGL ES 2.0 3D acceleration.

The blog post talks about *maybe* removing the OpenGL 1.x mode at some future datw, investigation into the viability pending. That's t. Nothing more firm than that.

I still use legacy hardware

Posted Feb 21, 2012 21:03 UTC (Tue) by mgraesslin (guest, #78959) [Link] (1 responses)

thanks for summing it up so nicely.

I still use legacy hardware

Posted Feb 21, 2012 21:37 UTC (Tue) by Sho (guest, #8956) [Link]

Sorry for the ton of typos though, darn virtual keyboards :).

I still use legacy hardware

Posted Feb 21, 2012 21:37 UTC (Tue) by dskoll (subscriber, #1630) [Link]

OK, cool. Thanks for the summary.

I still use legacy hardware

Posted Feb 22, 2012 16:54 UTC (Wed) by callegar (guest, #16148) [Link] (2 responses)

I am still confused. The blog mentions hardware that is > 6 years old. Seems reasonable to neglect that a bit. But then the opengl 1.x happens to bring in all the laptops with intel GMA 950 (e.g. 945 and variants). There are laptops in shops with this. Actually all my laptops have this and one of them is just 2 years old.

Seems a bit ironic that many linux users had to prefer conservative intel hardware until yesterday and today it is suddendly too old...

I still use legacy hardware

Posted Feb 22, 2012 17:57 UTC (Wed) by Sho (guest, #8956) [Link] (1 responses)

Right, but a two-year old laptop with a 950 might have a fast-enough CPU to make llvmpipe a reasonable alternative. That's what's to be investigated.

I still use legacy hardware

Posted Feb 23, 2012 11:44 UTC (Thu) by callegar (guest, #16148) [Link]

I guess that about half of the machines that are in shops and have a GMA 950 are Atoms (one of my two machines is a core 2, the other is an atom). With a decent amount of RAM, the atom machine is quite happy both with unity and kde compositing in spite of its limited resources, but I expect it to be doomed by llvmpipe.

Gräßlin: The Costs of Supporting Legacy Hardware

Posted Feb 21, 2012 17:41 UTC (Tue) by iabervon (subscriber, #722) [Link]

Shouldn't it actually be pretty easy to make a great new graphics card only advertise support for OpenGL 1.0 and give errors (from the driver) if clients try to exceed limits? I'd think that the hard thing would actually be to test against i915 without an actual i915, since what tends to happen there is that the driver submits a shader program which is too complicated for the hardware, and it's hard to determine what the complexity limits are, or (if you're not using that driver) what the generated shader program would even be. Surely it can't be too hard to check whether a texture dimension is a power of two and give a gratuitous error if it isn't, even without hardware available that can't deal with it.