GNOME Shell No Longer Requires GPU Acceleration

An anonymous reader writes "The GNOME 3.0 Shell with the Mutter window manager no longer requires GPU acceleration to work, while still retaining the compositing window manager and OpenGL support. GNOME Shell can now work entirely on the CPU using the LLVM compiler via the Gallium3D LLVMpipe driver. This will be another change to Fedora 17 to no longer depend upon the GNOME3 fall-back, which is expected to eventually be deprecated and further anger GNOME2 fans."

Comments

Software GPU Emulation

[masternerdguy]

Is slow. I'm not sure that this is an advantage.

Re:Software GPU Emulation

[jdege]

Am I the only person who runs my desktops as often through remoting as sitting at the console?

How fast will this be running over VNC?

Re:Software GPU Emulation

[TD-Linux]

Meh, the compositor has to draw the pixels, one way or another. KDE has two backends, XRender and OpenGL. If acceleration isn't available, the XRender backend can still run in software, and is pretty fast. KDE also supports no compositing at all, but with software compositing it's becoming irrelevant.

Note that compositing != GPU acceleration. Mac OS X has always used compositing, but it was entirely software. There are still good reasons to do so. I'll compare for you:

No compositing, one frontbuffer: You don't get your own pixmap to draw onto. You have to send drawing commands to the display server to draw on your behalf, to prevent you from drawing wherever you want on the frontbuffer. Unfortunately, if you have something complicated to draw, the user gets to watch as the drawing happens. When drawing a new object, generally the algorithm used is to draw the background, and then draw the objects in order from back to front. This means whenever the screen is updated, the user will see flicker whenever any objects are updated because they may briefly flicker to the background color. To work around this most modern toolkits (Qt 4, GTK 3) render to a pixmap, and then just tell X to draw their pixmap when they are done. This avoids the flicker but uses a bit more RAM.

With a compositor, the application still draws to the pixmap, but instead of requesting the X server to immediately draw their pixmap to the screen, they pass it a handle to the pixmap and the display server can draw it whenever. This makes a lot of things easier, like vertical sync and effects, as well as things like color format and color space conversion.

Drawing the pixmap on the screen is really the same operations, no matter if compositing is on or off. And the API your compositor uses shouldn't matter too much either if the underlying implementation is optimized. The highly optimized Gallium3D blitter is going to just as good as the traditional X blitter, if not better. The only thing slowing it down in this case is the fact that OpenGL API is rather overkill for blitting, but hopefully the llvmpipe backend is optimized for this use case. And it's probably not worth it to make the compositor support two drawing APIs, like KDE, as they both end up doing the same thing anyway.

Re:Software GPU Emulation

[Anonymous Coward]

No compositing, one frontbuffer: You don't get your own pixmap to draw onto. You have to send drawing commands to the display server to draw on your behalf, to prevent you from drawing wherever you want on the frontbuffer. Unfortunately, if you have something complicated to draw, the user gets to watch as the drawing happens. When drawing a new object, generally the algorithm used is to draw the background, and then draw the objects in order from back to front. This means whenever the screen is updated, the user will see flicker whenever any objects are updated because they may briefly flicker to the background color. To work around this most modern toolkits (Qt 4, GTK 3) render to a pixmap, and then just tell X to draw their pixmap when they are done. This avoids the flicker but uses a bit more RAM.

This is a bullshit way to look at it. You are confusing compositing, backingstores and backbuffers.

Compositing means to have a procedural transformation from a window pixel to a screen pixel, and allows you to do such things as transparency and 3D windows, it implies nothing of whether or not the window pixels are cached (Backing store). Basically anything besides 1->1 blitting of pixels from window coordinates to screen coordinates is compositing.

Backing stores, enabled in X11 with the +bs option and maybe used by default by other window systems, Wayland in particular, mean that the application renders to an offscreen buffer which is used to redraw the window during damage events (when the window is obscured), rather than calling back to the application to request it to redraw the window. They have nothing to do with tearing or removing flicker, except maybe in the degenerate case where the output device doesn't implement double-buffering or the window system operates asynchronously and decides to page-flip even though the new screen hasn't finished being drawn.

