NVIDIA Denies Opening Up Its Driver

[phoronix]

Phoronix: NVIDIA Denies Opening Up Its Driver

Yesterday we reported on the Linux Foundation's message they have issued on the behalf of more than 140 kernel developers: Binary-only kernel modules are harmful and undesirable. While no vendor was singled out in this message, the biggest hardware manufacturer that has yet to provide any real level of open-source support is NVIDIA Corporation. Over the past few months, however, we've received word from our sources that NVIDIA may be planning an open-source strategy...

http://www.phoronix.com/vr.php?view=NjU0NQ

[ethana2]

I'd donate money to fund a third party army of reverse engineers.

Buy a bunch of people a recent nvidia card, have them produce public domain docs of every transistor down to the HDCP implementation..
get nvidia's high end cards blacklisted by windows vista for any and all secure high definition media playback...

[Redeeman]

I'd donate money to fund a third party army of reverse engineers.

Buy a bunch of people a recent nvidia card, have them produce public domain docs of every transistor down to the HDCP implementation..
get nvidia's high end cards blacklisted by windows vista for any and all secure high definition media playback...
if you know of such an effort, a sort of dedicated warfare against nvidia, please please let me know, ill happily support it

[duby229]

Sorry but I dont think some of the sentiments in that article are entirely realistic, or for that matter even close... Sounds like propaganda against the kernel developers to me. How would properly and completely supporting an open driver cause workstation users to pack up and move to another OS? Really? I would like to try and understand the logic behind that.

I would like to try and steer clear of subjective ideologies, and instead stick with facts. Fact 1: The only limitations to the open drivers are the ones that ATi artificially imposes. Fact 2: It is only the artificially imposed limitations that would prevent workstation users from adopting open drivers.

Seems pretty cut and dry to me. If properly and completely supported, an open driver can and will be better then any closed driver could possibly be. Ever. How would a stable and functional open driver, drive workstation users away? Seriously, I'd like to try and understand the logic behind this reasoning.

[ethana2]

It wouldn't be a war against nvidia so much as it'd be an effort to remind them that they're /hardware/ vendors, and they should keep it that way.

I think it's worth it for every linux user with an nvidia card to pay the cost of the card as donation to such an effort, because a gpu is only as good as its drivers....

I'm getting an Ubuntu Dell w/ nVidia GeForce 8400m GS soon (no ati option), so for me, such a donation would be around $150.

[Redeeman]

well.. it SHOULD be warfare, they deserve it..

But again, if you hear of some effort, please inform me

[ethana2]

Redeeman: we don't want to completely alienate the company while there's still some hope of them coming around.

[Malikith]

Redeeman: we don't want to completely alienate the company while there's still some hope of them coming around.

Not with the 4870 just around the corner... Wait till you see what that thing can do. Hahaha ;), but on the warfare part, I'd give it a little more time. Just a little more, but not much.

[Redeeman]

Redeeman: we don't want to completely alienate the company while there's still some hope of them coming around.
nvidia has had plenty of chances, if i had the means, i'd gladly invalidate hdcp capability of all current nvidia products, thats not nearly as big a punishment as they deserve.

[ethana2]

Theirs is what used to be the mindset of everyone, even ati and intel at some point in the past-- i would attribute their problems to obselete thinking rather than malevolence. If they really hated us we'de have no drivers at all.

[bridgman]

I would like to try and steer clear of subjective ideologies, and instead stick with facts. Fact 1: The only limitations to the open drivers are the ones that ATi artificially imposes. Fact 2: It is only the artificially imposed limitations that would prevent workstation users from adopting open drivers.

Wasn't this an article about the other guys ? How did ATI get involved ?

Seems pretty cut and dry to me. If properly and completely supported, an open driver can and will be better then any closed driver could possibly be. Ever.

Open drivers can be better if the same development resources (or more) are poured into them. That's where it gets complicated.

Workstation customers make purchasing decisions based on proprietary software features and performance, which HW vendors spend a ton of money developing and don't want to give away to their competitors. The existence of open source drivers is not the issue, it's the implicit "and then we'll ban closed source drivers" that would be a problem for workstation customers.

Workstation seems to be an exception to the typical user base, since the "Linux workstation market" is really the old "Unix workstation market", which didn't have a problem with closed source drivers.

How would a stable and functional open driver, drive workstation users away? Seriously, I'd like to try and understand the logic behind this reasoning.

This is easy. Linux workstation customers expect feature and performance parity with Windows, which means either the same development cost for 1/10th the market size or sharing code between the OSes. Practically speaking, that means the Linux workstation drivers are going to share a lot of code with drivers from other OSes, which in turn means that "opening up the drivers" puts your competitive edge at risk in all OSes not just Linux.

We adopted a two driver strategy because we felt that workstation absolutely needed a closed source solution (because of the market pull for parity with Windows and the competitive challenges that brings) while most other Linux users could be satisfied with an open source stack that had all the important functionality but not the proprietary features or performance work which feeds the workstation market.

Our workstation customers felt that it would be handy to have an open source driver which could be swapped in to confirm that a kernel problem was in no way related to the binary graphics driver, but every one I spoke with (including both ATI and NVidia customers) said that what they cared about was performance and stability on a standard commercial OS distribution (typically RHEL or SLES/SLED), not open-ness or ability to work across arbitrary distros.

[Redeeman]

We adopted a two driver strategy because we felt that workstation absolutely needed a closed source solution (because of the market pull for parity with Windows and the competitive challenges that brings) while most other Linux users could be satisfied with an open source stack that had all the important functionality but not the proprietary features or performance work which feeds the workstation market.

Our workstation customers felt that it would be handy to have an open source driver which could be swapped in to confirm that a kernel problem was in no way related to the binary graphics driver, but every one I spoke with (including both ATI and NVidia customers) said that what they cared about was performance and stability on a standard commercial OS distribution (typically RHEL or SLES/SLED), not open-ness or ability to work across arbitrary distros.

Well.. as long as the free ati driver gets fullfeatured opengl, xv, and reasonable performance, i dont care at all what stuff amd does with their binary stuff.. and the same would be true for nvidia, not that i EVER plan to again purchase an nvidia product given that the AMD commitment holds.

[kriko]

I'm fine with binary drivers, but what irritates me is they are slow when it comes to fixing things.
New nvidia graphic card series have terrible performances under 2d desktop and they are just telling us - we'll fix this in near future. But when will this near future come (some bugs are 1+ year old!)? There are also a lot of other unfixed things that needs to be worked out, but it seems they don't care much. I'll go with AMD next time when I'm buying a graphic card.

[d2kx]

If the performance of the open source AMD drivers will be at least 75%, which is still some great work to do, then I think most people (home users) will use them over the proprietary one in the future as Xv and other important features should be avaible, too. With the AMD open source plan, I would have guessed that nVidia really has to do the same to continue selling cards for the non-Windows market, but it seems that they believe in something different...

[duby229]

Wasn't this an article about the other guys ? How did ATI get involved ?


Substitute ATi for nVidia. Same difference really. The argument that Michael was going for applies both ways.


Open drivers can be better if the same development resources (or more) are poured into them. That's where it gets complicated.

