Is ATI really on par with NVIDIA now?

[SyXbiT]

I know about all the announcements, and I know that ATI is making great strides.

BUT, what we all care about is RIGHT NOW.
It wasn't that long ago that I couldn't play DVD's properly with fglrx (major refresh rate problems). That made me sell it and buy an NVIDIA.
I have an 8800GTS (G92) right now, but would like to support ATI for its linux efforts. However, I will not support them until they are equal or superior to NVIDIA. (be that with either the OSS or fglrx).

I (like most people here) am all for open source. It's great, will enable better interoperability with the kernel and xorg and GNU/Linux distros in general, but, at the end of the day, like most users, I will choose to install whichever driver is best on linux. (the OSS, or fglrx).
Most people aren't free software freaks enough to use an inferior driver just because it's open.

I'd like to know your thoughts. (esp. at high end, like support in games/DVDs of 4870 vs 9800* with current drivers )

[Kano]

wine support is really bad with fglrx, keep your card, much better.

[d2kx]

It depends on what you're doing.

Native 3D applications/games run great with fglrx, watching videos is no problem either. But yes, wine + fglrx doesn't work as good as it does with nvidia at the moment (I think that this may change with the open source drivers). Overall, the open source support is worth getting an AMD card alone in my opinion (others may disagree).

[SyXbiT]

I started this post cause Phoronix themselves have stated that ATI is now on par witn NVIDIA. so, I took that to mean fglrx is on par with the nvidia binary.
mostly i'm interested in mpeg2/4, x264 playback and compiz

[some-guy]

mostly i'm interested in mpeg2/4, x264 playback and compiz
compiz + fglrx = tearing
video + compiz = only usable with x11/xshm (this doesn't happen with nvidia because nvidia doesn't follow DRI, which has this problem, DRI2 is going to fix this)

[d2kx]

Compiz + fglrx = works for me
Video + Compiz = works with Xv in fullscreen mode, DRI2 will fix this later

[Melcar]

Compiz + fglrx = works for me
Video + Compiz = works with Xv in fullscreen mode, DRI2 will fix this later

Yup. The new 8.6 now allows the playing of Xv/openGL accelerated videos as long as they're in fullscreen. The same for some games (Alien Arena still suffers from flickering). Compiz itself works fine, but I have noticed the tearing (specially with zoom).

[jeffro-tull]

eh. I've got an X1300 in my Thinkpad. It sucks. ACPI, video playback, and 3D? If I pick two of them, one of the available drivers will work. I've never had all three working satisfactorially for the two years I've had the laptop.

so, no. ATI is not yet on par with NVIDIA.

[Heiko]

Personally I think the binary nVidia drivers are slightly better then the AMD drivers at this moment. Although, AMD is catching up very quickly, I'm following the driver development closely since September 2007 (when I first heard about the improved Linux support by AMD).

As I own both, nVidia gpu's and an AMD gpu, I have the ability to compare the stability of the drivers. With nVidia I never had problems, everything worked just as I installed the driver. The AMD driver still contains some bugs which have to be solved before it is stable for the majority of the users (say 99%).

I have no experience with the open source drivers, but I think its a strong argument for buying AMD now. Why? Even if AMD itself wouldn't get it right (although I have no doubts they will get it right), there is a good chance that the open source community will provide a nice driver eventually. Besides that, the open source driver will probably have longer support. The AMD card I own is a 9500 pro, which is about the oldest card they still support. But as long as people from the open source community will use these cards, there probably will be driver updates for them.

Within a few weeks I'll buy a new computer and it will contain a new 4xxx series AMD gpu. I'm confident that within a few months you're better off having an AMD gpu then a nVidia gpu.

[Kano]

There must be always people with hope, otherwise ATI would not sell anything ;)

[Vighy]

Kano the pessimist, well know as "ATi's public enemy #1" :D :D

If you don't like fglrx, why don't you help the FOSS driver?

[Kano]

I did, I have found the 4 pipe too much error (only 4 not 8) of my X700 SE. I patched it differently than the final patch commited, but found it:

https://bugs.launchpad.net/bugs/151974

[some-guy]

Within a few weeks I'll buy a new computer and it will contain a new 4xxx series AMD gpu. I'm confident that within a few months you're better off having an AMD gpu then a nVidia gpu.
That will be a stable DRI implementation, DRI2/gallium(in radeon and radeonhd) will most likely come to distros in at least a year

[yoshi314]

http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.htmlit may look trollish but i think tha author has a point there, about one more reason why nvidia doesn't feel like opening their driver.

[bridgman]

The general reaction from X devs was "yeah, it's all true, but it's also almost fixed". Now that work on memory managers is going ahead it should be possible for DRI2 and RDR work to start moving again... and once that happens most of the issues covered by the article can go away.

Gallium is not on the critical path to the same extent -- it is not a pre-requisite for GL 2.x functionality, but most devs feel that it is "sufficiently better" than the current driver model that it's not worth implementing significant new functionality on the old driver model. The main pre-requisite for things like pbo's is better memory management.

[Vighy]

Mhh reflecting on the question of this thread, we can make a lot of comparisons and discussions, but what's for sure is that ATi is following nVidia, I mean on the closed sources drivers.

nVidia had SLI, AIGLX (and so on), much time ago.
ATi is close to Crossfire but has still to provide it, AIGLX was gained more than year late than nVidia... etc etc.

If really ATi is on par with nVidia, why don't they try to anticipate their competitor?

Would it be nice if ATi could start being on the bleeding edge instead of nVidia.

Obviously bugs need to be fixed, but nVidia is now having a good period too :D

so why don't you ATi guys put some killer features in your proprietary driver?
One that could be done, without waiting for Xorg to improve, could be kernel-based mode-setting.
or instead are you already woring on it?

DRI2 and EXA may be not suitable now, but kernel-based mode-setting seems to be "doable" :D

[yoshi314]

If really ATi is on par with nVidia, why don't they try to anticipate their competitor?ati is behind on the driver but ahead on the mindset ;-)

DRI2 and EXA may be not suitable now, but kernel-based mode-setting seems to be "doable"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.

[deanjo]

http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.htmlit may look trollish but i think tha author has a point there, about one more reason why nvidia doesn't feel like opening their driver.

Excellent link with some more good follow-up here http://lwn.net/Articles/288098/

[lenrek]

...
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.

Does NVidia develop the driver based any GPL's code? If none, then there is no issue.

NVidia had also made it clear:


... NVIDIA’s Linux graphics driver kernel module is structured so that all the code that is Linux-specific is provided in source code as a kernel interface layer. When customers upgrade their kernel to get the latest from kernel.org, they have everything they need to rebuild and even patch, if necessary the NVIDIA driver’s kernel interface layer...

Link: http://blogs.zdnet.com/open-source/?p=2588



Hence, the part where code should be open sourced has been released.

[Max Spain]

I did a little comparison here (http://www.phoronix.com/forums/showthread.php?t=11234) that pretty much validates what yoshi (and others) said.

[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 :D

[bridgman]

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

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/~cbrill/dri-log/index.php?date=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 :D

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 :D
I didn't know you liked our food! :D Are you going to have a speech in Italy in the future? :D would be nice to come to listen to you :p


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 :p), 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 :D

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 :DYou'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. :p

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. :p

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 :D

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. :p

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" :D

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

[d2kx]

I haven't been actively discussing this topic on here, but have been following what users & AMD say with great interest. Thank you for those long explanations, bridgman!

I, personally, have started using Linux, because it is free, as in freedom, but still, I am using some proprietary software here and there (mainly talking about fglrx and Windows for gaming, which I am doing less and less). Hopefully, this will change in the not too distant future :)

[Regenwald]

hm "come on all you hackers..."
is there an increase of x-devs/ati-hackers? are more people working now on the oos-driver? now that there are docs (for several months..), i wonder wheather there are more people working on x-drivers...
x is definitly *the* dark corner in linux...

[deanjo]