Finally backbuffers (or double-buffering) are used by the graphics driver of the windowing system, so that the screen can be updated synchronously to the vertical-blank, to avoid both tearing artifacts when updating graphics, this is done by changing the base address the graphics hardware reads from to display a different part of the framebuffer on each alternate blank (or only when the screen contents has been updated).

Backing stores are not actually as wonderful as people think, they increase memory usage by the size of the window (width*height*depth bits, or rounded up to the nearest page boundary, double if double-buffering is used), and the same results can be achieved much more efficiently by on-demand synchronous rendering, by placing responsibility for drawing widgets (what are known as Windows in X11) in the display system, as X Athena does (even if you think Athena i ugly, it does this right), rather than opaquely drawing bitmaps and transmitting those to the window system, as GTK and QT do. In the rare case that a backing store is necessary, because large complicated graphics are required, then backing store can be implemented in the application as you mention by using a pixmap. There is absolutely no reason why normal widgets and window layouts need to be back-stored, because if your window/widget system can not redraw all the widgets on the screen in less than 1/60 (1 blank), it is useless and pathetically slow.

The issue in X11 is that because it's a network display protocol, and it makes certain choices to transmit low-level graphics primitives (windows and pixmaps) rather than higher-level objects like widgets and textboxes, it is very difficult to implement synchronous screen updates by on-demand drawing (or it was in the 1980/1990), so it resorts to asynchronous updates, where it redraws the screen regardless if the windows have finished drawing (in fact usually there is no update because X11 doesn't use double-buffering).

It is entirely possible to have backing stores without compositing, compositing without backing stores, and double buffering in either the backing st

"fall-back .. to be eventually depreacated"

[LizardKing]

Oh for fucks sake. I've just switched the wife's laptop from Ubuntu 11.10 to the beta of Fedora 16, since unlike that Unity bollocks at least the GNOME shell has the "fallback" mode that turns it back into something usable.

Re:"fall-back .. to be eventually depreacated"

[PessimysticRaven]

OOoh. I see what you did there!

Seriously, though, I can't wrap my mind around why the most clunky, disgustingly inefficient windows managers are installed BY DEFAULT!

You'd think they were trying to copy Win7 and OS X's shinies in some half-arsed attempt to gain followers...

Oh, wait...

Re:"fall-back .. to be eventually depreacated"

[jawtheshark]

I don't entirely agree. One thing that I liked about Ubuntu is that I could pretty much install it for anyone who wasn't computer literate and have them safely and easily do basic user tasks. To be able to support them well, I tend to use the same settings as they are so that I can help them even when I'm not in front of a computer.

You can imagine that those kind of people are less likely to cope with huge paradigm shifts like Gnome2->Unity? The two most important of these users I have are my own mother and my mother in law. I don't foresee much problems with my mom, she's a science person (Master in Chemistry) and she'll cope. It will take her effort, but she's aware these changes require it. Mother in law though? Oh, boy, I so dread Ubuntu 12.04 LTS (I only give them LTSes)

It's not that I cannot install a different distro or install a different DE. I can, it's just that Ubuntu (10.04 LTS) did give perfectly sane defaults with a reasonable interface with good discoverability. I personally see that gone with Unity.

I have looked into Debian for an alternative, but Ubuntu does give a significant amount of polish (I'd mention the "Language Support" applet, for which I haven't found a decent alternative in Debian. I live in a multi-lingual environment, and it's pretty much the best tool I've seen in any operating system. It's not the only thing ) Linux Mint has been highly recommended on slashdot, and I'll most likely check it out sooner or later. I should also give Lubuntu a shot (LXDE, I use that on my Asus EEE 701 4G). It might be the way out of this mess. When doing a PXE installation of Ubuntu 11.10 it's given as a true option.

All in all, switching to Unity is alienating the userbase. Tech people because they don't like the dumbed down aspect of it, and non-tech people because of the familiarity (and let's face it, pretty traditional way of doing things of GNome2). Except for the light destop environments, I see none of the big ones being even remotely desirable... I know people think that GNome2 looks old, I happen to disagree. It's mature. Iron out the tiny bugs and annoyances and you'd get a rock stable useful UI. However, we can't do that in the open source world. Always, new, alway rewrite alway try out the newest language. Cut it already and realize this needs to stop.

Re:"fall-back .. to be eventually depreacated"

[thsths]

