Matthew Garrett ([info]mjg59) wrote,
@ 2009-06-23 19:16:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:advogato, fedora

It's now been over 6 months since Poulsbo hardware with Intel's GMA500 graphics core started shipping in volume. And we're still utterly lacking in any sort of worthwhile driver. It's an impressive turnaround from the recent days when the straightforward recommendation for mobile Linux hardware was "anything that has lots of Intel stuff in lspci", and while the Poulsbo situation in itself doesn't change that hugely it's potentially symptomatic of a worrying trend within parts of Intel.

The first thing to realise here is that, like most large companies, Intel consists of a large number of business units with different priorities. Their open-source technology center has historically had responsibility for providing Linux support for hardware, but this obviously depends on other business units cooperating with them. And there's strong evidence that many of those business units don't get it.

There's been signs of this for some time. Back before the days of the Intel X.org driver gaining native modesetting support, some people ran the Intel embedded graphics driver. This was (is?) a closed X driver that was able to provide native modesetting on platforms that could only otherwise be run at incorrect resolutions. One business unit was shipping a driver that was more functional than the official Intel Linux driver. To the best of my knowledge, none of that code was ever used in the rewritten Intel driver that now provides the same features.

Poulsbo is another example of this. Intel wanted a low-power mobile graphics chipset and chose to buy in a 3D core from an external vendor. IP issues prevent them from releasing any significant information about that 3D core, so the driver remains closed source. The implication is pretty clear - whichever section of Intel was responsible for the design of Poulsbo presumably had "Linux support" as a necessary feature, but didn't think "Open driver" was a required part of that. There's not a lot any other body inside Intel can do once IP-limiting contracts are signed and the hardware's shipping, but it ends up tarnishing the good reputation that other parts of Intel have built up anyway.

And while Poulsbo is the most obvious example of this to date, it's not the only one. Intel recently decided to make the EFI development kit discussion lists private. Various drivers for Moorestown (the followup platform to Poulsbo) have been submitted to the Linux kernel, and while they have the advantage of being GPLed they have the disadvantage of being barely above the level of typical vendor code. Objections that chunks of them simply don't integrate into Linux correctly has done little to get these problems fixed - I still have no real idea how the runtime interface to power management on the SD driver is supposed to be used, but I suspect the answer is probably "badly".

This all makes sense if you assume that there are large groups of people in Intel who don't talk to each other. But to the casual observer it just looks schizophrenic. Explaining to an irate user that the Intel who shipped a closed Linux graphics driver is only barely the same Intel who contribute so much to architectural improvements in the Linux graphics stack doesn't make their hardware work. And while all of this confusion is going on, Intel's competitors are catching up. Atheros are now making significant contributions to the state of Linux wireless. AMD are releasing graphics chipset documentation faster than Intel, and radeon support is improving rapidly.

Is the future going to be one where we can no longer simply say that Intel hardware will Just Work? Is their work on Moblin (easily the most compelling Linux UI for netbooks) going to be wasted on the broader Linux community because it'll mostly end up running on hardware that's not supported by the mainline Linux kernel? Does Intel have a real commitment to open source, or is that being lost in the face of short-term requirements?

Intel need to demonstrate that they have a company-wide understanding of what Linux support actually means or risk losing much of what they've earned over the past few years. I'm desperately hoping that Poulsbo and what we've seen so far of Moorestown are the exception, not the future norm.




(28 comments) - (Post a new comment)

Poulsbo was just the start
[info]macemoneta.myopenid.com
2009-06-23 09:56 pm UTC (link)
It used to be that Intel was the stable open source choice. It's not the GPU you get to play high-end games, but it was the one to get to insure that things just worked.

That's why when I bought a new motherboard, I selected one with G45/X4500HD. That was a mistake; X lockups, system hangs, X crashes, screen corruption. I ended up going from Fedora 10 to Fedora 11 to try to find some stability in the newer driver. As of today, it is stable, but only if I boot nomodeset and don't use Compiz. There are lots of bugs in bugzilla and at freedesktop.org.