Workstation customers make purchasing decisions based on proprietary software features and performance, which HW vendors spend a ton of money developing and don't want to give away to their competitors. The existence of open source drivers is not the issue, it's the implicit "and then we'll ban closed source drivers" that would be a problem for workstation customers.

Workstation seems to be an exception to the typical user base, since the "Linux workstation market" is really the old "Unix workstation market", which didn't have a problem with closed source drivers.


I'd like to see some hard facts to back up these claims. How about a double blind test in a cube farm with software developers. Or maybe a farm of say... transcriptionists. Possibly a farm of... telemarketers. Ooohh and... Medical billers...

The only two areas of potential concern is Graphics and Video. Graphics is easy. The fact is that graphics designers should be developing 100% opengl compliant products to begin with, which an open driver will be able to provide wonderfully. The only other issue is video and that has been hashed and rehashed too many times already.


This is easy. Linux workstation customers expect feature and performance parity with Windows, which means either the same development cost for 1/10th the market size or sharing code between the OSes. Practically speaking, that means the Linux workstation drivers are going to share a lot of code with drivers from other OSes, which in turn means that "opening up the drivers" puts your competitive edge at risk in all OSes not just Linux.


I disagree hardily. I disagree about as much as one can disagree. First of all your already putting the efforts needed into an open driver. Once you've dropped the closed driver your costs will go down. Not up. Second of all, the community is already developing an open driver with the documentation that you've already released. All you have to do is support that effort alone. Or you could do as I have previously suggested and re-allocate existing resources. Instead of paying people to develop the closed drivers, pay those same people to teach a new generation how to develop graphics drivers. Instead of wasting time and money on a futile short term effort that will ultimately fail, invest it into the future.


We adopted a two driver strategy because we felt that workstation absolutely needed a closed source solution (because of the market pull for parity with Windows and the competitive challenges that brings) while most other Linux users could be satisfied with an open source stack that had all the important functionality but not the proprietary features or performance work which feeds the workstation market.

Our workstation customers felt that it would be handy to have an open source driver which could be swapped in to confirm that a kernel problem was in no way related to the binary graphics driver, but every one I spoke with (including both ATI and NVidia customers) said that what they cared about was performance and stability on a standard commercial OS distribution (typically RHEL or SLES/SLED), not open-ness or ability to work across arbitrary distros.

The only thing I can say here is that most folks dont actually know what is --best-- for them. Do a double blind study to confirm. The scientific method actually does work.

[Redeeman]

If the performance of the open source AMD drivers will be at least 75%, which is still some great work to do, then I think most people (home users) will use them over the proprietary one in the future as Xv and other important features should be avaible, too. With the AMD open source plan, I would have guessed that nVidia really has to do the same to continue selling cards for the non-Windows market, but it seems that they believe in something different...
and with good reason, its not hard to see that the vast majority of hardware customers dont give a flying rats ass about freedom or stability, they dont give a fuck if their computer crashes once every day, as long as they are able to max out their 1kWh psu and see that extra 1fps on the counter..

[bridgman]

I'd like to see some hard facts to back up these claims. How about a double blind test in a cube farm with software developers. Or maybe a farm of say... transcriptionists. Possibly a farm of... telemarketers. Ooohh and... Medical billers...

I like it. We'll start with telemarketers then work our way up :)

The only two areas of potential concern is Graphics and Video. Graphics is easy. The fact is that graphics designers should be developing 100% opengl compliant products to begin with, which an open driver will be able to provide wonderfully. The only other issue is video and that has been hashed and rehashed too many times already.

Functionality and OpenGL compliance should be no problem for an open driver, I agree.

I disagree heartily. I disagree about as much as one can disagree. First of all your already putting the efforts needed into an open driver. Once you've dropped the closed driver your costs will go down. Not up. Second of all, the community is already developing an open driver with the documentation that you've already released. All you have to do is support that effort alone. Or you could do as I have previously suggested and re-allocate existing resources. Instead of paying people to develop the closed drivers, pay those same people to teach a new generation how to develop graphics drivers. Instead of wasting time and money on a futile short term effort that will ultimately fail, invest it into the future.

But... but... but...

The driver stack is mostly common code shared across multiple OSes. If we shut down the Linux driver effort and free up "all the people who work on that driver" then we shut down our Windows driver effort as well.

If we only re-task the group working on Linux-specific portions of the driver that team is nowhere near large enough to provide the kind of functionality or performance we get from the common code base today. Without that -- buh-bye customers.

[bridgman]

and with good reason, its not hard to see that the vast majority of hardware customers dont give a flying rats ass about freedom or stability, they dont give a fuck if their computer crashes once every day, as long as they are able to max out their 1kWh psu and see that extra 1fps on the counter..

I would probably say it more diplomatically, but yeah. There is a whole continuum of users each with significantly different priorities and a slightly disturbing lack of concern about the priorities of other users :eek:

Speaking of different users, it's probably worth mentioning that binary drivers are actually very stable if you install them on a supported distro then leave them alone. One of the big problems we have all faced is that our supported distros were picked based on workstation usage and those didn't line up with what you folks were using.

[duby229]

If we only re-task the group working on Linux-specific portions of the driver that team is nowhere near large enough to provide the kind of functionality or performance we get from the common code base today. Without that -- buh-bye customers.

I cant disagree more. Basically what your saying is that the common code in your driver runs magically on linux, and the resources needed to make it run on linux is negligible. In effect re-allocating resources would be futile due to the magical nature of your code base.

I just dont buy it. You've clearly got something tied up into it. Better to put that "something" to better use instead of wasting it.

Anyhow, sorry for being a pain. :D I certainly appreciate the work that has already been done, and would like to thank you for being such an active member in the community. I guess i could be classified as a vocal minority. Unfortunately it's the vocal minorities who know what they are talking about, and support many of the medium sized networks in this country.

[bridgman]

Sort of... I'm saying that somewhere between 90% and 95% of the code is OS-independent.