Yes, but XFCE is getting pretty fat, too. It is no fun in a VM or on a netbook. In fact it is using compositing now, too.

I have moved on to LXDE as lightweight system - it still uses a rather traditional window manager instead of an integrated desktop.

Gnome 2 still included

[pavon]

The summary is a troll (as is typical for slashdot). Gnome 2 is still included in Fedora 17. The only difference is that if you have selected Gnome 3 for your desktop (which is default), and GPU acceleration isn't working, it will now fallback to unaccelerated Gnome 3 rather than Gnome 2. Regardless of your opinion of Gnome 3, this just makes sense; it would be much more confusing to get a completely different desktop than you were expecting just because your video drivers got borked. Not to mention it is wasteful to have to install Gnome 2 as a fallback if you want to use Gnome 3.

xubuntu and lubuntu

[nadaou]

thank goodness for xubuntu and lubuntu! kubuntu too... the linux-for-OS-refugees world still has some shining lights.

GNOME is a study in how to not architect software.

[Anonymous Coward]

GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

It basically goes totally downhill after that. This bullshit with GPU acceleration being required in the first place, and then this additional bullshit involving LLVM, is yet another in a long list of flaws and horrible decisions.

I encourage all of the developers that I mentor to use GNOME and to get a good look at its internals. I just make sure that they know not to do what GNOME has done. By seeing the mistakes firsthand, it's less likely that they'll repeat them in the future with the software that they create.

Re:GNOME is a study in how to not architect softwa

[Anonymous Coward]

GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

Nonsense. GObject gives you multi-language bindings for free and if you're just an application developer it only makes your life easier. You can develop GNOME programs in C++, Python, Java or whatever suits your tastes.

I don't think the overhead resulting from using C is substantial at all. Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls. You'll have to back this up if you want me to believe you.

It basically goes totally downhill after that. This bullshit with GPU acceleration being required in the first place, and then this additional bullshit involving LLVM, is yet another in a long list of flaws and horrible decisions.

I encourage all of the developers that I mentor to use GNOME and to get a good look at its internals. I just make sure that they know not to do what GNOME has done. By seeing the mistakes firsthand, it's less likely that they'll repeat them in the future with the software that they create.

I'm not a fan of GNOME and I agree that they are headed in the wrong direction, but the problems are not at all due to GObject or C. Cut the FUD when you criticise GNOME next time.

this would be nice

[Tyrannosaur]

if gnome shell were actually nice. I'm with Torvalds; switched to XFCE

Re:this would be nice

[EasyTarget]

It's the way the Gnome3 devs are all working against each other that really sucks.

You have a half-incomplete tablet UI allied to a half-incomplete laptop UI both of which get on the tits of desktop users;
- and my feeling of 'at least they are going somewhere different and interesting' has evaporated now I see Gnome 3.2 is identical to 3,0 in every single cockup. Only one of the real UI problems has been addressed; and more ill-considered and contradictory decisions have been imposed on us.

Just reached a decent compromise on my machine

[Jack Malmostoso]

Debian Sid introduced Gnome 3 a couple of weeks ago and I had a bit of a tough time to come to terms with it, but now I have reached a good compromise by installing tint2 and the alternate menu extension (which basically brings back the switch off menu item).
I'm rather pleased with this setup and the only thing I am really missing are a couple of applets, but nothing major.

Or, as other have said, XFCE is a great alternative, especially if you NEED external outputs (which gnome-shell still miserably fails to manage properly).

Re:GNOME is a study in how to not architect softwa

[Anonymous Coward]

Thanks for quoting the entire post to make your six-word response.

It's about time...

[Zephiris]

It's about time Slashdot stops accepting 'blogspam' links, such as Phoronix, instead of attributing the actual source itself. Phoronix didn't solve this, a developer did.
A badly written Slash summary (and 'article') which just links twice to the same braindead Phoronix article (which itself is a several day old duplicate) is bad. Very bad.

Dredged from the bottom of Phoronix:
Mailing list post: http://lists.fedoraproject.org/pipermail/devel/2011-November/158976.html
Fedora 17 feature point: https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering

Personally, I have little doubt that the "anonymous reader" is Michael Larabel himself.

Re:GNOME is a study in how to not architect softwa

[Anonymous Coward]