While it's not fair to put all the blame on Intel, there really does need to be some coordination for the introduction of new hardware and Xorg driver releases. We saw what happened to Windows Vista when Nvidia didn't have their ducks in a row.

There's a great incentive for the hardware division to start shipping as soon as possible, but Intel, AMD/ATI, and Nvidia need to recognize that a lack of coordination between hardware and software leads to bad PR and loss of sales.

During this video fiasco, the ONLY stable full-function driver was the Nvidia PROPRIETARY driver. That's what I had to recommend to those that were looking for hardware at the moment. I wonder how many others were put in the same situation?

(Reply to this) (Thread)

Re: Poulsbo was just the start
(Anonymous)
2009-06-23 10:36 pm UTC (link)
During this video fiasco, the ONLY stable full-function driver was the Nvidia PROPRIETARY driver

Problem is, although the nVidia driver is very good at what it does (which is why I use nVidia hardware on my desktop box), it's also a complete non-participant in the changing world of Linux graphics. No kernel mode setting, no support for DRI2, TTM, or anything relating to the 'Linux' way of doing things.

Now, in part, that's what makes it reliable - it's not going through the changes that other drivers are. But I think it will leave that driver somewhat isolated in future, not fitting in as well as it does now.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
(Anonymous)
2009-06-23 11:49 pm UTC (link)
It does all of those things itself, and has more mature implementations. You can grumble about nvidia not sharing their code, but it's hard to fault them for not using the mainline implementations of these things - their own stuff works today (and in some cases worked 7 years ago too). And by virtue of providing both the kernel module and the client X driver, they gain nothing by conforming to mainline interfaces like DRI2, GEM or KMS.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
(Anonymous)
2009-06-24 06:27 am UTC (link)
"It does all of those things itself, and has more mature implementations."

No. It doesn't. There is no support for KMS at all. They are lagging behind and always will

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
[info]macemoneta.myopenid.com
2009-06-24 09:41 pm UTC (link)
There's no (usable) KMS support for my Intel G45 either. The presence or lack of a fractional-second of flicker on boot is not a deciding factor for many people.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
(Anonymous)
2009-06-25 07:20 am UTC (link)
"There's no (usable) KMS support for my Intel G45 either"

Actually there is. Using it right now in Fedora 11. Getting merged upstream in the next release.

"The presence or lack of a fractional-second of flicker on boot is not a deciding factor for many people."

You are completely clueless if you think KMS is just about avoiding flicker.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
[info]macemoneta.myopenid.com
2009-06-25 09:49 pm UTC (link)
Anonymity and ad hominem attacks; the backbone of Internet discourse.

The internal benefits of KMS are of no concern to a user that can't get their video card to work.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
[info]thefowle
2009-06-26 04:27 pm UTC (link)
"The presence or lack of a fractional-second of flicker on boot is not a deciding factor for many people."
"You are completely clueless if you think KMS is just about avoiding flicker. "
"Anonymity and ad hominem attacks; the backbone of Internet discourse."

That wasnt me, but that was not an ad hominem attack, it was an assertion, and a valid one at that.

Yes KMS is worthless if a user cant get their video card to work. What does that argument prove, what does it address? a) its already been asserted that your grumble about G45 is invalid, b) kms is still young anyways, but its the way forward for our video ecosystem, and theres an expectation drivers get updated for KMS.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
(Anonymous)
2009-07-03 09:08 pm UTC (link)
"that was not an ad hominem attack"

Yes, by definition it was.

"a) its already been asserted that your grumble about G45 is invalid"

An assertion is not a fact. Look at bugzilla for fedora and upstream.

