An Early Look at GNOME 3.0 (Linux.com) [LWN.net]

An Early Look at GNOME 3.0 (Linux.com)

Posted Mar 2, 2011 7:06 UTC (Wed) by drag (guest, #31333)
In reply to: An Early Look at GNOME 3.0 (Linux.com) by elanthis
Parent article: An Early Look at GNOME 3.0 (Linux.com)

> Metacity needs a new, stable compositor, that can use xrender or opengl depending on hardware/driver capabilities.

You have a lot of points that are valid if they matter to you. It's your time and I would be happy seeing you doing something that would make you happy to do. Seriously.

But this is a red herring. "2D acceleration" no longer exists for modern hardware, or at least any hardware going forward. You'll probably see it on embedded systems or Via's crap, but all that is going to go away also. One way or the other. This means that it only requires marginally more work to get basic OpenGL support then fast XRender support. And OpenGL is more important then XRender as on modern CPUs the 2D performance is just fine on pure software.

This means your choice isn't going to be between 2D or 3D acceleration... it's just a choice between having acceleration or not at all. Compositing is going to suck no matter what if you don't have decent acceleration. I think a Xrender-based compositor has VERY limited utility.

But you can do what you want. I just don't want you to put a lot of effort into something and you end up with the last time somebody put a lot of work behind a serious effort into (semi-)forking Gnome.

http://www.akcaagac.com/index_goneme.html

On a semi-side note.

I recently built a new machine using All-AMD chipsets just because I appreciate their efforts. AMD CPU, AMD mainboard chipset, and ATI 5770-based video card. I was afraid I was making a huge mistake, but with a rather insane setup using xorg-edgers PPA (beta Mesa + New X + beta ATI drivers) on Ubuntu 10.10 I am very surprised by the quality of the experience. I'm even running 2.6.38 kernel.
I am using the Gallium drivers and despite throwing random games at it running compiz, flash video, (simultaneously) and trying different things that normally caused issues for me in the past in Linux with OSS drivers.... it's been dead stable. It's amazing and I doubt other people will have similar experiences, but for me it's working fantastically.

to post comments

Devils are in the details

Posted Mar 2, 2011 9:56 UTC (Wed) by renox (guest, #23785) [Link] (9 responses)

You forget that currently on Linux, the HW accelerated video drivers are not really mature so using fewer functionalities ("2D" acceleration) may be a wise choice to ensure better stability, easier debugging..

So don't claim that 2D acceleration is identical to 3D acceleration even if they use the same hardware and drivers: this is only true if the drivers are flawless..

Devils are in the details

Posted Mar 2, 2011 12:11 UTC (Wed) by drag (guest, #31333) [Link] (8 responses)

> You forget that currently on Linux, the HW accelerated video drivers are not really mature so using fewer functionalities ("2D" acceleration) may be a wise choice to ensure better stability, easier debugging..

It's really bad form for applications developers to be forced to hack around Linux being shitty. It's better just to fix Linux and application developers can concentrate on using the APIs that are most appropriate for what they want to do.

Otherwise what your really doing is forcing the application developers to force users to make the choice between something that runs like crap versus something that crashes their computer. Choice is not a good thing when all the choices suck.

Devils are in the details

Posted Mar 2, 2011 13:16 UTC (Wed) by mjthayer (guest, #39183) [Link] (4 responses)

> It's really bad form for applications developers to be forced to hack around Linux being shitty. It's better just to fix Linux and application developers can concentrate on using the APIs that are most appropriate for what they want to do.

Currently that means using proprietary graphics drivers for many people, which is something a lot of Linux users don't feel comfortable with. As far as I can see, the Nouveau people and their colleagues are putting in a heroic effort to "fix" their bits of Linux, but it is hard for them to promise anything on a predictable time scale.

Devils are in the details

Posted Mar 2, 2011 13:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

With just open source drivers (including Nouveau) in Fedora 15 branch, GNOME Shell seems to be work surprising well on most hardware. So I would say, we are almost there already.

Devils are in the details

Posted Mar 2, 2011 14:14 UTC (Wed) by mjthayer (guest, #39183) [Link] (2 responses)

> With just open source drivers (including Nouveau) in Fedora 15 branch, GNOME Shell seems to be work surprising well on most hardware. So I would say, we are almost there already.

The Nouveau people are still very cautious regarding their 3D support, and warn people not to use it on production systems. Of course delivering more than they promise is much better than promising things and not delivering...

Devils are in the details

Posted Mar 2, 2011 16:34 UTC (Wed) by drag (guest, #31333) [Link]

I am surprised by the Gallium drivers at this stage in the game. I can't speak for Nvidia, but the AMD stuff for 57xx hardware has worked out great for me (when using xorg-edgers PPA for Ubuntu and 2.6.38)

It's actually faster then the older more traditional DRI drivers already.

I am cautiously optimistic that we have reached a similar situation with graphics that we saw with wifi... were the introduction of mac80211 protocol stack actually provided the basis for making it easier to write great working drivers for the majority of the hardware.

Devils are in the details

Posted Mar 3, 2011 9:46 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Red Hat has Ben Skeggs, one of the primary developers of Nouveau and Fedora benefits a lot from that expertise and can afford to be ahead in bug fixes and sometimes features.

Devils are in the details

Posted Mar 2, 2011 14:01 UTC (Wed) by renox (guest, #23785) [Link] (2 responses)

> It's really bad form for applications developers to be forced to hack around Linux being shitty.

Well it's called being pragmatic and wanting to have your application being available now, not several years in the future..
KDE developers do maintain a 'blacklist' list of features, but apparently there still wasn't enough testing (perhaps a lack of communication?) as I remember reading some complaints about HW-acceleration bugs..

>It's better just to fix Linux

Except that it's just wishful thinking:
1) some HW don't have open specifications!
2) Application developers may not own the problematic HW
3) plus fixing HW drivers (especially complex one such as 3D drivers) is a very different skill than developing applications.

>[cut] Choice is not a good thing when all the choices suck.

Welcome to the real world.

Devils are in the details

Posted Mar 2, 2011 14:40 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

"plus fixing HW drivers (especially complex one such as 3D drivers) is a very different skill than developing applications."

No. It may require different knowledge, but the skills are exactly the same.

Devils are in the details

Posted Mar 2, 2011 16:21 UTC (Wed) by drag (guest, #31333) [Link]

> Except that it's just wishful thinking:

So is having a good experience with a desktop that is designed to both use XRender and OpenGL to do the same thing. :P

> 1) some HW don't have open specifications!

Yes. This sucks. But there is plenty that do, or at least are 'open enough' that they work out well. Nowadays we have enough hardware on the market made by Linux-friendly-enough companies that I think it's pretty reasonable to expect that if people want to run Linux with the "Full Desktop" experience that they can obtain the necessary hardware.

And like I mentioned before: On modern hardware there is no longer 2D. It's not simple like that anymore. Drivers capable of driving XRender are going to be capable of doing other stuff. It's a API that is designed for hardware that doesn't exist anymore, I suspect. I am sure that other people understand the details better.

What we really need is a DE environment that is willing to depend on fully functioning subset of a particular popular API. OpenGL is probably just fine in this regard. It should concentrate on just working with that set of assumptions. Not trying to support multiple APIs and forcing users to choose when they have neither the knowledge of the hardware or understanding of the environment necessary to make a proper choice.

Then we need a 'lite' fall back were there is no acceleration available at all. That all your expected to be using is just pure software rendering or bit blotted display or something like that. Even if it ends up slow because application developers learn to depend on a properly configured computer it is not terribly important. It just needs to work.

> 2) Application developers may not own the problematic HW

This is what quality assurance and test suites are there to deal with.

Live CDs, usb drive images, automated benchmarks. It's easy nowadays to setup previews and things that people can just download and run. No compiling necessary or deep understanding. Trace logs and scripts to help providing debug information to developers should be built into the evaluation environments and nice documentation on what developers want needs to be provided. Information on the experience of the tester can be uploaded automatically or be sent with a press of a button.

It's often very useful to have the folks that QA be completely different from the folks that develop. Programmers are often 'too close' to the software to be able to see how users will approach it and what issues they will find. This helps issues get identified quicker in many cases.