Slashdot Mirror
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."
Is slow. I'm not sure that this is an advantage.
To offset political mods, replace Flamebait with Insightful.
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.
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.
thank goodness for xubuntu and lubuntu! kubuntu too... the linux-for-OS-refugees world still has some shining lights.
~.~
I'm a peripheral visionary.
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.
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.
if gnome shell were actually nice. I'm with Torvalds; switched to XFCE
I know there's a lot of resistance to GNOME Shell, but it's clearly the future of GNOME (like it or not) and the weird non-3d degraded mode that you get with GNOME 3 + no 3d is something that's not really fit for anybody.
Personally, I really like GNOME Shell and I'm glad to see that it will be supported on older hardware. I always found the decision to completely ignore this hardware to be questionable and damaging to Shell's adoption rate (as if it wasn't going to have a hard enough time to begin with). Surely they could have provided a similar UX without the eye candy for older systems - at least now we have a workaround!
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).
Thanks for quoting the entire post to make your six-word response.
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.
"A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
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.
Err.. The llvmpipe driver is developed by mesa and xorg to provide a software fallback driver that is faster than the dog slow swrast driver. Exactly why is this "bullshit" and a "horrible decision."?
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.
Thanks for quoting the entire post to make your six-word response.
Mod AC up hes his spot on...
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.
You are welcome on my lawn.
... And also, does the above mean that Gnome is no longer using GCC to compile, but switching to the LLVM compiler? ...
LLVM is designed to be modular. It sounds like what they're doing is probably similar to what Apple did a few years back - include LLVM bit-code files for functions that aren't handled natively, then hand those off to libllvm to emit native code when needed.
-Ster
And see a frost piss post...
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
Is that an attempt at recursive humor?
Presumably why they now have Vala.
AKA: Object Orientated?
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.
Yeah. I feel exactly the same. How many people reading this discussion are quietly enjoying GNOME 3 but don't care enough about the arguments to jump into the fray?
^I'm with stupid.^
This driver is part of Mesa. Mesa is not part of GNOME.
This story ties into GNOME, because the driver now supports all the features required of Gnome-shell at an adequate speed.
You're right that Apple does do something similar. Shader compilation uses LLVM and if the graphics card is missing features it gets run on the CPU. You're wrong that xcode has anything to do with this. Xcode uses Clang which is a c compiler. Clang uses LLVM, but clang has nothing to do with 3d graphics.
I would rather people copy each other, than suffer from not invented here syndrome. As LLVM is opensource, having extra contributors should be mutually beneficial.
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".
Quidnam Latine loqui modo coepi?
GObject or C++ or scripting language or whatever - function call overhead is negligible compared to all that work (and make-work) which a typical API function of a typical GUI widget is doing. When for other coders several years ago those same APIs, libraries and languages, and *worse* optimizing compilers, worked perfectly well on 10, and even 100, times less powerful hardware - trying now to blame other coders' ineptitude on GObject, GTK+, C compiler, X server, or whatever, is nothing but pathetic and idiotic.
The tools may be imperfect, but writing good and fast code with them is perfectly possible - *if* a coder knows what he's doing. If GNOME authors wrote a slow monstrosity, it is their own failure and no one else's.
Is that an attempt at recursive humor?
I don't think so because it's confirmed by your good self below:
Presumably why they now have Vala.
Yep, that's why they've tacked on another non-native language.
AKA: Object Orientated?
I believe the point is it's object oriented in the worst possible way.
I certainly don't consider GObject/Gtk to be worse than QT or Apples API's.
Uh, huh.
I often run remote GUI apps over SSH to my Ubuntu notebook. When you say that it doesn't work well with Gnome, does it also apply to single apps designed for Gnome (or designed for Gtk?), and would K* apps work better?
In practice, I regularly use Meld to compare 2 remote files, or Geany to edit them. As far as I understand, these 2 happen to be designed for Gnome/Gtk, rather than for KDE.
Would I be better off selecting KDE apps instead, or does it make no difference if I don't actually run the whole desktop, and just start a single app from my CLI SSH session?
Perhaps you should stop filtering ACs, in order to not shit-up Slashdot with reposts just to keep you happy?
Syllable : It's an Operating System
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.
> 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.
That's hardly a surprise. All JVM languages use the same object system underneath and were explicitly designed to interop with it. Same for CLR languages. When you use GObject, you are using it as a portable, but foreign object system that has to co-exist with the native one (like Python's). This is not poor design. It's a good work-around, given the constraints.
It's one thing to discuss whether GNOME should have been in C++, but another to compare it with JVM/CLR features. Core libraries should be native, not byte code.
It's British English, dick'ead.
I enjoy Unity and/or Gnome Shell. I'm the 1%
When ideas fail, words become very handy.
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.
My blog. Good stuff (when I remember to update it). Read it.
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.
If Mesa is getting a better software rasterizer through LLVMPipe it means that GNOME Shell (and KDE, Unity, xfce et al) can support users of older hardware without constraining what they can do that. That ultimately means better performance for the majority who do have GPUs, and it also means that Linux as a whole offers an experience that can compete against desktops running on other operating systems.
I like Gnome Shell. I find it simple, fast and intuitive. I just don't shout as loudly about it as the haters, because I have better things to get upset about.
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.
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.
You are incorrect here. In C++, if you choose to make virtual calls, you pay the price of indirection via a vtable (this pointer). That's it. You only pay the price in classes which have virtual methods. With GObject, all classes contain a vtable, i.e. all class methods take a pointer to the type instance, which contains within it a pointer to the vtable. Every GObject instance contains this overhead, which makes instantiation of GObject expensive, and additionally increases the memory required for every object. In comparison, you don't pay this overhead for C++ classes unless you actually require it. This isn't including the overhead of additional GObject features such as properties, which are both inefficient to process and are type-unsafe, and the use of "construction properties" in object instantiation. What makes it truly awful is that all this work to implement OO in C is mostly done by hand! You have to manually create your own vtables; you have to manually cast all types to the correct type, and if you get it wrong the compiler won't typically tell you. You have to understand the intricacies of how a C++ compiler works to implement an inferior version in C! Why would anyone willingly inflict this upon themselves?
But this is only the beginning of the GObject problems. When using GObject, the type resolution is done at run-time. Not only does this make programming unsafe--the many typecasts can hide typing issues, leading to failure at run-time rather than at compile-time, it has additional run-time overheads. Here are a few reasons: G_TYPE_CHECK_INSTANCE_CAST, G_TYPE_CHECK_CLASS_CAST, G_TYPE_CHECK_INSTANCE_TYPE, G_TYPE_CHECK_CLASS_TYPE, G_TYPE_INSTANCE_GET_CLASS. And you'll also need to check every function argument taking a GObject to make sure it's of the correct type with G_TYPE_CHECK_INSTANCE_TYPE (or commonly using a wrapper around it). This is not a cheap operation, it has to check the GType type register, which involves a string lookup in a hash table (GQuark, at least last time I looked). So you have several of those for every function call if you actually investigate the use of all the uppercase casting macros, and again inside the function. This is mostly absent for C++ code (the type checks and casts are done at compile-time), and C++ RTTI involves simple pointer comparisons of typeinfo objects; much faster, and again type-safe.
Here's an example of class using GObject: header source
This is the same class using C++