It's disheartening to see that Linux discussion is still living down to this level. This is why users use Ubuntu; their forums orient toward support, not shooting the messenger.

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
[info]thefowle
2009-07-04 04:24 pm UTC (link)
Ad hominem attacks are those levelled against a persons character, rather than the debate. In this case, what was argued was that the author knew too little about whats being debated. And thats factually true, it stands as a production of evidence relevant to the debate, based off the inability to cite anything but one trivial example of how KMS would help. The following are examples of where KMS would help:
1. More consistent & performant suspend/resume
2. Faster virtual console switching
3. Root-less X for more secure computing
4. More reliable debugging / less hanging
5. One consistent modesetting platform

This bug links against quite a few of the G45 issues. There appears to have been a colossal amount of issues end of april, but most of the issues seem to have been resolved mid / late may.

Fedora jumped the gun by introducing known experimental code, and unfortunately thats signalled the end users that they can join the wagon train then grief when things start breaking.


I'd ask the reciprocal rhetort; is this what linux is degrading into, a luser base that grumbles bitterly every time coders have to introduce a little instability to pave the way forwards? A base that is more interested in their own system working the way it used to, versus a focus on advancing technology and building a better path forwards? Unequivocally I'd answer: I'd much rather see Linux be condescending and elitist than suffer it being self-entitled and privledged.

(Reply to this) (Parent)

Re: Poulsbo was just the start
(Anonymous)
2009-06-25 09:57 am UTC (link)
Well, KMS should allow printing a nice panic screen even from X. Given the great stability status of the nVidia drivers, I guess it's not relevant there, though.

(Reply to this) (Parent)

Re: Poulsbo was just the start
(Anonymous)
2009-06-25 08:30 pm UTC (link)
The Intel drivers hit a low point in January.

Too much 'choice', which unfortunately is usually a bad thing. (because it always seemed that people in Linux have to choose between things broken in different ways rather then choose things that work in different ways)

XAA, EXA, UXA, KMS, X.org mode setting, DRI, DRI2, GEM unified memory management, Xorg/OpenGL/etc individual memory management

DRI2 + EXA + KMS or
DRI2 + UXA + KMS or
DRI + XAA + Xorg mode setting?

etc etc etc.

With the drivers that will be in the next stuff they are removing a crapload of choices and configuration options which should yeild a much more smaller driver with better stability and easier time maintaining it. The only choice is going to be KMS + UXA + DRI2 and I wholeheartedly welcome it.

Relying on Nvidia to properly shoehorn it's Windows XP driver into the Linux kernel causes as many problems as it solves. It's not a very good general solution. Linux absolutely needs better if it's going to be at all competitive.

Don't forget that Nvidia is the company that is telling people to avoid working on Linux and Android on embedded systems and choose Windows CE. They obviously care _MUCH_ less about their end users and people relying on their hardware then their own bottom line and providing a technically superior solution. (why? Because WinCE is shit beyond belief)

ATI is looking very strong on the open source front. But they are going to have to go through the same transition that Intel has just gone through by switching from the current model of 'unique memory management schemes for each API + giving whole X Server direct access to the hardware' to 'unified memory management and X Server going through application APIs controlled by the kernel like any sane application should'.

It's not a fun transition.

(Reply to this) (Parent)

Re: Poulsbo was just the start
(Anonymous)
2009-06-26 11:49 am UTC (link)
I really wish I could use this argument against proprietary nvidia drivers. I really wish I could praise intel for their commitment to advancing not only their own Xorg driver, but Xorg infrastructure itself.

But, alas, new intel drivers + Xorg newer that 1.4.x is an epic fail. Either you have too old kernel, xorg or intel driver, meaning no acceleration, crashes and lockups - or you are using git checkout and you are told "that stuff isn't stable yet". And you still get lockups at different places.

Apparently DRI2 abi was broken, recently, so it looks like I'll be "lagging behind" for the foresaable future.

(Reply to this) (Parent)

NVIDIA and old cards
(Anonymous)
2009-06-25 09:59 am UTC (link)
It's true that NVIDIA are very good at being closed (if performance is all I care about then NVIDIA often seems like the way to go on Linux).