hm "come on all you hackers..."
is there an increase of x-devs/ati-hackers? are more people working now on the oos-driver? now that there are docs (for several months..), i wonder wheather there are more people working on x-drivers...
x is definitly *the* dark corner in linux...

lol. If it wasn't for the contribs of intel/amd/novell developers the x community would be going "w00t!!!! We won!! We got docs!! Now what? Who want's to write drivers?"
............
..........
.........
.....
...
..
.

*more silence*

[bridgman]

also Red Hat (airlied) and a couple of very active independents (nha and MostAwesomeDude) who did nearly all of the R5xx 3D work and are continuing to work on the code to get it ready for porting to Gallium. Glisse is doing some interesting work on analyzing and preventing lockups... I know I'm forgetting someone else, sorry.

EDIT - forgot osiris and z3ro.

The big change I see is that 5 years ago there were lots of independent developers who did something different during the day and hacked on X during the evenings; now they all work for distros or IHVs. We need to help the next crop of developers get started, unfortunately it's a pretty complex environment these days for someone trying to get started.

[Redeeman]

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.
Yes, except that they havent actually done it yet, they are in the PROCESS of fulfilling their end, and once they have done, nothing more can be expected of them. If they do more, thats great, if not, well.. their choice..

[Vighy]

also Red Hat (airlied) and a couple of very active independents (nha and MostAwesomeDude) who did nearly all of the R5xx 3D work and are continuing to work on the code to get it ready for porting to Gallium. Glisse is doing some interesting work on analyzing and preventing lockups... I know I'm forgetting someone else, sorry.

EDIT - forgot osiris and z3ro.

The big change I see is that 5 years ago there were lots of independent developers who did something different during the day and hacked on X during the evenings; now they all work for distros or IHVs. We need to help the next crop of developers get started, unfortunately it's a pretty complex environment these days for someone trying to get started.

How could people start? what's the base knowledge you have to own to be able to put your hands on such an enormous project?
These are some of the initial problems to solve: provide, to the ones that would like to start, a way to grow and learn how to manage such problems.

Is there any strategy to solve this situation?

[Melcar]

How could people start? what's the base knowledge you have to own to be able to put your hands on such an enormous project?
These are some of the initial problems to solve: provide, to the ones that would like to start, a way to grow and learn how to manage such problems.

Is there any strategy to solve this situation?


Everyone seemed confident before. They just got taken by surprise and are overwhelmed. I don't think many were expecting the level of commitment AMD has shown.

[oblivious_maximus]

It was late, and I was hungry, sorry :DNo need to appologize, it must be tiring sometimes(or often perhaps) having to respond to so many people's concerns/queries. Thanks for being such a dilligent responder.

It's apparent from the replies that my own posts don't even really explain very well what I'm thinking here, and that I'm not even sure myself what I'm thinking. It all stems from my simply wanting to use the hardware I bought without fear of lockups, and from the clear functionality & stability disparity between the Windows and Linux drivers. From my perspective fglrx just doesn't seem like something worth putting much continued effort into. I guess I'll have to hold out and see if my opinion on that can be changed, but the fact that you're telling me I can't rely on being able to use any given X feature doesn't help my optimism. I'm still really thinking "seriously?" on that point, I just don't understand how "we don't support using x or y feature of X" can be AMD's position.

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"I'll see if I can't find some Phoronix articles that left me with that impression, but your own words from earlier in that post are a good example of what I'm talking about. You wrote: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."feature-rich and high performance proprietary drivers" vs "open source drivers". The implication being that open source drivers couldn't possibly be high performance and feature rich. Every time the two approaches are mentioned together(seemingly, from my craptastic memory at least), it's that same dichotomy.

Something I'm sure of my thoughts on - the people who want feature rich and high performance but don't care about openness would still be quite happy with a feature rich and high performance open driver, wouldn't they? I do accept your point though, re: AMD's existing software investment so please don't take this paragraph as an argument for abandoning flgrx, more as an argument for keeping an open mind (which seems to be the plan anyway, from the rest of your post so...).

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.I think you're overestimating my expectations a little (which is probably my fault :p). In much the same way I don't want to use a driver which causes me to stress over when I'm next going to have to use the reset button, I don't want to buy a 3D card only to get <50% of its capability because of the driver. I just hope that if that's the level of optimization that X.org devs are able to provide, AMD would be inclined to make efforts to push performance a bit higher, so that the performance difference between open and closed isn't a night and day -type contrast. The end of your post seems to indicate that's kind of already on the roadmap (certainly infrastructure-wise at least), so I'm glad to hear that.

