Is ATI really on par with NVIDIA now?

[Vighy]

i wonder about licensing issues here. linking a binary driver against gpl2 kernel is already pretty hairy issue and people still haven't decided whether it violates the licence or not. kernel modesetting proprietary driver might be legally difficult.

Bridgman could put some light on it

[bridgman]

Yeah right, the one topic that gets more flames than Digital Rights Management

I don't believe any of us link a binary driver against the Linux kernel API directly. We all ship open source code which implements an OS-neutral API, however we do not claim to be GPL.

That said, there are strongly held *idealogical* issues which are still being debated in the kernel developer community, and those idealogical positions are sometimes presented as legal issues. The two main positions are :

** Position 1 - "we should allow users to run binary drivers but" :

- educate them about potential problems (difficulty debugging kernel issues and keeping up with kernel changes)
- encourage them to support the development and use of open source drivers

** Position 2 - "we should prevent users from running binary drivers for their own protection, and to force the development of open source drivers"

The main debate is about wireless drivers right now, but that frequently spills over into graphics drivers as well. We obviously belong to the "position 1" camp -- we actively support the development of open source drivers, we encourage the use of open source drivers, but we feel that users should be allowed to use closed-source drivers where they make sense.

That said, I do understand the kernel developer's frustration -- there are a number of cases where good open source drivers exist but nobody even tries to use them as long as a binary driver is available. The question is whether we can find a way to encourage the development and use of open source drivers without forcing users to patch their kernels in order to run a binary driver.

Kernel modesetting seems easy by comparison

The main issue with kernel modesetting is the lack of an accepted API which can be used not only by the X driver but by other kernel functions. Moving modesetting to the kernel doesn't really help much if only the X driver is using it.

That API is being defined now -- you can follow the discussion live on #dri-devel as it happens. Right now, in fact.

http://people.freedesktop.org/~cbril...ate=2008-07-03

[oblivious_maximus]

What I don't get is why AMD can't just see to it that the open drivers are what "make sense" to use. The only reason I can think of that some people might feel that the closed binary is a choice which makes sense is the fact that AMD seems to be unwilling to aid future development of the open alternatives past the point of the basic foundation of functionality, and insists on positioning the closed the driver as the only option for users who want to actually get the use of the full range of their hardware's capabilities (I'm not talking about DRM/AACS/HDCP-type stuff)

It seems sometimes reading AMD statements about this subject that AMD doesn't quite realize Linux(/Unix) is not Windows. Obviously it's not that simple, as AMD clearly realizes a different approach is needed. If only it could see the value in actually embracing that different approach fully. If it wants to be the big name in Linux graphics hardware, AMD should really look towards moving all their Linux people onto develpment of Xorg and Mesa, the open drivers themselves (obviously), and whatever other projects are necessary to accomplish that end. The fact that the Windows driver works great and the Linux variant does not even come close to doing the same is the best argument IMHO that the current modus operandi with fglrx is just not working. What good is a unified multiplatform codebase if it's only worth using on one platform?

When in Rome, AMD?

---
And to add my $0.02 re: the original question, my experience the last 4 months with hd3xx0 hardware tells me ATI is nowhere near on par with nVidia, at least blob-vs-blob anyway. I'm not happy about saying that, as AMD is getting it so right on the one hand, but they're getting it so wrong on the other.

[bridgman]

What I don't get is why AMD can't just see to it that the open drivers are what "make sense" to use. The only reason I can think of that some people might feel that the closed binary is a choice which makes sense is the fact that AMD seems to be unwilling to aid future development of the open alternatives past the point of the basic foundation of functionality, and insists on positioning the closed the driver as the only option for users who want to actually get the use of the full range of their hardware's capabilities (I'm not talking about DRM/AACS/HDCP-type stuff.

When in Rome I visit pizza places, but that probably wasn't what you meant

The point here is that a significant amount of our R&D investment is in software. The closed source drivers provide a way to make the results of that investment available to users without exposing the IP. The "conventional wisdom" is that all the IP is in hardware but that just is not the case. We are providing enough information to write fully functional and fully performant open source drivers, ie the only thing we are holding back is our driver source itself.

It is entirely possible that in a year or two the open source infrastructure may have advanced to the point where a closed source driver is not required, but that is not the case today.

[Vighy]

When in Rome I visit pizza places, but that probably wasn't what you meant

I didn't know you liked our food! Are you going to have a speech in Italy in the future? would be nice to come to listen to you

It is entirely possible that in a year or two the open source infrastructure may have advanced to the point where a closed source driver is not required, but that is not the case today.

So you mean that if open source driver was as good as the intel is (for their platform, obviously ), you (ATi) wouldn't work on fglrx.

But what about UVD? I think we will always need (on r600 chips) fglrx to take advantage of all the features of our grpahics.
Maybe r700 it will be more Open Source friendly... but r600 seem to be tied to fglrx.

ain't it right?

[bridgman]

If the open source driver was as good as the NVidia binary we wouldn't work on fglrx. Again, this would be for our platform not NVidia's