However if you are an owner of an older card you will only see maintenance releases and no new features. There are NVIDIA cards quite capable of AIGLX that will not have that support in the closed drivers. And just like all drivers (closed or open or whatever) there are bugs NVIDIA knows about that lock the machine that they will never fix as there is no financial incentive with older hardware.

The real killer is that people won't look at your bugs and you can never be sure at first glance whether that crash/lockup is due to the binary drivers or a genuine bug - it feels like you are cutting yourself from support as neither party will help you if they think the other side is to blame.

(Reply to this) (Parent)(Thread)

Re: NVIDIA and old cards
(Anonymous)
2009-07-03 09:03 pm UTC (link)
"However if you are an owner of an older card you will only see maintenance releases and no new features. There are NVIDIA cards quite capable of AIGLX that will not have that support in the closed drivers."

I have a 32MB NV17 card (8+ years old now), and it runs compiz just fine with the (updated) nvidia closed legacy driver. While nvidia doesn't add new features to legacy hardware, they do maintain the drivers so they remain functional with new kernels/xorg.

(Reply to this) (Parent)(Thread)

Re: NVIDIA and old cards
(Anonymous)
2009-07-17 10:58 am UTC (link)
I have a 32MB NV10 (9 years old now) and it doesn't run compiz on "plain" X with the NVIDIA closed source legacy driver. There are also lock-the-system-up bugs that NVIDIA has known about for years that haven't been fixed. Last time I tried I couldn't have a working suspend to RAM if I used the in kernel AGPGART with the closed source drivers. Who knows what the problem is? If only NVIDIA would tell the kernel maintainers perhaps it would be fixed?

It's not a complete disaster but for some of us it hasn't been all roses in closed source NVIDIA land (and some people have been there for many years).

(Reply to this) (Parent)(Thread)

Re: NVIDIA and old cards
(Anonymous)
2009-08-06 04:47 pm UTC (link)
I think that one of general problems with Linux is that people are keeping old junk working rather than focusing on new hardware.

NV10? GeForce 256 is looong gone. Get a card made in 21st century.

What next? Were going to complain that new kernel is not supporting ISA bus on 486?

Much bigger problem currently is support for that GMA500. I'm getting new computer and I can't get decent desktop experience because there is no way to setup correct resolution. That is the problem. Not bug on NV10.

Put that card in junk white box to show it running Quake 2 to your children in few years.

(Reply to this) (Parent)(Thread)

Re: NVIDIA and old cards
(Anonymous)
2009-09-02 09:29 pm UTC (link)
If you think people shouldn't continue to use perfectly functional hardware they've bought, that continues to meet their requirements, then maybe you should send them some of *your* money to buy newer hardware. Otherwise, your argument doesn't stand.

(Reply to this) (Parent)(Thread)

Re: NVIDIA and old cards
(Anonymous)
2009-09-04 08:42 am UTC (link)
But he implied ongoing support as a requirement. It is unreasonable to expect hardware to be supported forever. Especially in open source! Resources are limited and often it is just better to spend $20 on ebay, craigslist, whatever, than have someone track down bugs or add features for a small group. Its a simple cost-benefit analysis and its just selfish whining to argue against it.

Old hardware is just as capable as it was in the past. You don't NEED to upgrade to newer versions of X, kernel, whatever.

(Reply to this) (Parent)

Re: Poulsbo was just the start
[info]https://me.yahoo.com/paul_wayper#799c7
2009-09-02 06:20 am UTC (link)
I talked to Dave Airlie a while back and he made the point that nVidia's primary market is in performance hardware. Everyone knows that all the manufacturers are disassembling each others drivers, but no-one can really use that information first-hand (they use "clean room" implementation). So any extra lead time they can get on competitors - by keeping their clever secrets in binary blobs rather than showing everyone the source code - is actually quite valuable. This means they're really not going to bother open-sourcing anything that actually helps.