I just want to explain that I wasn't suggesting AMD just drop Catalyst for Linux altogether, immediately. Obviously it's working for some people/customers. And I wasn't suggesting that AMD put in enough people-power to duplicate Catalyst performance/feature-wise with ati/radeonhd. Just that I think it would ultimately be advantageous for AMD to put more resources into helping to make the open driver(s) as good as they can be. I don't see why that has to mean ripping code out of fglrx, but I'm just a humble(ok not so humble) user.

I have certainly become a Free software lover, and quite anti-proprietary software over the last few years, but my use of "Linux and Free software" was more intended to be an all-project-encompassing term, X.org, Mesa, the various distros themselves, and the BSDs also, rather than a "Free=correct proprietary=incorrect" -type comment. It seems to me once the open drivers are up and running, ATI hardware would be supported on a truckload more operating systems than at present(and not just GNU/Linux ones), with fglrx only being tested on 3 distros (2 of which nodody outside an office really uses).

[Kano]

ATI can keep the fglrx drivers, but the bugs in there usually stay in for years. It is even more likely that new bugs are added: like 8-6 is completely unsable for wine due to corrupts, 8-5 worked at least most of the time. There are several other errors, and the attitude that "we don't add kernel x support until it is released" it absolutely crap. In most cases there are ways to run the drivers with new kernels, but why on earth do others need to do the job for ATI? At least for the drivers of the current hardware lineup Nvidia provides 2.6.26 capable drivers, but better don't expect that even when there is rc9 now... And the kernel 2.6.26 IS used in Ubuntu/intrepid! So it would be extra funny to have got a build target which does not compile ;) Something that only ATI can do.

[bridgman]

ATI can keep the fglrx drivers, but the bugs in there usually stay in for years. It is even more likely that new bugs are added: like 8-6 is completely unsable for wine due to corrupts, 8-5 worked at least most of the time. There are several other errors, and the attitude that "we don't add kernel x support until it is released" it absolutely crap. In most cases there are ways to run the drivers with new kernels, but why on earth do others need to do the job for ATI? At least for the drivers of the current hardware lineup Nvidia provides 2.6.26 capable drivers, but better don't expect that even when there is rc9 now... And the kernel 2.6.26 IS used in Ubuntu/intrepid! So it would be extra funny to have got a build target which does not compile ;) Something that only ATI can do.

In fairness, the "attitude" is that support for unreleased kernels and unreleased distro versions is lower priority than some of the *other* issues our users would like to see addressed -- so we work on those other issues first.

Once most of the other hot issues get settled we should be able to start working earlier with new kernel and OS versions. Our intent is still for open source drivers to track the bleeding edge while fglrx focuses on released distros and kernel versions, but I think we would all like to start working earlier on new stuff coming from upstream.

[Kano]

Mabye it is too hard to understand that after a few rc of a new kernel is it highly unlikely that the ABI will change. Therefore waiting up to the point where a kernel is finalized is extra stupid. Also when you look at 2.6.26 and x64 then ATI really fails badly - ever for released kernels. Not even that was fully tested, it is a real joke with fglrx. If ATI would really want to compete with NVIDIA then they would provide patches ON THEIR OWN - and not wait till the commuity finds em. Just like NVIDIA does whenever needed. The excuse that for driver xy the timelimit was hit is really bad. Provide official patches or make your drivers compatible directly. Thats the way driver development should work - not the other way around.

[bridgman]

Not a question of understanding, just of "opportunity cost", ie what would we have to "not do" in order to spend time working on upcoming kernels. Historically these have been very hard choices; going forward things should be easier.