re: UVD, we would either need to have determined that we could safely open r6xx UVD, or we would need enough DRM-related infrastructure in Linux that we could implement a secure solution in an open driver, or we would need agreement from enough of the Linux user community that UVD support for 6xx was not required -- which might actually happen once IDCT/MC support is in users hands.

[oblivious_maximus]

When in Rome I visit pizza places, but that probably wasn't what you meant

You're correct, that is not what I meant. I'm sure you realize though what I was suggesting - if AMD wants to embrace Linux and Free software, it should do so to the fullest extent, not with the left-foot-in, right-foot-out approach currently employed.

The point here is that a significant amount of our R&D investment is in software. The closed source drivers provide a way to make the results of that investment available to users...

My only problem with that is that AMD isn't making the results of that investment available to Linux users in anything remotely resembling the level at which you make it availabe to Windows users. fglrx doesn't even fully support X's feature set(not to mention that of the ATI hardware itself), instead we are saddled with the limitations of Microsoft's platform(multiple Xservers not supported? seriously?) And stability? I saw absolutely nothing resembling it in my 4 months trying to use ATI hardware. What I'm trying to say is your investment is not paying off at all the way you seem to think it is, certainly in this user's brief experience. AMD got my money, an HD3650 and an HD3870's worth*. I got a small pile of perfectly good hardware which I couldn't use thanks to fglrx. And that is extremely frustrating.

The "conventional wisdom" is that all the IP is in hardware but that just is not the case. We are providing enough information to write fully functional and fully performant open source drivers, ie the only thing we are holding back is our driver source itself.

You're holding back developers while you cling so tightly to the closed driver.

It is entirely possible that in a year or two the open source infrastructure may have advanced to the point where a closed source driver is not required, but that is not the case today.
---
If the open source driver was as good as the NVidia binary we wouldn't work on fglrx.

But AMD keeps saying(/intimating) that fglrx is going to remain the only choice that "makes sense". Why not start working towards making the open driver(s) as good as the nVidia binary? Why wait for the day when "the open source infrastructure may have advanced to the point where a closed source driver is not required"? Shouldn't the goal be to get the open source drivers to that point? Surely AMD has something to offer beyond specs and goodwill that isn't unreleasable 3rd-party code? Or does the fact that your devs have seen the 3rd party code preclude them entirely from participation?


*not to mention the second 770 motherboard I bought after frying the bios of my first one in hopes of getting fglrx to function. or the 790FX board I bought hoping for the same result. or the 2 X2 CPUs with broken temperature sensors(but those are largely OT except for the AMD-derived-frustration factor).

[deanjo]

You're correct, that is not what I meant. I'm sure you realize though what I was suggesting - if AMD wants to embrace Linux and Free software, it should do so to the fullest extent, not with the left-foot-in, right-foot-out approach currently employed.

My only problem with that is that AMD isn't making the results of that investment available to Linux users in anything remotely resembling the level at which you make it availabe to Windows users. fglrx doesn't even fully support X's feature set(not to mention that of the ATI hardware itself), instead we are saddled with the limitations of Microsoft's platform(multiple Xservers not supported? seriously?) And stability? I saw absolutely nothing resembling it in my 4 months trying to use ATI hardware. What I'm trying to say is your investment is not paying off at all the way you seem to think it is, certainly in this user's brief experience. AMD got my money, an HD3650 and an HD3870's worth*. I got a small pile of perfectly good hardware which I couldn't use thanks to fglrx. And that is extremely frustrating.

You're holding back developers while you cling so tightly to the closed driver.

But AMD keeps saying(/intimating) that fglrx is going to remain the only choice that "makes sense". Why not start working towards making the open driver(s) as good as the nVidia binary? Why wait for the day when "the open source infrastructure may have advanced to the point where a closed source driver is not required"? Shouldn't the goal be to get the open source drivers to that point? Surely AMD has something to offer beyond specs and goodwill that isn't unreleasable 3rd-party code? Or does the fact that your devs have seen the 3rd party code preclude them entirely from participation?


*not to mention the second 770 motherboard I bought after frying the bios of my first one in hopes of getting fglrx to function. or the 790FX board I bought hoping for the same result. or the 2 X2 CPUs with broken temperature sensors(but those are largely OT except for the AMD-derived-frustration factor).

For years, people cried for documentation on ATI cards now that they get it they say that it's not enough.

AMD put out the specs. For years the community said "We aren't asking you to write the drivers, we will do it, we could do a better job."

AMD fulfilled it's end, it time for the FOSS developers to put up or shut up.

[Melcar]

For years, people cried for documentation on ATI cards now that they get it they say that it's not enough.

AMD put out the specs. For years the community said "We aren't asking you to write the drivers, we will do it, we could do a better job."

AMD fulfilled it's end, it time for the FOSS developers to put up or shut up.

My feelings exactly. All these years I kept hearing the same things over and over again; "give us the specs. and we will show you how it's done". Now that they have it, what? Yes, good progress is being made, but for all the talk back then, one would expect the FOSS drivers to be at least a few steps behind fglrx by now.