I'm not saying that re-allocating resources would not benefit the open source driver, I'm saying that it would not benefit the open source driver *enough* for us to be able to compete successfully with other vendor's closed source drivers on performance and features. That's a very important difference (isn't it ?).

I agree that vocal minorities are important.

[duby229]

Sort of... I'm saying that somewhere between 90% and 95% of the code is OS-independent.

I'm not saying that re-allocating resources would not benefit the open source driver, I'm saying that it would not benefit the open source driver *enough* for us to be able to compete successfully with other vendor's closed source drivers on performance and features. That's a very important difference (isn't it ?).


I dont think it is no. I think that everything that an open source driver needs, can be made available. Everything else can be dropped completely. You'll save time money and talent by doing so.

The side effect of doing so is that anything that anybody could ever possibly need could be fulfilled at the same time. Nobody needs DRM, despite what the MPAA, and RIAA would have you think.

And then there is the issue of blue sky. Blue sky is just a term meaning extra cool stuff. Can you provide blue sky in an open driver? Thats debatable, but I believe it can.. Blue sky should be implemented in hardware, and controlled by a firmware. Take power management for example. Some degree of power management is required, the minimum for the open driver would be some form of clock scaling. But if you wanted to provide a better system of power management then it should be implemented in hardware and controlled by a firmware.

I think we've all seen the benefit of a similar system, that you've described here called AtomBIOS... A similar system to provide blue sky would be ideal, and would still allow for an entirely open source infrastructure. It would easily satisfy all of your customers who have mistakenly claimed that they need a closed driver, and would also satisfy the vast majority of other users who will need the open driver.

[bridgman]

I dont think it is no. I think that everything that an open source driver needs, can be made available. Everything else can be dropped completely. You'll save time money and talent by doing so.

Just to be clear, are you saying that you feel we could successfully compete in the workstation market even though we would no longer benefit from all the work done on the OS-independent proprietary code, and even though our performance and features would be significantly lower as a result ?

[Kano]

Well I think especially this site hyped the ATI open source drivers a bit too much. Of course those drivers can be used for compiz and games with low performance needs, but for demanding games/apps these drivers are not designed as they are way too slow. I guess thats the common misunderstanding - even when new cards are supported by those drivers a gamer will not be happy with em. Same applies for workstations of course.

[duby229]

Just to be clear, are you saying that you feel we could successfully compete in the workstation market even though we would no longer benefit from all the work done on the OS-independent proprietary code, and even though our performance and features would be significantly lower as a result ?

No, I'm saying that most of what you call "features" is actually bloat and it doesnt really matter anyway. You can provide all the functions needed for the open driver and drop everything else, and it would be adequate for everyone.

If you wanted to provide more advanced "features" in a proprietary sort of way, then they should be implemented in firmware.

OK, lets take my situation as an example. I work for a company that handles a medical management software for it's clients. Most of these are family doctors and dentists.. We deploy the software to several hundred workstations on the network using a linux thin client. I personally would never under any circumstance consider deploying the closed driver on any of these workstations. They all use a fairly simple GTK interface and run on the various open drivers depending on which chip they have.

I'd guess that at least 90% of your linux workstation market share is made up of configurations very similar to my own.

[bridgman]

Ahh, I think we have different uses of the word "workstation" here. For your type of applications I agree open source drivers are fine, and would probably be my preference as well.

When I say "workstation" I'm talking about the FireGL / Quadro business -- big honkin' CPUs, big honkin' graphics, specialized CAD applications, ISV certification requirements, multiple 30" monitors and buyers who carry SpecViewperf around on a USB key ;)

Using firmware for proprietary stuff is problematic because the graphics drivers typically need a *lot* of CPU power when running demanding applications, and adding that kind of general purpose processing power to a GPU raises the cost quite a bit. We have simple processors and firmware on a modern GPU today, but nowhere near enough processing power required to host the drivers on-chip, particularly for features like Crossfire.

That said, this problem gets easier with every process shrink so I'm not saying it can't be done in the future, just that we don't have a way to make it financially viable today.

[duby229]

Ahh, I think we have different uses of the word "workstation" here. For your type of applications I agree open source drivers are fine, and would probably be my preference as well. When I say "workstation" I'm talking about the FireGL / Quadro business -- big honkin' CPUs, big honkin' graphics, specialized CAD applications, ISV certification requirements, and buyers who carry SpecViewperf around on a USB key ;)

For most other applications today the open source drivers should be fine.

Even here your talking about OpenGL. Which the open driver will be 100% compliant.

[ethana2]

I think the people who talk about proprietary firmware are forgetting that many have a moral objection to that too. They want 1.silicon 2.FOSS

Also, I think we're not looking at graphics cards anymore really as one entity, they're another processor-- with some video output stuff and sensors and clocks and whatnot.. and the same applies to the drivers.

We're going to start seeing gallium backends for blender's renderer, mplayer and such, DirectX, you name it.. and proprietary drivers are always slow to take new things like that into account. The problem with proprietary drivers over something like flash is that they form the foundation of your experience with all your other software. They can make WINE crash, they can screw up KDE4's compositor, they can bork goodness knows what else, and it's always the corner cases that get ignored, as if you're not /supposed/ to be using your hardware that way.

I'm always the corner case, see.

And we're seeing all kinds of paradigm convergence where the only coherent way things can happen properly is by being open... by keeping everything open, we keep it flexible, and can continue to make life more awesome for people with hardware long unsupported by the manufacturer.

[Redeeman]

Well I think especially this site hyped the ATI open source drivers a bit too much. Of course those drivers can be used for compiz and games with low performance needs, but for demanding games/apps these drivers are not designed as they are way too slow. I guess thats the common misunderstanding - even when new cards are supported by those drivers a gamer will not be happy with em. Same applies for workstations of course.
what kind of performance are you seeing versus the closed driver?

as i understood it, the open drivers would be like ~80% that of the closed, that to me is perfectly fine.

I realize that these figures are probably not whats being seen today, but isnt that sortof the "plan" so to say?

[Svartalf]

if you know of such an effort, a sort of dedicated warfare against nvidia, please please let me know, ill happily support it

You need to take a chill pill. Seriously. You are more of a hindrance than a help right at the moment with the attitude.

Pick your fights- something you're not doing right now. Honest.

[ethana2]

I'd be happy with anything above 90% performance, but probably not 80%...

[Kano]

@Redeeman

That's a value in your dreams. Because several things are completely missing like GLSL support and glxgears is really no benchmark - that it would be possible to archive a similar thruput for extra simple operations yes, but you must be really lucky to get maybe 25% speed for more demanding things.

[Redeeman]

You need to take a chill pill. Seriously. You are more of a hindrance than a help right at the moment with the attitude.

Pick your fights- something you're not doing right now. Honest.
i guess thats the difference between the two of us, i pick fights that are just and right, you seem to pick fights "you can win"

[Redeeman]

@Redeeman

That's a value in your dreams. Because several things are completely missing like GLSL support and glxgears is really no benchmark - that it would be possible to archive a similar thruput for extra simple operations yes, but you must be really lucky to get maybe 25% speed for more demanding things.

glsl should be coming some time, atleast with gallium.

which things are you saying have only 25% speed?

anyway, that stuff SHOULD become faster with the documentation released, right?

[ethana2]

Will we need GLSL when we have gallium?

[Redeeman]

yes, we will, glsl is what the applications use to do the shaders.. gallium will then read the glsl and transform it into something the hardware can do.

[Svartalf]

i guess thats the difference between the two of us, i pick fights that are just and right, you seem to pick fights "you can win"

You tilt at windmills- what you consider is "just and right" only distorts the message you try to convey and you get NOWHERE fast.

[edit]
You have your heart in the right place- but stridence does you NO favors. You seem to enjoy bringing strife wherever you go and you accomplish little with it.

[bridgman]

glsl should be coming some time, atleast with gallium.

yep; definitely needs a good memory manager first, and by the time we have the memory manager Gallium should be far enough along that it makes sense to do the rest of the work there. The open issue with Gallium is how effectively llvm will be able to pack work into the SP's, but that primarily affects performance not functionality.

EDIT -- it's probably worth mentioning that GLSL doesn't "come for free with Gallium" -- someone has to do a whole heap of work to make it happen. The attractive thing about Gallium is that it seems like a sufficiently useful foundation that there's a good chance that the work will get done.

which things are you saying have only 25% speed?

I realize you weren't asking me but I'll answer anyways ;)

The whole speed thing is hard to put a single number on. I do expect that some things will run as fast on the open driver as on our proprietary driver -- but in other cases there may be a 5:1 difference. We do expect that open source drivers will be fast enough for many users, and some of the rest will simply get a slightly faster graphics card and not worry about performance.

anyway, that stuff SHOULD become faster with the documentation released, right?

We will be providing enough information and support to make open source drivers which run just as fast as the proprietary ones. The question is whether the open source community has the resources to write a driver which takes full advantage of the information even including development resources provided or funded by HW vendors.

[Svartalf]

@Redeeman

That's a value in your dreams. Because several things are completely missing like GLSL support and glxgears is really no benchmark - that it would be possible to archive a similar thruput for extra simple operations yes, but you must be really lucky to get maybe 25% speed for more demanding things.

Once the GLSL is in place with an optimizing compiler the performance will majorly improve. But, that's a bit off yet, I fear- at least another 6-12 months before we start really seeing the results of the work in progress with Gallium3D, etc.

[duby229]

We will be providing enough information and support to make open source drivers which run just as fast as the proprietary ones. The question is whether the open source community has the resources to write a driver which takes full advantage of the information even including development resources provided or funded by HW vendors.

My guess is it'll prolly never be quite as fast as the closed drivers simply due to the vast amount of resources that are devoted to that code base. But I'd be happy with 3/4.

But in the same aspect it also makes sense that the open drivers will improve with each new release. It may never catch up with the closed driver, but by the time a card reaches the end of it's life it should be pretty close.

[bridgman]

Yep. I do agree that most people will be happy with 3/4.

One of the little revelations that made this plan possible was "y'know, GPUs *are* pretty fast these days" :D

[Redeeman]

Once the GLSL is in place with an optimizing compiler the performance will majorly improve. But, that's a bit off yet, I fear- at least another 6-12 months before we start really seeing the results of the work in progress with Gallium3D, etc.
will we really see gallium being put to use in this timeframe? to be honest i would expect it to take longer?

[Chris]

Another issue people don't seem to fully realize with completely GPL'd FOSS drivers is patented (evil word) technology. For example, floating point textures and rendering (more or less a requirement for HDR rendering) is patented by SGI. You must get a patent license to implement it, and unless SGI decides to allow FOSS developers to implement it royalty-free, you'll never see that supported in GPL drivers (GPLv3, at least).

Another is DXT compression, patented by S3. Will also likely require license fees, and will not see the light of day in a GPL(v3)'d driver, unless S3 is feeling rather generous. Not to mention the various NV and ATI-specific extensions, some of which no doubt have patent encumbrances. And of course, there's the whole thing with MS claiming patents on the programable/shader pipeline..

[hubick]

Workstation customers make purchasing decisions based on proprietary software features and performance, which HW vendors spend a ton of money developing and don't want to give away to their competitors.

Workstation seems to be an exception to the typical user base, since the "Linux workstation market" is really the old "Unix workstation market", which didn't have a problem with closed source drivers.

the Linux workstation drivers are going to share a lot of code with drivers from other OSes, which in turn means that "opening up the drivers" puts your competitive edge at risk in all OSes not just Linux.

but every one I spoke with (including both ATI and NVidia customers) said that what they cared about was performance and stability on a standard commercial OS distribution (typically RHEL or SLES/SLED), not open-ness or ability to work across arbitrary distros.

GAH!

It seems that maybe you and/or your customers don't yet "Get It" when it comes to the Free Software model and all the reasons *why* they are using Linux today. Linux and the Free Software model has basically killed off Unix, for good reason, and it's now obvious which model has won out in the market. I think Nvidia, and apparently still AMD, need to realize that they are primarily a hardware company, and thus need to compete with the quality of their hardware, and to STOP looking for a competitive edge in software. Make the software a *shared* commodity so *nobody* has any advantage and you can all work together on it - that's what Linux is all about and you can only fight the model for so long before you either get with the program or someone who does eats your lunch (like maybe Intel) and you head down the same path proprietary Unix did.

[bridgman]

I think you just touched on the real issue -- the fact that there are at least two totally distinct groups using Linux, with totally different reasons for using it.

One group strongly embraces the "Linux is better because it's free and open" thinking, but the other group either feels there is a simpler explanation (the commercial Unix vendors underestimated how quickly PC hardware would progress, dragged their feet on porting to PCs and got their butts kicked out of the market as a result) or simply don't care.

To that second group, the "free and open-ness" of Linux is much less of an issue than the ready availability of a commercially supported "*nix" system for PC hardware, leveraging the work done by Red Hat, Novell and others to use Linux on commercial servers. The Unix platforms which embraced PC market are doing OK (BSD-based MacOS had almost 5% market share last time I checked, and Solaris seems to be showing renewed signs of life) but most of the other Unix vendors missed the boat.

I agree that for the Linux-specific portion of our market we should be embracing open source and that is obviously what we are doing -- I expect that in the not-too-distant future the majority of our consumer Linux users will run the open source drivers -- however there is also a small but important segment of the Linux market (the "second group" above) which expects feature and performance parity with Windows and for *that* market we are continuing to offer a closed-source driver to leverage and protect the significant investment we make in driver code for other platforms.

[duby229]

what Linux is all about and you can only fight the model for so long before you either get with the program or someone who does eats your lunch (like maybe Intel) and you head down the same path proprietary Unix did.

Intel is already eating ATi's lunch... It is Intel that is making just about every major breakthrough in the linux graphics infrastructure. It's Intel that is shaping the future. Not ATi. The way ATi is going right now, the year or so after Intel releases a top end competitor ATi will be done.. It's a shame really, but the only one to blame is ATi.

[Melcar]

^
Funny how a thread about nvidia is turning into a "it's ATI's fault" thread. AMD is trying to please both sides here, and I think they are doing a good job at it. They acknowledge the needs of the OSS community, while still maintaining their commitments to the small (but influential) UNIX crowd that still desires proprietary stuff. This is far more than what nvidia or Intel are doing; nvidia seems to simply not care about Linux proper, and Intel simply does not have the same obligations ATI and nvidia have as far as high power workstation graphics go (until Larrabee pops out that is).

[duby229]

From the article this thread is about.

however, there is a (smaller and largely unspoken) set of people outside of NVIDIA that want the binary curtain to remain. They fear that if NVIDIA provides an open-source alternative, kernel developers may become even more hostile towards binary blobs.

In this theoretical but possible situation, NVIDIA and AMD would continue producing their binary-only drivers while at the same time supporting the alternative open-source drivers that are focused on the "out of the box" experience and not the high-performance full-featured driver that would remain closed-source. With there being open-source alternatives for all major graphics hardware, free software zealots could make the decision (or several decisions over time) that would block critical elements of the kernel that are necessary for the binary drivers to work. If the kernel developers do this and there ends up being no revert of action, they have just severely stabbed Linux.

This would likely result in a fork, legal action, or other challenges in order to overturn such a decision to reach a new common ground. If no common ground was reached, NVIDIA and AMD would be put in an awkward position of not being able to support their workstation customers with the high-performance drivers they need as they can't have some of their third-party intellectual property and other work exposed in an open-source driver. If it were really severe, the workstation business could just pack up and move to another operating system. That's what some fear at least.

I've taken the liberty of bolding what I have issues with, and underlining what pertains to AMD (aka ATi)

I just wanted to make it perfectly clear that this snippet from the front page article this thread references, is what I am talking about. Micheal references both nVidia and ATi, and while nVidia may be more guilty then ATi at this poitn they are both guilty. I'll give AMD some credit that at least they are trying. Nvidia isant even trying. And lets face the facts here, when (not if) binary blobs are denied access to the kernel the only company that will be prepared for it is Intel. If ATi continues down the path that they chose it is doomed to fail. And the only one at fault is themselves. The way I see it is when Intel releases a top end competitor nVidia is doomed. ATi still has a chance if the open driver is mature enough to take on the full load of supporting the Linux community. If not then ATi is doomed as well.

[hubick]

however there is also a small but important segment of the Linux market (the "second group" above) which expects feature and performance parity with Windows and for *that* market we are continuing to offer a closed-source driver to leverage and protect the significant investment we make in driver code for other platforms

Sure, but what happens when a competitor comes along who gives consumers _both_ an integrated open source solution *and* high performance? You just don't think it can happen? Or think you are capable of reacting quickly enough if/when it does?

[ethana2]

I'd just like to say, and this may not be particularly /informative/, but you folks at AMD and intel are doing an awesome job, and I would feel no qualms at all about buying the newest most powerful gpu you offer. Keep up the great work. We love you guys, you rock.

I'm of the opinion that hardware vendors -only- obligation for data provision to customers is hardware specs.

Providing drivers for our OS /and/ helping code free ones is just amazing. Think about it. That's a lot of stuff for free. AMD is going above and beyond the call of duty as I'm concerned, and I really appreciate that.

[remm]

We adopted a two driver strategy because we felt that workstation absolutely needed a closed source solution (because of the market pull for parity with Windows and the competitive challenges that brings) while most other Linux users could be satisfied with an open source stack that had all the important functionality but not the proprietary features or performance work which feeds the workstation market.

The reason they "need" a closed driver is first of all that, when they buy their (new) hardware, there's no 3D available at all with the OSS driver. Before making claims that performance is king (which is fine by me, but you'd also have to demonstrate that an OSS driver cannot have good performance), I'd like to point out that, as of now the ATI OSS drivers have: very early 3D for R500, no 3D for R600, and nothing for R700. How could a user possibly choose to use the open source driver exactly ?