2.6.26 is not a released kernel, is it ? I agree it is pretty close (new RC recently) but AFAIK it's not released yet.

[Kano]

Did you ever look at:

http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

If you want to be at least so good as your competitor don't behave much worse!

[Melcar]

I don't get why you keep insisting on the same thing Kano. Bridgman already said countless times that fglrx targets "mainstream", released platforms, and not what hasn't been released (like kernels). They consider those things "bleeding edge" and don't consider them a target for their driver. Such things are left to the open source drivers, where it should be much easier to patch. Nvidia does not have a viable open source driver, so they *have* to make sure it works with everything.

[Kano]

That thread was about parity with NVIDIA. And therefore you have to compare everything. Nobody buys a gaming card to run it with 10-20% speed and lacking features (you may want to run the lowend cards with free drivers). Does ATI really think that midrange/highend cards are driven with opensource drivers? Nice try to use opensource drivers as excuse, but for me they are years behind. Of course driver developments costs money, but does a huge enterprise say that as excuse? Others have then the problem - really nice.

[deanjo]

Nvidia doesn't support officially support non final release kernels as well.

[Kano]

But they provide patches even for unreleased kernels, ATI does not.

[bridgman]

Is there a specific article I should be reading ? I see lots of users looking for help with problems, and a driver release from a couple of weeks ago with "preliminary support for 2.6.26" although I don't think that works with the newest GPUs.

The difference is that there are already full-featured open source drivers for most of our GPUs, backed up with documentation and support for the developers, which do work on the new kernels today. I think you will see the "few week gap" close up over time but honestly for anyone who wants to use unreleased distros or kernels we are encouraging the use of open source drivers not fglrx.

[Kano]

NVIDIA released offical patches for kernel 2.6.26 for those drivers: 96.43.05 (GF2MX to GF4) , 173.08, 173.14.05 (GF5 and newer). Direct support is in 173.14.09 (latest stable) and 177.13 (lastest beta for GTX 260/280 and older cards since GF 6).

[bridgman]

The point I am trying to make is that NVidia has no choice but to supply early patches for unreleased kernels since they do not provide the same kind of support for open source driver development as AMD and Intel, and therefore users need to run with the binary drivers even if they are following the "bleeding edge". We chose to invest relatively more resources into supporting open source drivers instead.

We all take different approaches and some people will probably prefer NVidia's strategy over ours, just as there are people who prefer our strategy over NVidia's.

[Kano]

Yes, in one point you are right, NV does not provide 3d support in OSS drivers. Maybe they could add basic support to run at least Compiz sooner or later - you can not really say that OSS drivers are first choice when you want to play games. Also do you think that your OSS developers are unable to fix fglrx kernel problems? I guess they would not really require so much time to do so.

[some-guy]

the reason for fglrx (technically) being able to perform better is that it has access to parts of the hardware that amd can't give specs on

[bridgman]

That actually hasn't been an issue yet. Most of the info we need to hold back is in DRM-related areas. There are a couple of things we left out of the r5xx doc because they were hugely complicated to document and support but only gave a couple of % performance difference. If the open source driver gets to the point where all the pre-requisite support is there we will try to find a way to get that information out too, either by writing a big honkin' document or (more likely) adding the code ourselves.

Right now the main reason for the performance delta is that the open source driver architecture is relatively old, but that is improving rapidly. The fglrx 3d driver stack has literally hundreds of man-years of accumulated effort in performance tuning and optimization, and was re-written from scratch (millions of lines of code) in order to deal with the remaining architectural issues in our previous OpenGL stack.