Not the GP, but what he's saying is far more true to my experience than what you're saying. I don't think the GP's comment is spreading FUD, either, but just a truth that many GNOME'ers don't want to hear.

Have you ever tried to use the GObject bindings for other languages? The Python bindings are the only ones that aren't terrible, but they weren't that good either. The rest were very incomplete, very outdated, or didn't exist at all. The theoretical benefits or capabilities of GObject are worthless if we can't use them in practice. I've had a lot more success with interoperability between Java, Scala, and Clojure than I ever have had with any GObject-based code. The same goes for .NET when the languages are C#, VB.NET and F#. Those all work seamlessly with almost no effort, while GObject needs a lot of hand-holding and even then it often just doesn't work.

What the GP says about some C compilers not doing a good job optimizing unusual C code is correct, too. I used to work on a compiler that generated C for a proprietary OO language and this artificial C code confused the optimizers of several popular C compilers. We got much better performance when we wrote our own native back-end. So I could totally see some of GNOME's bad performance being caused by this.

Also, KDE is very good evidence to back up the GP's claims. It's comparable in size and complexity to GNOME, but is written using C++ instead of C. On every computer I've ever used, KDE has been a lot faster than GNOME. It is also a far nicer environment to work with when you're writing code. OO programming is more natural in C++ than it is in C using GObject.

Don't write off the GP's comments as FUD. There's a lot of evidence to show that they're real problems.

Re:GNOME is a study in how to not architect softwa

[PopeRatzo]

Thanks for quoting the entire post to make your six-word response.

It was useful for the poster to quote the entire post because many of us often filter out all posts by Anonymous Cowards. By filtering out the ACs, you avoid a lot of crap and frosty pisses and enthusiastic racist name-calling.

It was an insightful post by someone who didn't care to create an account, even though it's very easy to create an account and Slashdot is very good about not misusing our email addresses. By quoting the good post in full, the GP performed a service to the community.

Re:GNOME is a study in how to not architect softwa

[Anonymous Coward]

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C.

Is that an attempt at recursive humor?

It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place.

Presumably why they now have Vala.

Worse, this sort of code promotes library design that's slow and inefficient.

AKA: Object Orientated?

To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

I'm not convinced by this argument, it's possible to write inefficient code in any language.

While I don't actually like Gnome, being written in C is about the only thing I do like about it. I certainly don't consider GObject/Gtk to be worse than QT or Apples API's.

Re:GNOME is a study in how to not architect softwa

[digitig]

Who says it's not a verb? The Oxford English Dictionary lists it as having been a verb since at least 1818, and as being more specific than "design".

Re:I like Gnome Shell

[RocketRabbit]

None. Not any.

It becomes clearer every day that people hate Gnome 3, and yet even as the soft noise builds to a roar, some people think it's merely a few haters bellyaching.

Listen, people hate the *shit* out of Gnome 3. It seems obvious that what started out as an attempt to create some sort of tablet-compatible UI which is also palatable on the desktop has now become a large liability. Gnome 3 has nothing that users asked for - it has been funded and driven by corporate interests (ahem INTEL) that wish to eventually provide some competition to Android's current domination in the Linux tablet market.

People hate Gnome 3. Developers hate Gnome 3. Gnome 3 is simply one of the worst abortions of a window manager to ever appear on Linux, and the situation is not going to get any better until people start fleeing and distributions leave it in the dust.

The writing's on the wall, but just because you avoid glancing in that direction that does not mean you can expect us all to swallow your fantasy about Gnome 3's awesome suitability.

Re:GNOME is a study in how to not architect softwa

[PitaBred]

You've had AC's disabled for a while, eh? I only ever see a few frosty pisses or goatse's or whatever per discussion, and a lot more useless shit from people who've actually signed in.

What a lot of whiners...

[msevior]

There is a hell of a lot of whining about GNOME 3 here. I'm a free software developer of desktop software (AbiWord). I personally like GNOME 3 and its approach to do a new take on how best to present a computer interface to users. I also maintain systems for my mother and daughter who are definitely not computer geeks. They're both impressed and comfortable with GNOME 3.

So my extremely small sample imply that GNOME 3 is a good step. For the computers geeks out there there a plenty of alternatives. Find the one that works for you.