[mrintegrity]

Phoronix: NVIDIA Denies Opening Up Its Driver
This would likely result in a fork, legal action, or other challenges in order to overturn such a decision to reach a new common ground. If no common ground was reached, NVIDIA and AMD would be put in an awkward position of not being able to support their workstation customers with the high-performance drivers they need as they can't have some of their third-party intellectual property and other work exposed in an open-source driver. If it were really severe, the workstation business could just pack up and move to another operating system. That's what some fear at least...

http://www.phoronix.com/vr.php?view=NjU0NQ

Bit of a rant that eh? Exactly what evidence do you have that such doom scenarios might occur? Please provide more information about who you are referring to when you say "That's what some fear at least..."... is that just like a dream you had or something?

Alan

[dickeywang]

Nvidia is putting a lot of hope on its CUDA library and has spent a lot of money to convincing people in the parallel computing community to look at the possibility of doing high performance computing on their GPUs, so I doubt Nvidia would open their driver source until it has established a dominance in that field.

[curaga]

Since we are talking about AMD and Intel here too, do you think Intel will go blob with Larrabee, to archieve the higher performance/DRM?

[bridgman]

And lets face the facts here, when (not if) binary blobs are denied access to the kernel the only company that will be prepared for it is Intel. If ATi continues down the path that they chose it is doomed to fail. And the only one at fault is themselves. The way I see it is when Intel releases a top end competitor nVidia is doomed. ATi still has a chance if the open driver is mature enough to take on the full load of supporting the Linux community. If not then ATi is doomed as well.