I expect to see big improvements in open source driver performance over the next year as initiatives like kernel memory management and Gallium start to kick in. If you follow the IRC channels (#radeon and #dri-devel mostly) you can see some of that work happening right before your eyes. If you're into the technical stuff, take a look at the work nha is doing in Mesa to improve the shader compiler logic and get ready for the transition to Gallium.

[Kano]

You are always referring to the future, don't you get that? You build an idealitic picture of what it will be. But today, now the things are really different - and you have to look at today when you want to buy a good supported card - until you are willing to test every little improvement youself to see the progress.

[bridgman]

I'm the open source project manager, it's my job to talk about the future :D

Seriously though, everyone knows the current state; 5xx, 690 and earlier have pretty good open source support but run 30-50% as fast on average for things like gaming, GL support is just shy of 1.4, which is a problem for some games, and support is only just starting to make its way into distributions. Closed source runs real fast but you will have trouble running on unreleased kernels and distros, and there are still improvements to be made in both open and closed drivers, with 6xx/7xx open 3d being the biggest hole today.

I am also talking about what we *don't* do, ie we are not making an attempt to support closed source driver use on unreleased kernels or distros other than for testing purposes, and are not likely to do so in the future.

The question was whether open source performance was limited by information we had held back from the development community. I guess I could have just said "is not !!" and not said what *would* have to change to improve open source performance but let's be blunt, serious open source gaming still *is* in the future on integrated and low end discrete graphics. Fortunately we also make reasonably high end cards.

[RobbieAB]

[snip]... let's be blunt, serious open source gaming still *is* in the future on integrated and low end discrete graphics. Fortunately we also make reasonably high end cards.

I know many wargames fans who would take issue with not being classified as "serious" gamers. Indeed, I would place myself in that group... :D

[bridgman]

I know many wargames fans who would take issue with not being classified as "serious" gamers. Indeed, I would place myself in that group... :D

OK, let's make that "graphically demanding" :D

EDIT -- in hindsight, the whole performance vs hardware vs game vs resolution vs driver vs settings thing is too complex for a one-line comment. For any given GPU family the high end product is typically between 5x and 10x as fast as the low end parts, and with the same hardware and display you can easily get a 4:1 range or better by changing resolution or eye candy. Maybe serious open source gaming is no longer the future, except for games which demand a higher level of GL support than the drivers have today.

[bnolsen]

Yes, in fact ATI is probably beyond nvidia at this point.

A week ago the 7600GS in my system burnt up. Bad fan & melt city.
Just replaced it with a 3650 I got at microcenter for $49.

Really night & day.
The RainSlicked demo on the 7600GS ran painfully choppy at low quality 1280x768
The 3650 ran the same demo 1680x1050 high quality absolutely smoothly.

Actually now I don't even have any nvidia cards left in any of my machines, neither work nor home.

[Ellipsys]

Let me be the first to say I'm a Linux noob - I've messed around with a few distributions in my time. Debian (Thanks Kano!), *buntu, and I'm looking forward to trying Arch soon, when I can devote an entire hard drive to Linux use!

I'm trying to decide on a new, high performance video card for my uses. Pretty much, I know I'm going to be dual booting, but I'd like to spend as much time in Linux as possible. That means I, for lack of a better phrase "want it all".

I plan to game both under Windows when required, but would like to play as many of my games as possible (with eye candy) in Linux. In many cases this will require the use of WINE, I am sure. Aside from gaming, I plan to mess around with Compiz-Fusion, watch full screen HD video etc.. and all those other graphically demanding issues. I have no use nor need for DRM, so that's not a consideration for me. I don't purchase DRMed media.

Would it be wise, for me to buy an ATI card at this point? I applaud ATI's open source efforts and hope they continue and expand, but I need functionality, so I don't mind using a closed-source driver if need be. I'm also a little concerned about ATI's answer to CUDA, NVidia's PhysX implementation.

I really want to support ATI, but I really can't spend my money on an expensive video card only to find that its a couple of years ago again, and I'm shouting at my Mobility x600 trying to get 3D support with fglrx, while everyone around cries out "ATI = your problem. Should have bought Nvidia".

Trust me, I really want to support ATI's efforts and I realize that I "want a lot" from my cards, compared to those who are going to primarily use 2d apps.

Bridgman - Thanks for coming onto a forum like this. Its cool to see a direct rep from AMD/ATI here. Please know that there are a number of us (and that number is growing, I think) who want high powered 3d gaming on an Open Source operating system, would we have the cards and drivers that support it. Are there plans to get proper and up to date OpenGL support into the drivers?

[some-guy]

Let me be the first to say I'm a Linux noob - I've messed around with a few distributions in my time. Debian (Thanks Kano!), *buntu, and I'm looking forward to trying Arch soon, when I can devote an entire hard drive to Linux use!

I'm trying to decide on a new, high performance video card for my uses. Pretty much, I know I'm going to be dual booting, but I'd like to spend as much time in Linux as possible. That means I, for lack of a better phrase "want it all".

I plan to game both under Windows when required, but would like to play as many of my games as possible (with eye candy) in Linux. In many cases this will require the use of WINE, I am sure. Aside from gaming, I plan to mess around with Compiz-Fusion, watch full screen HD video etc.. and all those other graphically demanding issues. I have no use nor need for DRM, so that's not a consideration for me. I don't purchase DRMed media.

Would it be wise, for me to buy an ATI card at this point? I applaud ATI's open source efforts and hope they continue and expand, but I need functionality, so I don't mind using a closed-source driver if need be. I'm also a little concerned about ATI's answer to CUDA, NVidia's PhysX implementation.

I really want to support ATI, but I really can't spend my money on an expensive video card only to find that its a couple of years ago again, and I'm shouting at my Mobility x600 trying to get 3D support with fglrx, while everyone around cries out "ATI = your problem. Should have bought Nvidia".

Trust me, I really want to support ATI's efforts and I realize that I "want a lot" from my cards, compared to those who are going to primarily use 2d apps.

Bridgman - Thanks for coming onto a forum like this. Its cool to see a direct rep from AMD/ATI here. Please know that there are a number of us (and that number is growing, I think) who want high powered 3d gaming on an Open Source operating system, would we have the cards and drivers that support it. Are there plans to get proper and up to date OpenGL support into the drivers?
Nvidia, it isn't limited by DRI, will give you good performance.

Replace it with an ATi one in a few years ;)