[bridgman]

You're correct, that is not what I meant. I'm sure you realize though what I was suggesting - if AMD wants to embrace Linux and Free software, it should do so to the fullest extent, not with the left-foot-in, right-foot-out approach currently employed.

It was late, and I was hungry, sorry

You said the magic words - "Linux and Free Software". To you, presumably Linux is all about free (as in freedom) software, and for you we support open source driver development. To others Linux is just a damn good operating system for high end commercial graphics and visualization, and for them we provide fglrx. They don't tell us to stop making open source drivers for you, and you shouldn't tell us to stop writing proprietary drivers for them

It's possible you think we have a huge team working on fglrx which could simply be diverted to work on open source drivers. That is simply not the case -- if we made the kind of investment in open source development that you are expecting we would have to pull developers off Windows and MacOS work, not just Linux.

Our Linux investment is already much bigger than the market share justifies. Some customers would like to see it all invested in feature-rich and high performance proprietary drivers, others would like to see it all invested in open source drivers -- but the two groups have totally different priorities and the solution for one will not satisfy the other.

My only problem with that is that AMD isn't making the results of that investment available to Linux users in anything remotely resembling the level at which you make it availabe to Windows users. fglrx doesn't even fully support X's feature set(not to mention that of the ATI hardware itself), instead we are saddled with the limitations of Microsoft's platform(multiple Xservers not supported? seriously?) And stability? I saw absolutely nothing resembling it in my 4 months trying to use ATI hardware. What I'm trying to say is your investment is not paying off at all the way you seem to think it is, certainly in this user's brief experience.

Until very recently fglrx was only targeted at commercial workstation customers using FireGL products and we offered the driver "as is" to consumer users. I think everyone agrees that was not enough to make for happy customers so we have been starting to increase focus on consumer users. You should be starting to see some of the benefits from that now and they will continue to roll out over the next few months.

If you want to use "every feature of X" then probably the open source drivers are a better fit for you. I realize you have a 6xx-family board and so we don't have 3d acceleration documentation available yet but that is a legal and IP process; all the developers in the world would not make it go faster (except for special cases like Alex who has an IP background and is a good writer in addition to being a very effective developer). We do have a number of people working on 6xx/7xx open source acceleration in parallel with the final documentation effort.

AMD got my money, an HD3650 and an HD3870's worth*. I got a small pile of perfectly good hardware which I couldn't use thanks to fglrx. And that is extremely frustrating.

All I can say there is "thanks for supporting us and I'm sorry we haven't made you happy so far, but we will".

You're holding back developers while you cling so tightly to the closed driver.

Um... yeah

Look, let me try to be as clear as possible. If you want all the features and performance comparable to that other OS then given the size of the Linux market the only practical way for us to provide those nice things is by sharing code across multiple OSes. That code is proprietary and needs to stay proprietary. Our vehicle for delivering that shared code is fglrx. This is relatively recent and the transition from separate to shared code is almost finished; two years ago there was a separate Linux-specific code base but the performance and features were not there.

If you want us to set up another huge team to duplicate all that work in a separate open source driver for Linux then I'm sorry but the market share is simply not there.

But AMD keeps saying(/intimating) that fglrx is going to remain the only choice that "makes sense". Why not start working towards making the open driver(s) as good as the nVidia binary?

That is not our message at all. If you see anybody or any materials saying that please let me know and I will get them fixed. I am saying that fglrx makes sense but that is not the same as it being "the only thing that makes sense".

You mentioned "intimating" rather than saying; again, if you see anything which even implies that fglrx is the only direction please let me know. Obviously anything from before last September doesn't count.

Why wait for the day when "the open source infrastructure may have advanced to the point where a closed source driver is not required"? Shouldn't the goal be to get the open source drivers to that point? Surely AMD has something to offer beyond specs and goodwill that isn't unreleasable 3rd-party code? Or does the fact that your devs have seen the 3rd party code preclude them entirely from participation?

It's a lot more than drivers. The whole X/DRI environment is in transition right now. The best open source driver in the world still wouldn't be close to a proprietary driver in performance and features if it worked within the current framework, but that will change over time. We need those changes for fglrx as well as the open source drivers, so we are "motivated"

We are trying to help the infrastructure move ahead, but in the short term that mostly involves taking on more of the driver development work ourselves so that devs who *would* have been working on new GPU support can make progress on other things like memory management and kernel modesetting. Once we are caught up with 6xx/7xx 3d we plan to put more direct and funded resources into the infrastructure itself.

Seeing proprietary code does not preclude someone from working on open source but in order to get the benefits you expect they would have to *copy* or transcribe that code into the open source drivers -- which we do not allow.

EDIT - one last point... this initiative is *not* about AMD writing open source drivers ourselves. As Melcar and deanjo said, the request from the open source community was to provide documentation and support. We are doing all that and more.

I thought Dave Airlie said it well in his blog post : http://airlied.livejournal.com/56605.html