I'm still not getting your point. All the open source drivers use the same framework, and they will all make progress at approximately the same rate. We need to stay focused on 6xx 3d support for another month or two, but after that we'll just be another part of the community helping to push things along where we can.

[bridgman]

Bit of a rant that eh? Exactly what evidence do you have that such doom scenarios might occur? Please provide more information about who you are referring to when you say "That's what some fear at least..."... is that just like a dream you had or something?

Not a question of fear, more like predictable cause-and-effect. If binary drivers are blocked before open source drivers are ready to provide comparable performance and features that is going to cause problems for at least one significant portion of the Linux user base. Those companies are using Linux because it works for them, and if serious obstacles are raised I would expect them to move to another platform. Could be Windows, could be a Unix-based OS, or (as Michael hinted) the distros could potentially back out the changes in order to retain their customer base.

You're probably asking "why do I care ?".

A non-trivial part of the development activity in Linux is funded by companies who make a living providing software and services to high end commercial users (Red Hat and Novell being the most obvious ones). I believe server sales are still the biggest contributor but workstation revenues are not that far behind. At some point the distros (who employ many of the developers on the list) will start to feel the pinch...

...and *that*s when the really interesting discussions will start to happen.

[Melcar]

Since we are talking about AMD and Intel here too, do you think Intel will go blob with Larrabee, to archieve the higher performance/DRM?


It wouldn't surprise me if they did.

[Kano]

Intel already added a loader for a binary part to the driver, maybe then they will use it.

[Tsiolkovsky]