[Ellipsys]

Nvidia, it isn't limited by DRI, will give you good performance.

Replace it with an ATi one in a few years ;)

I'm kind of new so, what do you mean that Nvidia isn't limited by DRI? Is this related to the fact I hear the Nvidia closed source driver kind of...subjugates or takes over part of X and ATI "honors" the way things are supposed to be done?

Also, does everyone else agree with this? Nvidia for the time being? *le sigh* I hate to pay an extra couple hundred for minimal performance increase over 4780, and working Linux drivers. But...if that's what needs to happen..

[val-gaav]

I'm kind of new so, what do you mean that Nvidia isn't limited by DRI? Is this related to the fact I hear the Nvidia closed source driver kind of...subjugates or takes over part of X and ATI "honors" the way things are supposed to be done?


Yes that exactly is the problem ... So until dri2 you will have some glitches mainly with 3d desktop.

As for wine as you ask about it ... Wine is more nvidia friendly right now ... You can run it with games + fglrx with some hack in wine registry ... or so they say ;) but well still nvidia drivers will give you more chances to get your games working...
Here is a good read about Wine + fglrx
http://www.phoronix.com/forums/showthread.php?t=10104&page=5


though you should also note that newest nvidia cards have also problems:
http://www.phoronix.com/forums/showthread.php?t=11044

[mtippett]

Yes that exactly is the problem ... So until dri2 you will have some glitches mainly with 3d desktop.