OTOH, the nouveau driver is now good enough that it's better than nVidia's public 2D driver (nv). nVidia have said (according to Dave) that they're not going to interfere in nouveau's development, presumably because it actually means they can now drop the nv driver. We've also got various groups wrapping up the binary drivers in easy-to-install packages, so (like all good things) the community is getting on with doing what the developer should be doing.

What we need, IMO, is a way to engage nVidia in the process of maintaining their drivers that doesn't involve them divulging what they see as trade secrets, but still helps the community. For example, getting them involved in running their own RPM and DEB repositories (rather than 'download this blob' archives), or adding features they need to the kernel. Things that can help them reach out a bit but still stay in their comfort zone. Things that won't have them scurrying for lawyers checking whether this means they're allowed to do it. (The kernel thing may be going too far, because we've seen how well that's gone so far with embedded hardware developers, but, hey, whatever works.)

That's what we have to propose to nVidia, Intel, Via and every hardware manufacturer we want to work with. We should be saying "Help Us Help You", rather than "We Want Everything On A Stick".

Have fun,

Paul

(Reply to this) (Parent)

Re: Poulsbo was just the start
[info]thargol
2009-06-24 11:37 am UTC (link)
I ended up going from Fedora 10 to Fedora 11 to try to find some stability in the newer driver

I'd like to try that, too. But F11 won't even install on my box :-(

(Reply to this) (Parent)(Thread)

Re: Poulsbo was just the start
[info]thargol
2009-06-24 11:38 am UTC (link)
Bah. Thread fail. Today is not going well...

(Reply to this) (Parent)

mjg quote
(Anonymous)
2009-06-25 10:04 am UTC (link)
"Intel's commitment to providing high-quality drivers that meet the needs of the mobile Linux community is second to none."

It still is second to none - who else is doing better? :(

Linux land - where you have to take what you are given and daren't complain ( http://www.linuxjournal.com/content/cisco-settles-where-here ).

(Reply to this)

Natural law
(Anonymous)
2009-06-25 12:32 pm UTC (link)
Because Intel holds a monopoly, natural laws will ensure - this time via the driver situation - that other vendors do catch up.

(Reply to this)


[info]thefowle
2009-06-26 04:22 pm UTC (link)
one of my favorite reasons to hang around in intel's #mobilin is to hear gma500 discussion. even the intel people in the channel are sick to death. it warms the curmudgeonly cockles of my heart to see more public facing well phrased commentary.

intel just went from 7m to 31m shares of Imagination Technologies (3.2% to 14%). maybe now that they own more of the company they'll have more leverage to improve the 1990's class vendor driver released for PowerVR tech. the question i have is, what about the rest of the PowerVR family? Whether Apple's 3.6% share in Imagination gets leveraged for better drivers, will the rest of the ARM world ever be able to expect modern video drivers from PowerVR?

(Reply to this) (Thread)


[info]thefowle
2009-06-26 04:44 pm UTC (link)
comrade Semaphore of arstechnica just pointed this out to me; Apple today upped its share from 3.2% to 9.6%. http://www.techreport.com/discussions.x/17126

(Reply to this) (Parent)

Frustration
(Anonymous)
2009-07-08 06:47 pm UTC (link)
Yes, recently one begins to wonder. Why would intel suddenly stop supplying linux drivers for a platform. The very least the could do is to make an official statement, then release closed-source drivers for all distributions now. Then they deal with the legal issues and release an open source driver - hopefully with full energy saving, KMS and VA-API/VDPAU support. That's when I'll buy my MSI U110 with the GMA500 Poulsbo chipset.

(Reply to this)

Give us a descent Poulsbo driver for Linux
(Anonymous)
2009-08-03 08:18 pm UTC (link)
Open-source or closed... just give us a modern driver with stable 3d and working video acceleration (GMA500 support). C'mon Intel.. I'm never going to buy another netbook based on the Intel Platform after this Poulsbo debacle, unless you can make good and get some descent Linux drivers released!

(Reply to this)


(28 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…