here's an interesting blog post from a KDE developer's point of view: How NVIDIA Impedes Free Desktop Adoption (http://vizzzion.org/?blogentry=819). Looks like bad closed source NVIDIA drivers cause a lot of problems for KDE 4.

[Chris]

How NVIDIA Impedes Free Desktop Adoption.
I think that post is a bit one sided. Sure, nVidia's drivers have problems, but what driver (open or closed) doesn't? It's not like open source drivers are more stable.

But it makes me wonder.. how would free desktop adoption be with only open source drivers? Well, for one, we could kiss next (http://opengl.org/registry/specs/EXT/texture_compression_s3tc.txt) gen (http://opengl.org/registry/specs/ARB/fragment_program.txt) gaming (http://opengl.org/registry/specs/ARB/color_buffer_float.txt) goodbye..

[duby229]

I'm still not getting your point. All the open source drivers use the same framework, and they will all make progress at approximately the same rate. We need to stay focused on 6xx 3d support for another month or two, but after that we'll just be another part of the community helping to push things along where we can.

That is exactly my point. Being another part of the community should be your sole priority. It should consume 100% of your focus. Permanently, from this day forward. It should be the only concern that you have.

[duby229]

I think that post is a bit one sided. Sure, nVidia's drivers have problems, but what driver (open or closed) doesn't? It's not like open source drivers are more stable.

But it makes me wonder.. how would free desktop adoption be with only open source drivers? Well, for one, we could kiss next (http://opengl.org/registry/specs/EXT/texture_compression_s3tc.txt) gen (http://opengl.org/registry/specs/ARB/fragment_program.txt) gaming (http://opengl.org/registry/specs/ARB/color_buffer_float.txt) goodbye..

Which is the point and is 100% nVidia's fault for not supporting an open driver. Dont blame open source software, put the blame squarely where it belongs at nVidia. If nVidia wants there hardware to work once binaries are locked out then --they-- need to get on the ball. It's there hardware, and if they want to contibue selling it, then they better do something right now while they still can...

Like I already said, nVidia has no real future. ATi has potential, but they'll always be "number 2" as long as they go down the path they have chosen. Take a look at just about every major innovation being made today, and you'll see that it is being either developed by, or implemented first in Intel's open drivers. Not ATi's binary blob, or ATi's open drivers, or nVidia's binary blob.

It is Intel that is shaping the future and the reason they are shaping the future is there commitment to open source.

[Redeeman]

Intel already added a loader for a binary part to the driver, maybe then they will use it.

didnt they remove that?

also, dont you think larabee will need an entirely new driver?

[Chris]

Which is the point and is 100% nVidia's fault for not supporting an open driver. Dont blame open source software, put the blame squarely where it belongs at nVidia. If nVidia wants there hardware to work once binaries are locked out then --they-- need to get on the ball. It's there hardware, and if they want to contibue selling it, then they better do something right now while they still can...
I have no idea what you're talking about. It's not nVidia's fault that other companies hold patents on technologies next-gen gaming relies on (S3 for texture compression, SGI for floating point/HDR rendering, MS supposedly for programmable shaders). These are things open drivers cannot have if they want to be patent free (with the exception of the MS thing, given how we know MS likes to throw FUD around). If open drivers became the norm, these are the kinds of features we lose. That is in no way nVidia's fault. And I wouldn't hold your breath for a binary driver lock-out. Several patches have been proposed for the Linux kernel already to block loading any non-GPL driver.. they've all been rejected.

Take a look at just about every major innovation being made today, and you'll see that it is being either developed by, or implemented first in Intel's open drivers. Not ATi's binary blob, or ATi's open drivers, or nVidia's binary blob.
Like geometry shaders, sRGB rendering, and HDR rendering? Can't forget about CUDA and whatever AMD offers..

[duby229]

I have no idea what you're talking about. It's not nVidia's fault that other companies hold patents on technologies next-gen gaming relies on (S3 for texture compression, SGI for floating point/HDR rendering, MS supposedly for programmable shaders). These are things open drivers cannot have if they want to be patent free (with the exception of the MS thing, given how we know MS likes to throw FUD around). If open drivers became the norm, these are the kinds of features we lose. That is in no way nVidia's fault. And I wouldn't hold your breath for a binary driver lock-out. Several patches have been proposed for the Linux kernel already to block loading any non-GPL driver.. they've all been rejected.

Like geometry shaders, sRGB rendering, and HDR rendering? Can't forget about CUDA and whatever AMD offers..

100% opengl compliance. That is the requisite. Nothing more and nothing less. We dont need more bloat. MS or anybody else can patent whatever they want. The sole objective should be nothing less then 100% opengl compatibility. If AMD, nVidia, SGI, Intel, IBM, and every other major player in the graphics market got together and standardized development efforts we'd be 10 years ahead of where we are today. Instead we have an opengl specification that is outdated and in severe need of modernization.

nVidia aint doint it. AMD aint doing it. Intel is. And they are doing it completely using open drivers.

Heres the bottom line, Binary blobs --will-- be locked out of the kernel sooner or later. At this point it is inevitable. The only company who is prepared for that is Intel. Your customers arent going to leave Linux, not with how heavily invested companies like the one I work for are, but they will leave you and move to Intel. Linux market isnt going anywhere, but your share in that market will.

[Chris]

100% opengl compliance. That is the requisite. Nothing more and nothing less. We dont need more bloat. MS or anybody else can patent whatever they want. The sole objective should be nothing less then 100% opengl compatibility.
Owing to bugs, I've never had an issue with nVidia's OpenGL implementation. Their hardware is more than capable, unlike Intel's.

Binary blobs --will-- be locked out of the kernel sooner or later. At this point it is inevitable.
Says who?

[deanjo]

Says who?

Not Linus. He already said he won't have any part of that.

[bridgman]

This is where the fun starts. Linus has refused to push those changes into the tree himself, and he is violently opposed to having developers dictate how Linux will be used, but as long as someone else (eg a major distro) picks up the changes first he is not blocking them. That was the last I saw anyways.

[Svartalf]

This is where the fun starts. Linus has refused to push those changes into the tree himself, and he is violently opposed to having developers dictate how Linux will be used, but as long as someone else (eg a major distro) picks up the changes first he is not blocking them. That was the last I saw anyways.

The biggest question then will be: "Who will be the distro that does it and ends up on the short end of the stick?"

That's one of those things that can mar your rep, much like the Novell-Microsoft deal has done to Novell's rep.

[ickusslime]

Binary blobs --will-- be locked out of the kernel sooner or later.

That is the problem. You will kill the goose that lays the golden egg. Most people don't have a problem with proprietary drivers as long as they work and work reliably.

As soon as "they" lock out modules from the kernel the software isn't free as in freedom anymore. Someone else is dictating how I can use the software; end of story. At that point it becomes a fiefdom no better than the people they are "fighting", despite what Stalin... I mean Stallman says.

I don't understand the F/OSS community anymore. They are just as bad as the proprietary companies. There is no middle ground anymore. It's all me me me...
If you start complaining about not being able to use the hardware that you "paid" for then you didn't research the hardware you bought or even read the box. I don't buy Brillo pads and then complain they scratch my bath tub when i clean the tub with them.

[Jimmy]

Not Linus. He already said he won't have any part of that.

Good on him for being grounded in the REAL world and not the IDEAL world.

Sure, it would be nice if all software everywhere were free and open. However that's not the world we live in. The idealist zealots would have me and everyone else chuck anything that isn't 100% FLOSS and blessed by RMS as holy and pure. They're looking for ways to restrict me from running software of my choosing. Because it's FLOSS that's ok.. but if Microsoft wants to restrict me to only running software which requires Microsoft software... that's EVIL OMFG MAKE IT STOP.

This notion that I should be able to run ONLY FLOSS software is a divisive waste of time. If you want people to use FOSS software, make FOSS software better. Don't try to cock block other software that works better. Compete with quality and feature completeness or you are no better than Microsoft. Competing by making sure no other software runs is one of the things Microsoft has done to piss FLOSS folks off so much. Yet that's what they want to do now ?

[Jimmy]

We'll force them to be free.

[Redeeman]

That is the problem. You will kill the goose that lays the golden egg. Most people don't have a problem with proprietary drivers as long as they work and work reliably.

As soon as "they" lock out modules from the kernel the software isn't free as in freedom anymore. Someone else is dictating how I can use the software; end of story. At that point it becomes a fiefdom no better than the people they are "fighting", despite what Stalin... I mean Stallman says.

I don't understand the F/OSS community anymore. They are just as bad as the proprietary companies. There is no middle ground anymore. It's all me me me...
If you start complaining about not being able to use the hardware that you "paid" for then you didn't research the hardware you bought or even read the box. I don't buy Brillo pads and then complain they scratch my bath tub when i clean the tub with them.
patches to stop non-gpl modules from loading is no more "dictating how i can use the software" than some software not having a specific menu entry, despite having the feature..

stop with the useless and extremely bad comparisins, even if the linux kernel blocked the loading of non-gpl modules, you could still load them, you'd just have to excercise you FREEDDOM to do it.

just as gnome isnt removing your freedom when they remove all the features, they merely change their application, you are free to do as you please..

[duby229]

Owing to bugs, I've never had an issue with nVidia's OpenGL implementation. Their hardware is more than capable, unlike Intel's.


Says who?

nVidia's implementation works well enough, it has a few minor bugs, but it works pretty good. Much better then ATi's at this point., but that is besides the point. The point was that anybodies implementation will be adequate as long as it is 100% opengl compatible. That includes open source implementations.

And the vast majority of Linux users.....

[bridgman]

If an end user has to patch and rebuild the kernel in order to run something that is going to have a big impact on commercial users. The real question here is whether the major distros are going to support these changes or not.

This is where the threads always get really philosophical and rathole on the essential difference between "not making something easy to do" and "making something hard to do" :D

[Redeeman]

nVidia's implementation works well enough, it has a few minor bugs, but it works pretty good. Much better then ATi's at this point., but that is besides the point. The point was that anybodies implementation will be adequate as long as it is 100% opengl compatible. That includes open source implementations.

And the vast majority of Linux users.....
you dont seem to get that there is a vast amount of issues with the nvidia binary driver..

as posted in another thread, you might wanna read:
http://vizzzion.org/?blogentry=819
https://www.linuxfoundation.org/en/Linux_Graphics_Essay

[duby229]

That is the problem. You will kill the goose that lays the golden egg. Most people don't have a problem with proprietary drivers as long as they work and work reliably.

As soon as "they" lock out modules from the kernel the software isn't free as in freedom anymore. Someone else is dictating how I can use the software; end of story. At that point it becomes a fiefdom no better than the people they are "fighting", despite what Stalin... I mean Stallman says.

I don't understand the F/OSS community anymore. They are just as bad as the proprietary companies. There is no middle ground anymore. It's all me me me...
If you start complaining about not being able to use the hardware that you "paid" for then you didn't research the hardware you bought or even read the box. I don't buy Brillo pads and then complain they scratch my bath tub when i clean the tub with them.

That's not fair. Most people dont know the difference between a disc brake and a drum brake either... But what a car manufacturer has the responsibility of doing is choosing the brake that is going to be safest and most practical for the end user.

In every single possible way Open source drivers are the safest and most practical implementation. The sole requirement is 100% opengl compliance. An open driver is fully capable of providing exactly that.

Blue sky is what ATi, nVidia, and Intel have to worry about.

[duby229]

If an end user has to patch and rebuild the kernel in order to run something that is going to have a big impact on commercial users. The real question here is whether the major distros are going to support these changes or not.

This is where the threads always get really philosophical and rathole on the essential difference between "not making something easy to do" and "making something hard to do" :D

Modern Package management. Every single package manager that I know of in common use today support rolling updates, and security updates on the fly. There is nothing philosophical about it. An update gets released and the distribution tests it and pushes it out to the repositories. The end user gets a pop up in the tray icon telling them that an update is ready for his computer. He clicks ok and 20 seconds later he is done.

edit: which by the way is something that binary drivers make extremely difficult to do. With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not, and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version. Which can often takes weeks or even months, and in ATi's case even quarters..

Compatibility, upgradeability, and stability are all much much much better on an open driver.

[bridgman]

That's not fair. Most people dont know the difference between a disc brake and a drum brake either... But what a car manufacturer has the responsibility of doing is choosing the brake that is going to be safest and most practical for the end user.

Probably a better analogy would be restricting the car to only run on paved roads unless you crawl underneath each vehicle and rip out some wires.

Modern Package management. Every single package manager that I know of in common use today support rolling updates, and security updates on the fly. There is nothing philosophical about it. An update gets released and the distribution tests it and pushes it out to the repositories. The end user gets a pop up in the tray icon telling them that an update is ready for his computer. He clicks ok and 20 seconds later he is done.

Sorry, I was trying to make a different point. If the kernel devs stick these changes in and the distros decide to rip them out again everything is simple. I don't know what is going to happen there. There's a good chance the distros will pass the changes through rather than do battle with the kernel devs.

With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not, and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version.

Surely the same problem happens when a user is running an open source driver with their new card, requiring a bleeding-edge drm in the kernel. When you upgrade the kernel and pick up an older drm driver in the process the user is equally broken until they reinstall the driver.

A real solution would be to work with the HW vendors to ensure that appropriate proprietary kernel drivers were included and tested before each new kernel was distributed. I do agree that there would be some expectations re: making the kernel drivers smaller and less likely to "oops" -- again, that would be good for everyone.

Now *that* would be doing something good for the users :D

[Redeeman]

Surely the same problem happens when a user is running an open source driver with their new card, requiring a bleeding-edge drm in the kernel. When you upgrade the kernel and pick up an older drm driver in the process the user is equally broken until they reinstall the driver.

but that is only for non-released drivers, so you cant really compare that.

[Chris]

With a binary driver every time the kernel gets updated you have to re-install the binary blob, whether it is the same version or not
I had to reinstall an open source driver for my webcam when I updated my kernel. Being binary has nothing to do with that, it's solely because it wasn't part of the kernel sources.

and in many cases updating the kernel will break the binary blob due to it not supporting that newer kernel version.
Same thing happened to the aforementioned open source driver. Sure I could go in to try to fix it, but do you know what it's like to look at a kernel module source when you have no experience working in the kernel? :P In the end, I had to wait for the developers to update it.. just as if it was a binary blob.

[duby229]

Probably a better analogy would be restricting the car to only run on paved roads unless you crawl underneath each vehicle and rip out some wires.


Absolutely not. That's just a cop out.


Sorry, I was trying to make a different point. If the kernel devs stick these changes in and the distros decide to rip them out again everything is simple. I don't know what is going to happen there. There's a good chance the distros will pass the changes through rather than do battle with the kernel devs.

Surely the same problem happens when a user is running an open source driver with their new card, requiring a bleeding-edge drm in the kernel. When you upgrade the kernel and pick up an older drm driver in the process the user is equally broken until they reinstall the driver.


Not once the driver makes it into the kernel tree. That is the point and purpose. If your going to develop an open source kernel driver, the point and purpose of doing so must be to get it into the kernel tree as soon as possible. Without that end goal in mind there is no point in doing so.


A real solution would be to work with the HW vendors to ensure that appropriate proprietary kernel drivers were included and tested before each new kernel was distributed. I do agree that there would be some expectations re: making the kernel drivers smaller and less likely to "oops" -- again, that would be good for everyone.

Now *that* would be doing something good for the users :D

Backwards. A real solution would be for the hardware vendors to work with the community to develop an open driver so there hardware will work properly. It's your hardware after all, and Linux is here to stay with or without you.. ATi is doing this to a limited, but somewhat succesfull extent, but only in a half assed "If I must" attitude. nVidia isnt doing it at all, and Intel is doing it perfectly. And as would be expected Intel has the best drivers, followed by ATi, with nVidia at the end.

In the end I'm glad that ATi is doing what it is already doing. I'm happy with the progress being made, but it is too slow. ATi has literally the best graphics hardware on the planet. They've got the talent that is certain, but I still think that ATI can do better on the open source drivetrs.

[bridgman]

I'm curious... other than GLSL (which is just a matter of time) and the fact that Intel started sooner and therefore have drivers in most distros today, in what way do you feel Intel's currently shipping open source drivers are better than, say, radeon/drm/mesa running on a 5xx ? We all use the same infrastructure, and perhaps 1% of the code is different between Intel and AMD hardware.

Writing releasable programming documentation for the 6xx has been a huge task, larger than even I expected, but that is nearly done now, and at that point the same functionality on 6xx and beyond should come quite quickly.

[Redeeman]

i havent really tried the r500 free stuff yet (im hoping to recieve the X1650 i oredered today/tomorow (its 05:35 here now)), but glsl is quite important.

but what i "feel" (and yes, it is feel at this point, nothing factual), the intel commitment at this time seems to be a more solid thing, the drivers are proven, you KNOW that when you buy intel it WILL work.

with r500 one still have to get the dev stuff, and it really isnt "garantueed" (i know, intel isnt garantueed to work either, but it is strongly expected to) to work.

i realize that this says nothing of amd's commitment, as the this is just a matter of time.

But if you ask what i feel, i would have to say that i think its very likely that for now, intels drivers are more stable than the r500 stuff in development. I base this on absolutely nothing, except that it makes sense, as intels drivers are in production and used by thousands of people, whereas the r500 stuff is residing in git used by tens of people :)

i am nevertheless EXTREMELY eager to try out the r500 stuff, and i really do hope its every bit as good as i imagine :D

[Alex W. Jackson]

I'm curious... other than GLSL (which is just a matter of time) and the fact that Intel started sooner and therefore have drivers in most distros today, in what way do you feel Intel's currently shipping open source drivers are better than, say, radeon/drm/mesa running on a 5xx ? We all use the same infrastructure, and perhaps 1% of the code is different between Intel and AMD hardware.

I think it's mainly the fact that R5xx is now three generations behind the times (at least in terms of retail numbering, i.e. HD4xx0->HD3xx0->HD2xx0->X1xx0) whereas Intel's open source driver has full 3D support for their very latest hardware.

Another part of it is that some popular distributions don't seem to bother to ensure an optimal or even a working default configuration for open-source ATI drivers (e.g. not keeping DDX/DRM/DRI reasonably up to date in their update repositories, or not even keeping them in sync with each other) since the distro maker assumes that everyone with an ATI card is just going to install the binary driver immediately.

[Redeeman]

that will almost certainly change soon though..

[Svartalf]

This is where the threads always get really philosophical and rathole on the essential difference between "not making something easy to do" and "making something hard to do" :D

Ain't that the truth? :D You should see the "fun" over in the Gaming section stuff if you've not gone and done it. I've had a "fun" week this week- and it's not close to over yet... </sigh>

[duby229]

I'm curious... other than GLSL (which is just a matter of time) and the fact that Intel started sooner and therefore have drivers in most distros today, in what way do you feel Intel's currently shipping open source drivers are better than, say, radeon/drm/mesa running on a 5xx ? We all use the same infrastructure, and perhaps 1% of the code is different between Intel and AMD hardware.

Writing releasable programming documentation for the 6xx has been a huge task, larger than even I expected, but that is nearly done now, and at that point the same functionality on 6xx and beyond should come quite quickly.

Great questions. All of them. Code maturity is one thing. I can get acceleration on any Intel card using well tested, solid drivers that have already been in the mainline kernel for a long time already. I don't have to worry about manually installing from a git repository, or about which versions of what will work with this or that. I know that the packages that are marked stable in the package manager are simply going to work with no fuss. I know that when I update the kernel I don't have to worry about breaking the graphics driver because it is already built in. I know that when kernel mode setting goes mainline Intel will be the first with working drivers. Across the board. I know that when Gallium3D goes mainline Intel will be the first with working drivers. Again across the board.

The list just goes on and on and on. The point is that right now Intel's open source drivers are better then everything that ATi has right now combined and then a whole hell of a lot more, for as far into the future as my mind can reach..

The question in my mind is "How long till Intel releases a top end competitor?" and "Then what will ATi do?"

[legume]

I think that post is a bit one sided. Sure, nVidia's drivers have problems, but what driver (open or closed) doesn't? It's not like open source drivers are more stable.

But it makes me wonder.. how would free desktop adoption be with only open source drivers? Well, for one, we could kiss next (http://opengl.org/registry/specs/EXT/texture_compression_s3tc.txt) gen (http://opengl.org/registry/specs/ARB/fragment_program.txt) gaming (http://opengl.org/registry/specs/ARB/color_buffer_float.txt) goodbye..

You can use s3tc now - it's not in mesa but you just download and install a lib.

I guess the same workaround could happen for the the others.

[Chris]

You can use s3tc now - it's not in mesa but you just download and install a lib.

I guess the same workaround could happen for the the others.
Being able to use S3TC, and being able to use the textures *properly*, are two different things. The advantage of S3TC is that they take up about 1/4th less space on the card than the uncompressed counterparts and are decompressed on-the-fly, allowing more/larger textures to be used and used faster (since less data needs to be read). If you have to decompress them on load, you gain nothing.

[legume]

Being able to use S3TC, and being able to use the textures *properly*, are two different things. The advantage of S3TC is that they take up about 1/4th less space on the card than the uncompressed counterparts and are decompressed on-the-fly, allowing more/larger textures to be used and used faster (since less data needs to be read). If you have to decompress them on load, you gain nothing.

Well I read the links as meaning it does use h/w - but I may misunderstand.

http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html

http://dri.freedesktop.org/wiki/S3TC

[Svartalf]

Being able to use S3TC, and being able to use the textures *properly*, are two different things. The advantage of S3TC is that they take up about 1/4th less space on the card than the uncompressed counterparts and are decompressed on-the-fly, allowing more/larger textures to be used and used faster (since less data needs to be read). If you have to decompress them on load, you gain nothing.

Internally, S3TC is used whether or not you have the code that touches on the patent- if the textures were already formatted that way. It does no good to have it reside in the driver to decompress (which is where the use on the card would entail...) and put it to another, uncompressed buffer for the texture in question. The problem in "enabling" it is that for you to be completely correct, you need to be able to GENERATE the compressed textures from uncompressed ones- which is wherein lies the problem with the drivers. If you have pre-generated textures in S3TC, you can DO S3TC with the stuff we have in hand right now- patent's covered, they had to buy the rights to do the hardware decode. It's the on-the-fly generation part that's the gotcha.