Just to clarify, there is nothing fundamentally stopping drivers from using DRI to achieve full COMPOSITE support (which is what people are really talking about when they talk about Compiz+Video, Compiz+3D, etc. Direct clients (Video, OGL, etc) currently ignore the redirected window and continue to render directly to the screen instead of the buffer.

There is sufficient infrastructure within DRI to allow any driver to do provide full COMPOSITE support. This is since DRI is basically an interface for communicating between X, DRM and the Client. Each driver has a shared area that is private. This can be used for whatever the driver requires. This is where the drivers can share information required to achieve COMPOSITE support.

Note however that for the Mesa in core XOrg drivers the developers will not want to do this on a per driver basis, but would rather provide it to all drivers at the same time. This is where DRI2 comes in. DRI2 provides a refresh of the interfaces with explicit knowledge of what is required for COMPOSITE support.

So for the OSS drivers to achieve full COMPOSITE support, you will need at least DRI2 and TTM. Depending on when the dust settles, this may also be in time with Gallium (the new Mesa) and also kernel modesetting.

Regards,

Matthew

[Pickup]

How about the old cards? Most of the work in the new drivers is spent for the newer and the less-newer cards and chipsets, but while people is developing a driver for those cards a brand new one comes out. And someone have to write a driver. So, I sense developement resources move continously to the newer and slowly drops the older, leaving drivers for the legacy stuff half-developed.

The question is: will a GPU - any GPU - be "fully supported"?

[null8]

I got me 4850 for around 150 euros to play some games and support AMD in it's open source efforts.
I completed crysis on it on high settings with directx9. I mostly use linux for work and I found the fglrx driver much better than the last time I tried it (in the age of radeon 1950pro). It even has 2d acceleration unlike my last geforce 8800gts. Even if there were, I am fed with the whole linux driver situation so I am dead serious of not buying nvidia ever unless they release the damn specifications. I also advise you to put your money where your mouth is, so if you want to use non-windows OS'es and want to have a complete driver in the long run - do something about it and buy an ati/intel card.

[Pickup]

I also advise you to put your money where your mouth is, so if you want to use non-windows OS'es and want to have a complete driver in the long run - do something about it and buy an ati/intel card.

An Intel card? Do Intel-based video cards (not mainboards with Intel graphic chips) exist?

[yoshi314]

eh. I've got an X1300 in my Thinkpad. It sucks. ACPI, video playback, and 3D? If I pick two of them, one of the available drivers will work. I've never had all three working satisfactorially for the two years I've had the laptop.i have x1300 in my desktop pc and i have all three working nicely. (hint - try git snapshots of mesa and drm modules for nicely working 3d ;-) )

[d2kx]

i have x1300 in my desktop pc and i have all three working nicely. (hint - try git snapshots of mesa and drm modules for nicely working 3d ;-) )

Yeah, I recently tested Ubuntu 8.04.1 with the Xorg-Edgers packages and it was an amazing desktop experience in terms of Compiz, video support and 2D performance :) But I wouldn't recommend it for everyone yet (productivity) as I had some package conflicts.

[Vighy]

An Intel card? Do Intel-based video cards (not mainboards with Intel graphic chips) exist?

If there was, it would have been my next card :D

well I really don't know if they exist!

[charon]

If there was, it would have been my next card :D

well I really don't know if they exist!

Just wait for Larabee. :D Should arrive in Q2/09 (well, next year). But keep in mind that it is supposed to need around 300 W...

[d2kx]

I don't expect Larabee before Q4 2009 or Q1 2010. It was made for raytraycing, but is also able to render using existing methods.

[Kano]

It will use up to 32 Pentium MMX cores, funny way of a GFX card *g*

[Pickup]

It will use up to 32 Pentium MMX cores, funny way of a GFX card *g*

Yes but they did not say they will sell that Clarybelle chip as a video card. It is likely to be THE video counterpart for Intel-cored computers, plugged on mainboards or even embedded into the CPU itself. I suppose AMD will do the same with ATI GPUs, and we will say goodbye forever to the video card market, and NVidia will be forced to sell itself to another (which?) CPU manufacturer or close its business.

[curaga]

Now now, let's not be hasty.
The prototype will be improved upon, the final product isn't likely to consume all 300W. And there's 1-2 process shrinks coming before it's launch anyway, that should bring the consumption down.

The cores being based on i586 - so? With current tech 32 of those can be tucked into a smaller package than a single current Core2. And based, well means just that. It's not like it won't be improved over the Pentium days. We already know they will get 512-bit vector units.

[Regenwald]

the "expected" tdp will surely go down. moreover, i think that they could easily implement several power optimizations i.e. they could deactivate several cores and just activate as much as the current usage needs. just 2 cores for standard 2d, the other (30?) cores sleep or "power off"...:)