Tear-Free Acceleration For ATI EXA, Xv

[phoronix]

Phoronix: Tear-Free Acceleration For ATI EXA, Xv

For those of you that have been using the open-source xf86-video-ati driver, need we remind you of its rapidly-improving state and feature set? One of the latest additions to this open-source ATI driver that supports the old ATI R100 graphics cards up through the new Radeon HD 4800 series (RV770) is tear-free acceleration. The current implementation of this tear-free acceleration is for EXA and Textured Video (X-Video) and should eliminate any "tearing" issues that some users experience...

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

[Pickup]

Does it mean we'll have a 6.9.1 "tear-free" ati driver pretty soon?

My old Nvidia with proprietary driver displays the most tearish 2d I've ever seen... My next card will be an Ati, no more doubt.

[izual]

One of the latest additions to this open-source ATI driver that supports the old ATI R100 graphics cards up through the new Radeon HD 4800 series (RV770) is tear-free acceleration. The current implementation of this tear-free acceleration is for EXA and Textured Video (X-Video) and should eliminate any "tearing" issues that some users experience.

That sounds like there is already EXA and Xv support for the R7xx series. But that's not true is it?
I had to read this part 3 times before I understood it correctly ;)

[sundown]

Sounds like the radeonhd devs are losing groung in what seems to be an internal developer's competition of who will bring out the cooler driver.

Anyone cares to remind me why we're having two open working drivers again?

[RoboJ1M]

As somebody who tried to get Xv and other things working in the fglrx bad-old-days, I read the title as, "Tears-of-frustration free".

J1M.

[bridgman]

Sounds like the radeonhd devs are losing groung in what seems to be an internal developer's competition of who will bring out the cooler driver. Anyone cares to remind me why we're having two open working drivers again?

This patch (and radeon itself) handles four generations of cards which radeonhd does not support. We are trying to keep largely common acceleration code between radeon and radeonhd anyways, so I don't think there is any competition here.

Check out the "quick & dirty 2d" branch of radeonhd and let us know what you think.

[Zhick]

Awesome! As soon as this code hits master I'll switch back to radeon.

[Pickup]

We are trying to keep largely common acceleration code between radeon and radeonhd anyways, so I don't think there is any competition here.


I see, but then what is the reason for having two drivers? they should merge, or separate completely (up to 600 managed by radeon, the upper by radeonhd).

[Zhick]

The cleanest cut would probably have been between r500 and r600, so all <=r500 would have been supported by radeon (as the r500 and the previos Radeon Chips share much acceleration-code) and everything >=r600 would have been up to radeonhd. But at the time radeonhd was started it was about supporting the Radeon-Chips which were not already supported by radeon then, and thus they started working on r500.

[bridgman]

Yeah -- if you look at the display controller then 4xx/5xx is the logical split, but if you look at acceleration then 5xx/6xx makes a lot more sense.

The radeonhd initiative was driven by the need for modesetting support, while the post-4xx radeon work was driven by the need for acceleration support. We hope the two efforts can pull together over time. I suspect that once we reach a common understanding on requirements, priorities, design / coding practices and the importance of things like kernel modesetting the rest will be easy ;)

[Louise]

Yeah -- if you look at the display controller then 4xx/5xx is the logical split, but if you look at acceleration then 5xx/6xx makes a lot more sense.

The radeonhd initiative was driven by the need for modesetting support, while the post-4xx radeon work was driven by the need for acceleration support. We hope the two efforts can pull together over time. I suspect that once we reach a common understanding on requirements, priorities, design / coding practices and the importance of things like kernel modesetting the rest will be easy ;)

I read that the reason Red Hat is devoting man hours in this is because they have customers demand. Or if I remember right, they said they had one customer that could see a business model for OSS gfx drivers.

So I am wondering, is Novell's and Red Hat's demands/needs the same?

E.g. does Red Hat put emphasis on something else than Novell?

[bridgman]

AFAIK the original reason for pushing ahead with radeon was that RH had a specific customer program which needed 2d acceleration and didn't feel that radeonhd would be able to make the schedule based on progress to date. By adding atombios support to radeon they were able to use all of the existing 2d accel code since the 2d block was pretty much identical to previous generations.

A contributing factor was that both the radeon and avivo developers were OK in principle with writing a new, atombios based driver for 5xx and above rather than building on their existing code, but when radeonhd turned out to be mostly hard-coded the idea of adding atombios-based support to radeon started to look more attractive.

[Louise]

Wow.

I really think that Red Hat and IBM are interesting companies. I fear to think how much Red Hat spend on Ice Tea!

Have Novell said anything on why they are dedicating so much effort and money?

[jeffro-tull]

Hmmm, I might have to ditch my geforce 6200 in my tower in favor of my old Radeon 9000 Pro. The extent of my 3d needs are Chromium BSU (when I'm too lazy to go into the other room and fire up R-Type III). As long as I get damn-near-spotless 2d support (which Nvidia has been sliding downhill with) I'm happy.

[bridgman]

Have Novell said anything on why they are dedicating so much effort and money?

I think everyone is trying to achieve the same ends -- to advance what can be done with Linux and expand the potential market. Both Novell and RH are trying to "give back" where they can. There are some differences in the RH and Novell customer bases today and so they do have some different short term priorities. Please don't ask me for details :D

[Louise]

I think everyone is trying to achieve the same ends -- to advance what can be done with Linux and expand the potential market. Both Novell and RH are trying to "give back" where they can. There are some differences in the RH and Novell customer bases today and so they do have some different short term priorities. Please don't ask me for details :D

I won't =)

But I was surprised to read that Ubuntu decided to include the OSS gfx drivers for Ubuntu 8.10. Would have expected they didn't care, since they have the closed source drivers in their repositories.

[DeeZiD]

Does this mean that it's soon possible for me (with my dirty HD2600 mobility) to watch video and use a composited desktop without any tearing like in vista or macosx? :D

INCREDIBLE!


Dennis

[bridgman]

I don't think any of the distros want to be totally dependent on proprietary drivers when they are being expected to provide a seamless user experience on a huge variety of hardware. By booting the open source driver out of box they have the ability to cherry-pick specific fixes which match the rest of their release, although I don't know how much of that is done with Ubuntu.

[curaga]

Does this mean that it's soon possible for me (with my dirty HD2600 mobility) to watch video and use a composited desktop without any tearing like in vista or macosx?By this you of course meant you get tearing only in vista and OS X :D

[DeeZiD]

By this you of course meant you get tearing only in vista and OS X :D

ahhrgh :D
My English...

[an0n1m0us]

I'm completely confused.

AFAIK *before* AMDTI disclosed details about their cards, there was one open source driver trying to support ATI cards through reverse engineering. Is this correct? Was this the xf86-video-ati driver?

AFAIK *after* AMDTI disclosed details abou their cards, xf86-video-radeonhd was likely to take over the open source ATI driver mantle and xf86-video-ati was in it's death throes.

What has changed? Why didn't xf86-video-ati die? What is the point in confusing end users with two open source drivers for (largely) the same hardware? Where is xf86-video-radeonhd at the moment?

When will ATI cards finally "just work", "out of the box", on most Linux distros?

I hear a lot of news about different developments here on Phoronix but I'm confused about the bigger picture context.

[mityukov]

Sorry, is EXA-support enough for Compositing on itself?

I mean, do I need to compile Mesa with the latest HW support, in order to have KWin 4's (or Compiz's) Desktop Effects working?

Or, it's now enough to install the latest build of xf86-video-ati driver?

[bridgman]

I'll answer the easiest question first. There is a delay between having drivers available in git and having them included in "out of box" distros, typically 6 months or so.

I think the modesetting driver support has been around long enough that most new distros include that support out of box. 3D acceleration for 5xx and rs6xx is more recent so is not included in the current crop of distros (other than F9) but should show up in the next round of distro releases.

re: EXA and compositing, as I understand it full EXA is enough to support some compositors (eg. Metacity) but you need OpenGL for Compiz. Not sure about KWin, but I'm fairly sure it requires OpenGL as well.

[agd5f]

The tear-free code is more of a proof of concept than anything else. I doubt it'll actually get merged to master.

It basically inserts a stall in the command stream to wait until the vline trigger is past the active area of the display. The problem is you don't really want to stall the engine if you can avoid it, plus, depending how large your command stream is, you may not finish rendering by the time the crtc starts scanning again anyway. The real solution is compositing and pageflipping. You'd basically do all of your rendering to a different buffer than you are currently scanning and then insert a page flip at the end of the command stream. As soon as the rendering was done, the buffer pointers would flip and the crtc would scan out of the newly rendered buffer at the next retrace. That way you are never rendering and scanning out of the same buffer at the same time.

[panda84]

re: EXA and compositing, as I understand it full EXA is enough to support some compositors (eg. Metacity) but you need OpenGL for Compiz. Not sure about KWin, but I'm fairly sure it requires OpenGL as well.

KWin 4 supports both OpenGL and XRender acceleration (in fact it runs -- slowly -- also in my really old Trident 8MB shared through XAA).

[Uber]

The tear-free code is more of a proof of concept than anything else. I doubt it'll actually get merged to master.

It basically inserts a stall in the command stream to wait until the vline trigger is past the active area of the display. The problem is you don't really want to stall the engine if you can avoid it, plus, depending how large your command stream is, you may not finish rendering by the time the crtc starts scanning again anyway. The real solution is compositing and pageflipping. You'd basically do all of your rendering to a different buffer than you are currently scanning and then insert a page flip at the end of the command stream. As soon as the rendering was done, the buffer pointers would flip and the crtc would scan out of the newly rendered buffer at the next retrace. That way you are never rendering and scanning out of the same buffer at the same time.

I love to test this as I have been wrestling with the tear in ATI for 6 months not in my HTPC running Mythtv.

I have an ATI 2600 card and is running Ubuntu 8.04 and Mythtv.

I have 2 DVB cards that deliver SD(Mpeg2) and HD (1080I H.264)

What further packages do I need to build to test this driver, and any special xorg.conf setings I should have ?

I kill for XVMC or at least proper XV and non tear video.

Good work for showing of something to teat and maybe we all get rid of the crappy tearing on ATI cards.

[Uber]

I don't think any of the distros want to be totally dependent on proprietary drivers when they are being expected to provide a seamless user experience on a huge variety of hardware. By booting the open source driver out of box they have the ability to cherry-pick specific fixes which match the rest of their release, although I don't know how much of that is done with Ubuntu.

I think everyone just want the spechs to be known and an working driver. Bug will be fixed just like any other GPL package.

It's not like the proprietary driver have anything useful that an open implemntation would miss nor any more "bug free".

It's not rant, it's an good thing ATI open up the spechs and in some time this will help them compete with Nvidia.

ATI got loads of PR that would cost $$$ othervise.

[agd5f]

I love to test this as I have been wrestling with the tear in ATI for 6 months not in my HTPC running Mythtv.

I have an ATI 2600 card and is running Ubuntu 8.04 and Mythtv.


This code only affects r1xx-r5xx radeons as there is no acceleration code yet for r6xx chips like the 2600. We are working on initial code and documentation now.

[Uber]

This code only affects r1xx-r5xx radeons as there is no acceleration code yet for r6xx chips like the 2600. We are working on initial code and documentation now.

Doh!

Ok, I have a few other boxes in my lab I could build for testing and setup as Frontend to my Mythtv HTPC. (SocketA/Pentium4 etc)

I have a box with an pile of mix from ATI Rage -> Radeon 9800 cards,
anyone that would work better than others ? (AGP/PCI)

So, any quick words/links to what other packages I need to build before making your git version ?

Looking forward to the R600 code :)

The closed driver claims to have fixed the tearing, maybe I'm missing something in the xorg.conf..

[airlied]

I'm completely confused.

AFAIK *before* AMDTI disclosed details about their cards, there was one open source driver trying to support ATI cards through reverse engineering. Is this correct? Was this the xf86-video-ati driver?

AFAIK *after* AMDTI disclosed details abou their cards, xf86-video-radeonhd was likely to take over the open source ATI driver mantle and xf86-video-ati was in it's death throes.

What has changed? Why didn't xf86-video-ati die? What is the point in confusing end users with two open source drivers for (largely) the same hardware? Where is xf86-video-radeonhd at the moment?

When will ATI cards finally "just work", "out of the box", on most Linux distros?

I hear a lot of news about different developments here on Phoronix but I'm confused about the bigger picture context.

Yes you are :),

-ati was not in its death throes ever.. at the time AMD were working on opening specs, Alex, before joining AMD (using some work I'd started) had just redesigned -ati to use randr 1.2, this is why the release gap between 6.6.3 and 6.8.0 was so long.

-ati can't die, what would support all the other cards. -ati isn't all reverse engineered, large parts of it were from ATI before the r300, and a lot of the fixes for r300 came out of helpers in ATI. Only the PCI Express and 3D stuff was ever really reverse engineered.

In any case the future from Red Hat's POV is kernel modesetting, and really for us that will obsolete -radeonhd vs -ati. Currently radeonhd is porting accel code from radeon, with kernel modesetting removing everything but the accel code I don't see the reason to offer the same accel code in two packages.

Dave.

[some-guy]

I'm completely confused.

AFAIK *before* AMDTI disclosed details about their cards, there was one open source driver trying to support ATI cards through reverse engineering. Is this correct? Was this the xf86-video-ati driver?
-ati was made to support R100-R200 cards with spec provided under NDA, it was then extended to support R300-400 cards with some reverse engineering.

-avivo was aimed to reverse engineer the R500 cards, after AMD announced it's plans the avivo driver was discontinued.

AFAIK *after* AMDTI disclosed details abou their cards, xf86-video-radeonhd was likely to take over the open source ATI driver mantle and xf86-video-ati was in it's death throes.
No, -randonhd was supposed to support R500+ cards while -ati supported R100-R400 cards

What has changed? Why didn't xf86-video-ati die? What is the point in confusing end users with two open source drivers for (largely) the same hardware? Where is xf86-video-radeonhd at the moment?
I wasn't supposed to die. The radeonhd devs wanted to hard-code all of the registers, -ati disagreed and decided to support R500+ with using the AtomBIOS(makes adding support much easier and quicker)

If radeonhd stuck with AMD's original plan, we wouldn't have this problem, though they are switching to it now...

[agd5f]

-ati was made to support R100-R200 cards with spec provided under NDA, it was then extended to support R300-400 cards with some reverse engineering.

There was no reverse engineering in -ati for r3xx-r4xx cards. ati provided the patches directly. They only thing that was reverse engineered was r3xx/r4xx 3D support in mesa.

[NaterGator]

I modified the X11 gentoo overlay to build this branch. That's all I had to do.



Beautiful. No tearing with Xv. Thank you Alex! Looking forward to more improvements like this; IMO this is a huge one.

It seems, however, that you can't redirect output to the textured adapter. Once the video starts passing through compiz, tearing resumes. I assume this is because compiz can't vsync properly, but I don't know.

[agd5f]

I modified the X11 gentoo overlay to build this branch. That's all I had to do.



Beautiful. No tearing with Xv. Thank you Alex! Looking forward to more improvements like this; IMO this is a huge one.

It seems, however, that you can't redirect output to the textured adapter. Once the video starts passing through compiz, tearing resumes. I assume this is because compiz can't vsync properly, but I don't know.

You'll probably need to enable the vsync option in compiz (done via OpenGL).

[merkurial]

I have vsync enabled in compiz and tried the tear free acceleration commit on top of the master branch since I couldn't get your vsync_accel branch to compile. For me the video is smoother without the patch than with it. Again, this is with compiz, I did not try with it.

For those who were asking what was needed to get 3d working, you need mesa 7.1_rc3, xorg 1.4.99.905, xorg-video-ati-6.9.0 and x11-drm from git. That's all. With that you can use compiz and Textured Video, also simultaneously, with no flickering while playing video on a Xv window!! Impressive to say the least!!

[NaterGator]

Alex,

Any work on this still happening? I was quite excited to see work on cutting down on tearing. I'd be more than happy to help/facilitate in any way possible; I'd just love to see reliable vsync brought to open source ATI drivers.

[agd5f]

Your best bet for now is to use compiz with OpenGL vsync.

general vsynced acceleration will require infrastructural changes. See comment #24.

[NaterGator]

Alex, I understand. I guess I'm just hopeful that this is an issue developers have intentions to work on when the time is right.

The reason I say "reliable vsync brought to open source ATI drivers" is because I do use compiz and have enabled OpenGL vsync, but I still get tearing like mad (it's pretty clear OpenGL vsync isn't working, for whatever reason). I'd say the only place I don't get tearing is via Xv that hasn't passed through the textured adapter, and that only leaves me with tear free video. :(

That is, however, another thread. Thanks for the quick reply as well.
-----Nate

[oblidor]

I get tearing when I watch DVDs in a large window. Have to reduce the size not to get it. Is there some option I need to set in xorg.conf that can help as this thread claims it is fixed now?

[bridgman]

When you say "fixed", do you mean "fixed while running the experimental patch mentioned in the article" ? The regular drivers will still exhibit tearing.

[oblidor]

When you say "fixed", do you mean "fixed while running the experimental patch mentioned in the article" ? The regular drivers will still exhibit tearing.

Ah. I only read the thread not the article. I thought it was about that the driver was fixed. I'm running git version of the ati driver...

[duby229]

Yes you are :),

-ati was not in its death throes ever.. at the time AMD were working on opening specs, Alex, before joining AMD (using some work I'd started) had just redesigned -ati to use randr 1.2, this is why the release gap between 6.6.3 and 6.8.0 was so long.

-ati can't die, what would support all the other cards. -ati isn't all reverse engineered, large parts of it were from ATI before the r300, and a lot of the fixes for r300 came out of helpers in ATI. Only the PCI Express and 3D stuff was ever really reverse engineered.

In any case the future from Red Hat's POV is kernel modesetting, and really for us that will obsolete -radeonhd vs -ati. Currently radeonhd is porting accel code from radeon, with kernel modesetting removing everything but the accel code I don't see the reason to offer the same accel code in two packages.

Dave.

So the question in that case is why was any time ever wasted on radeonhd? I mean it's clear that all the time they used developing modesetting code was a total waste and they are just recycling the acceleration code from radeon anyway, why didnt they just get together with the radeon devs in the first place? The simple fact of the matter is that radeonhd has no innovations. None. The modesetting code is worthless, and they havent contributed jack shit to the acceleration code.

Honestly I've never seen more resources wasted then I've seen with the development of drivers for ATi's hardware.

You've got a complete waste of a closed source driver, several completely wasted open source drivers... At this point the only driver that is worth anything is radeon, and it's so incomplete as to be almost worthless. but the kicker of it all is that if everybody had been working together from the beginning it could have been stable by now.

I blame ATi for it personally. I know damn well it was ATi that pushed Novell into the radeonhd project. I know damn well it was ATi that killed the avivo project. I know damn well it was ATi that killed the original closed driver. And I know damn well that it was ATi that started on the new closed driver.

Personally I think it is well past time for some consolidation. The kernel devs need to tell ATi to shove the closed driver where the sun dont shine. And ATI needs to tell novell to suck on an orange. Or better yet to find a pole, sit on it, and spin around endlessly.....

I've seen at least a dozen highly skilled hackers bitch and moan that there isnt enough qualified developers working on linux graphics drivers to make a big difference, but at the same time, they are all wasting there efforts working against each other.... It's a shame.. A damn dirty shame...

[ivanovic]

Uhm, there is a very good reason for radeonhd:

It works better than radeon. That is at least on my system with a hd3850 it is working better. Do not ask me why, that is just the case. Somehow I think that the default for everything till r5xx will be xf86-video-ati where for everything later on it will likely be xf86-video-radeonhd.

No idea how long it will really take till kernel mode setting will be available. This might as well take many more months. Until then for r6xx+ hardware, radeonhd is IMO preferable.

[bugmenot]

So the question in that case is why was any time ever wasted on radeonhd?
There are reasons why there is radeonhd, search the forums. E.g. http://www.phoronix.com/forums/showpost.php?p=40414&postcount=13.

[some-guy]

So the question in that case is why was any time ever wasted on radeonhd?
At that point (when radeonhd was started, and radeon didn't support r500+), radeon was meant to support r100-r400 cards, radeonhd was meant to support r500+, the problem came with atombios. radeonhd said that using the registers diretly is the better (and free-er) solution, but amd wanted radeonhd to use atombios first, then after it was implemented properly, use registers. But radeonhd still used the registers, so radeon started implementing r500+ support with atombios.

Then radeon went ahead in support, and started implementing things faster that radeonhd.

[duby229]

Uhm, there is a very good reason for radeonhd:

It works better than radeon. That is at least on my system with a hd3850 it is working better. Do not ask me why, that is just the case. Somehow I think that the default for everything till r5xx will be xf86-video-ati where for everything later on it will likely be xf86-video-radeonhd.

No idea how long it will really take till kernel mode setting will be available. This might as well take many more months. Until then for r6xx+ hardware, radeonhd is IMO preferable.

I understand that some people believe that radeonhd has some unexplainable, almost religious value.. It's a shame, but there is nothing I can do about it. So let me ask you what makes radeonhd preferable? They switched over to using atombios, and are recycling the acceleration code from radeon anyway... Radeon is more mature, and offers more functionality. So what -exactly- makes radeonhd preferable?

I'm sorry, I've tried, but I just cant see anything more then a waste of valuable time and effort.

[duby229]

At that point (when radeonhd was started, and radeon didn't support r500+), radeon was meant to support r100-r400 cards, radeonhd was meant to support r500+, the problem came with atombios. radeonhd said that using the registers diretly is the better (and free-er) solution, but amd wanted radeonhd to use atombios first, then after it was implemented properly, use registers. But radeonhd still used the registers, so radeon started implementing r500+ support with atombios.

Then radeon went ahead in support, and started implementing things faster that radeonhd.

So things didnt work out the way things had been envisioned. I can understand that, But in that case why is it still being funded and developed? Once it was discovered that radeon was capable of doing what needed done faster and cheaper than radeonhd, why wasnt it killed right then and there?

The radeonhd devs are fully capable and highly qualified, so why arent they working on radeon right now?

[some-guy]

The radeonhd devs are fully capable and highly qualified, so why arent they working on radeon right now?
FWIK, mostly disagreements on how things should be done.

I'm sure one will be dropped once kms is finished, because at that time the main differences will be 2D and video acceleration, which imho isn't enough reason to have 2 (2D) camps.

BTW, both projects use the same drm and 3D code...

[Extreme Coder]

Or even better, they could merge :P One can dream..
What matters most to me right now is the 3D, I can't wait till they move to Gallium, but I think that won't be till next year..

[duby229]

Or even better, they could merge :P One can dream..
What matters most to me right now is the 3D, I can't wait till they move to Gallium, but I think that won't be till next year..

Nope definitely not till next year.. My biggest complaint is that I cant get the damn xserver to build from git for some damn reason, and nobody seems to have any explanation why. I've asked on this forum several times. I've asked on gentoo's forums several times. I've asked on several mailing lists several times, and so far I've got nothing from nobody. I mean do I actually have to wait until next year?

ATi, do you actually expect people to wait that long? DRI as it is now may not be all that great, but at least the infrastructure is there. Why not get everybody together and stabilize the drivers for DRI right now, and then start working on DRI2? That way we could have a stable and reliable driver now --AND-- later...

Makes sense to me...... But of course lets all vote for change:rolleyes:...

[TechMage89]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.

Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.

[Extreme Coder]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.
Well, AFAIK, OpenGL 2 comes with Gallium.

[TechMage89]

Well, AFAIK, OpenGL 2 comes with Gallium.

Only because the devs don't think it's worth the effort to continue to pour effort into advancing a depreciated driver framework (well technically Gallium isn't a framework, but I'm not sure what exactly to call it)

[duby229]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.

Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.

How about working on making it stable so that those of us who dont know that voodoo you do can take advantage of it as well....

And what exactly has native modesetting done? Dalay after delay, it;s over a year now with no progress, and and has been dropped in favor of the same kind of modesetting that radeon already does...

Once modesetting is moved into the kernel and radeonhd is using radeons acceleration code what then will have been the point? I guess I just dont understand the religion...

[TechMage89]

AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.

[duby229]

AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.

Like I said, I guess I just dont understand the religion.

If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.

[Extreme Coder]

Like I said, I guess I just dont understand the religion.

If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.
What chance are you talking about that later on won't exist?

[duby229]

What chance are you talking about that later on won't exist?

ATi has no real competition right now... nvidia doesnt have an x86 chip, so once fusion hits the market, nvidia will be relying solely on discreet products to get by.. And Intel doesnt have anything compelling on the graphics side.

However this is only a short term condition.... The rumormill has it that nvidia is working on designing an architecture that will be compatible with X86 on the front end, which puts them back in the game... And Intel will have Larrabee...

The only thing nVidia needs is a top end CPU, and the only thing Intel needs is a top end GPU, and they are both working on exactly those things.....

[TechMage89]

Duby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.

[grantek]

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.
Maybe for the current generation of cards, but that won't be true forever. As open-source developers come up with graphics/memory management/etc. optimisations, a technology base will develop that will feed from and into other graphics drivers, ideas will be shared, and performance will increase exponentially. By that point, closed-source developers will be re-implementing some ideas from the open-source community (or straight-out stealing code if they dare), and future hardware will be developed with [then-]exisiting technology in mind. If companies like AMD are bringing out technologies like Fusion, they need to support it out of the box on open OSes, so they'll need to continue commissioning open drivers, which will also drive the closed-source driver closer the open one(s).

At least that's the way I'd like it to happen. There's currently a lot of value in fglrx, and there will be for a while, but I'd gladly take a substantial performance hit for an open driver - I already am taking a minor performance hit running Windows games on Wine/Cedega anyway :)

[MrCooper]

The sync-to-vblank technique used by compiz can't work reliably with indirect rendering. Until we can use compiz with direct rendering with DRI2, the only hope there is to set the vblank_mode option to 2 or 3 in /etc/drirc. Unfortunately, that doesn't help in the non-fullscreen case either, as compiz uses the GLX_MESA_copy_sub_buffer extension instead of buffer swaps for incremental screen updates. And in the fullscreen case, compiz can unredirect the window anyway, in which case the following applies:

It should be relatively straightforward to integrate the XVideo part of Alex's patch into mainline xf86-video-ati Git. Only the normal 2D rendering part isn't ready.

[some-guy]

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.
While it may have features that OSS doesn't(because of drm, etc), OSS will imo get ahead. Many games use OpenGL 2 and GLSL, this is where mesa is behind, once gallium comes, GL2 and 3 as well as the GLSL's should be implemented, then it should be very close

[duby229]

Duby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.

I simply cant agree with you... I've taken the liberty of bolding one thing that you've said... So with that bolded statement in ming, again what was the point in radeonhd? You keep bringing up native modesetting as it's only saving grace except that you've already admitted that it was a watse of time due to KMS. I'm sorry but I just cant find anything redeeming. Nothing.

I think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....

So far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee... Like I said the window of opportunity is closing and ATi needs to get on the ball while they still can...

[bridgman]

So with that bolded statement in ming, again what was the point in radeonhd? You keep bringing up native modesetting as it's only saving grace except that you've already admitted that it was a watse of time due to KMS. I'm sorry but I just cant find anything redeeming. Nothing.

There are some things about radeonhd which are more important to Novell than to Red Hat, at least for a while. One example is that the radeon modesetting code is built natively around randr1.2, which makes the code nice and simple but means that xservers without randr1.2 are not directly supported. A lot of Novell enterprise distros in use today are running pre-Randr1.2 x servers while the corresponding Red Hat distros are running slightly newer X servers and are happy with only RandR1.2-based modesetting. My understanding is that it should be possible to pick up the RandR1.2 code from the server and patch it into the driver but the Novell devs had a strong preference for supporting the pre-RandR1.2 API directly.

There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.

I think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....

Depends on whether you are talking about 2D or 3D. On the 3D side the performance is pretty close already, and fglrx will probably continue to be faster than the open source driver because the API is common with other OSes and we can take advantage of a common code base across OSes.

On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.

So far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee...

I don't understand this - can you fill me in ? Our open source drivers run on our high end workstation cards, and once the memory management work catches up with the recent change from TTM to GEM I expect the new framework features will arrive more or less simultaneously on Radeon parts. Most of the performance difference between fglrx and open source drivers today is a function of framework features and driver architecture, but those are all being addressed.

Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?

The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.

That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.

[duby229]

Hi Bridgeman,

Sorry for the late response. After the weekend I came to work only to discover a massive outbreak of Antivirus 2008 XP... Oy...

Anyhoo....

There are some things about radeonhd which are more important to Novell than to Red Hat, at least for a while. One example is that the radeon modesetting code is built natively around randr1.2, which makes the code nice and simple but means that xservers without randr1.2 are not directly supported. A lot of Novell enterprise distros in use today are running pre-Randr1.2 x servers while the corresponding Red Hat distros are running slightly newer X servers and are happy with only RandR1.2-based modesetting. My understanding is that it should be possible to pick up the RandR1.2 code from the server and patch it into the driver but the Novell devs had a strong preference for supporting the pre-RandR1.2 API directly.

There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.


Which is --exactly-- why ATi needs to tell Novell to suck on an orange. Time and time again Novel does something totally retarded specifically for the sole reason of holding our industry back. This is just one more example in a massive string of others. I could go on and on about just how corrupted Novell really is, and show where most of there money comes from, but I'll choose to keep this short and sweet. I'll just say this... Novells earnings reports are damn near illegal.


They definitely have a financial bias against the linux community, and it is because of this that it is no coincidence that they chose to buy Suse, and has since then proceeded to obfuscate, and divert resources industry wide across a huge range of projects..


Depends on whether you are talking about 2D or 3D. On the 3D side the performance is pretty close already, and fglrx will probably continue to be faster than the open source driver because the API is common with other OSes and we can take advantage of a common code base across OSes.

On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.


3D, 2D, Video. It's all the same.... Buggy, slow, incompatable, unstable, incomplete, not standards compliant, etc, etc, etc. The list goes on and on and on.. I'll just put it like this, Play Doom3 on Windows, and then on Linux using fglrx on the same hardware, nuff said...... This is not a suggestion, you should actually do it. See for yourself.


I don't understand this - can you fill me in ? Our open source drivers run on our high end workstation cards, and once the memory management work catches up with the recent change from TTM to GEM I expect the new framework features will arrive more or less simultaneously on Radeon parts. Most of the performance difference between fglrx and open source drivers today is a function of framework features and driver architecture, but those are all being addressed.

Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?


Absolutely yes. Beyond the shadow of any doubt. 100% Clearly and obviously. The problem is that while the radeonhd devs were busy accomplishing -nothing- the memory management code could have been worked on by more people. While ATi was busy writing a buggy, incomplete, unstable, non-compliant, propriatary driver they could have been working on releasing documentation faster, or helping the xserver devs, or helping the mesa devs... Hell any one of a 100 other things far more productive.

And then there are ATi's excuses for why they cant support crossfire on the open drivers, or proper video decode on the open drivers, or etc, etc, etc... The list again goes on and on and on again. Tell me why ATi couldnt use an industry standards interconnect? And becouse they chose to implement a proprietary interconnect shouldnt they be obligated to document it?


The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.

That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.

No this is exactly what the point is. fglrx performance sucks, radeonhd is a waste, and radeon isnt anywhere near what it could be, and should be by now. ATi has spread itself too thin and --must-- consolidate.

Once Intel gets a top end competitor out on a stable feature complete open source driver, ATi is done. It has no future from that point forward.

[TechMage89]

uhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.

It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

[mityukov]

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

It's very interesting point... "With all the $$ spent for hacking of Games' not-driver-friendly code", someone said..

But those games were all for Windows, isn't it? Or, there were some $$ spent for "hacking" Linux games?


Also, from what I heard, the closed driver is full of "Win blobs", adjusted via some hacking/work-arounds for working in X environment. While the OSS drivers were originally designed for X.

Yes, it supports more visuals, higher versions of OGL, etc, where OSS drivers fall back to software rendering. But I would doubt this is close to Windows version even in 3D...

[duby229]

uhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.

It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

I fully understand and appreciate that, however fglrx's 3d performance is --not-- up to par with windows. Not even 75%. I fully expect that in the coming year or two mesa will at least hit 75% of the single GPU performance. On the other hand the open driver is responsible for 2d acceleration, and video acceleration, and in both cases the open driver is wholly inadequate and yet it still outperforms the closed driver...

Why is that? How is it that a handful of open source developers that are are working against each other, can produce an incomplete, underdeveloped driver on an infrastructure that was designed for Intels inferior hardware? And get this, even under these extreme limitations,they still annihilate ATi's closed driver in almost every metric.

And I never said that ATi is holding the market back, but I did say that Novell is...ATi on the other hand for some reason that only they seem to know, thinks that a closed driver on an otherwise completely open platform is somehow, someway a good idea.... It may not be deliberate sabotage on ATi's part, but it certainly is stupid to the extreme.

[bridgman]

In most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.

re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.

On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.

Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.

The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.

[duby229]

In most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.

re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.

On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.

Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.

The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.

I understand your position as a public face for ATi, and I appreciate it very much. We need more people like you in this industry for sure, but I really dont think that you are being at all realistic. I think your views are so far off base right now that they likely arent representative of the majority. I think you give ATi a much greater role in the open source community then they deserve. And you portray the closed driver as some sort of "requirement" I think your out of touch with reality, and are getting deeper and deeper in delusions that are driven by marketing.

Heres what I would like to see for once... I would like ATi to admit that they havent been allocating the resources that there products deserve. That the closed driver has no place in an open source environment. And to tell Novell just where they can shove it.

Stop defending your worthless closed driver, and get your open source developers on the same team.

[Dieter]

>> The closed driver was primarily aimed at the workstation market,
>> where most of the users come from the Unix world and so open
>> source is really not a concern.

Sorry, closed drivers *are* a problem, not just in linux, but also
with real Unix.

> NVidia doesn't seem to be having problems with a closed driver;

Nvidia's closed drivers have bugs, including security holes.
Nvidia's closed drivers cause data loss.

Without source code these problems are effectively impossible to fix.

Binary-only drivers are unacceptable. It doesn't matter if
the chip is AMD/ATI or Nvidia or VIA or whoever's. It doesn't
matter if the OS is linux or real Unix or Plan-9 or whatever.

Binary-only drivers are unacceptable. PERIOD. How many times do
we have to say it?

> Stop defending your worthless closed driver, and get your open
> source developers on the same team.

Better yet, stop wasting resources on worthless closed driver(s),
pick one FLOSS driver (*) and have everyone work on that driver.

(*) If it makes sense for, say, R200 and R600 to have different
drivers, that's fine. I mean one driver per generation.

[yotambien]

Sorry, closed drivers *are* a problem, not just in linux, but also with real Unix.

Well, the vast majority of companies out there use Windows and closed drivers and the Earth hasn't apparently exploded yet. Focusing on Nvidia, it can't be that bad when folks are using their tools and hardware to do molecular mechanics and weather simulations among others.

Nvidia's closed drivers have bugs, including security holes.

Of course, because free drivers are also bug free.

Nvidia's closed drivers cause data loss.

This is simply not true. Even if it was, it would have nothing to do with them being closed.

Without source code these problems are effectively impossible to fix.

You mean efectively impossible to fix by somebody outside their party. Nothing impedes them to fix their bugs, and the proof is that they do.

Binary-only drivers are unacceptable. PERIOD. How many times do we have to say it?

It's not how many times and how loud you say it. If you don't back up your position with an argument of some sort it basically goes nowhere. Even if you do it might be possible (marginally) that your interests do not equal, say, AMD's interests.

Stop defending your worthless closed driver, and get your open source developers on the same team.

Their 'worthless closed driver' is the only way many people has to play games at any half decent frame rate, or to run some 3D applications at its full power (*). Is fglrx crap? In my experience, yes; but wiping it out as suggested before is non sense. Fortunately for AMD's stakeholders, their guys know better than following the advice posted at some random forum.

You still haven't got that the open source drivers are not going to catch up with the closed driver in terms of 3D performance. No matter they themselves said it here, the mantra goes on and on. I have the feeling that some of this open source loving (I'm not pointing at you two, guys) comes more from the frustration that fglrx has brought to many linux users than to anything else.


(*) I can't run properly VMD with the open source drivers, and couldn't run Gtkradiant at all until some months ago. Given that I count with three fingers the number of 3D apps I use, the percentage is rather bad (_in my case_).

[rbmorse]

Better yet, stop wasting resources on worthless closed driver(s),
pick one FLOSS driver (*) and have everyone work on that driver.

I don't think that's something ATI controls. They contribute to the radeohHD effort, but it's run by Novell. I'm not sure what ATI's relationship is with "radeon" outside of moral support and possibly some technical assistance.

I'm sure ATI has some influence, but I doubt John or anyone else at ATI is in a position to call one of the open-source driver teams and tell them to cease what they're doing and just work on the other project. ATI might suggest that happen...ATI might have already suggested that happen, but I suspect the personal and theological divides are still too great and ATI cannot force it to happen. And, probably shouldn't, all things considered.

I'm very sure John isn't in a position to make the case to his management that they need to quit working on FGLRX and devote those resources to the open driver. Because like it or not, there's a butt-load of revenue tied to the CAD/Workstation market and almost zero revenue potential in gaming on Linux, which is what you want to see developed.

I'm as sorry as anyone else that Radeon/FGLRX doesn't work any better than it does with games, but I understand why it's not job #1.

FireGL/FGLRX is a pretty good solution for the CAD/Technical workstation segment. That's one area were a lot of people are betting it's going to be possible to make money with Linux-based solutions. It's a (comparatively) huge market and there are a lot of seats at stake. Have you priced a FireGL card, recently?

Look at what happened at SIGGRAPH this year. The Khronos Group threw the gamers under the bus (again) in favor of the development track pushed by the CAD/Workstation faction. When you look at who's funding Khronos that's no surprise, and it's pretty clear as to who's going to control the development of OpenGL for the forseeable future. I don't think they care much about wobbly windows. Or accelerated 3D.

That said, I do think ATI is coming around to the realization that even though there isn't much direct revenue to be had from Desktop Linux it's still something they ought to do better at. Pride if nothing else. And I think they decided to go open-source because it's a perfect approach for what they need to do...it doesn't cost much and what costs there are get split with others. ATI won't incur any support or maintenance liability and that is an important consideration if you don't expect the product to generate any revenue.

The drawbacks are what we see, of course.

[Dieter]

>> Well, the vast majority of companies out there use Windows
>> and closed drivers and the Earth hasn't apparently exploded yet.

Lots of people do lots of stupid things and the Earth hasn't
exploded. But the Earth would be a much better place to live
if people made better choices.

>>> Nvidia's closed drivers have bugs, including security holes.

>> Of course, because free drivers are also bug free.

Compare OpenBSD's security record with ms-virus-server's.

>>> Nvidia's closed drivers cause data loss.

>> This is simply not true.

What, if something hasn't happened to you personally, you think
it hasn't happened to anyone?

>> Even if it was, it would have nothing to
>> do with them being closed.

The inability for users to fix it has everything to do with
not having source.

>> Their 'worthless closed driver' is the only way many people has
>> to play games at any half decent frame rate

If you think that playing games is more important than security and
data integrity you can expect a very bad experience in your future.

>> You still haven't got that the open source drivers are not going
>> to catch up with the closed driver in terms of 3D performance.

Personally, I don't expect to need *any* 3D performance in
the foreseeable future.

> almost zero revenue potential in gaming on Linux, which is what
> you want to see developed

I don't run linux, I run real Unix. I couldn't care less about
silly 3D gaming. What makes you think I care about gaming on linux?

> Have you priced a FireGL card, recently?

Not the GL, but the "FirePro V3700 will cost a mere $99 USD"
http://www.phoronix.com/scan.php?page=news_item&px=NjY0NA

> ATI is coming around to the realization that even though there
> isn't much direct revenue to be had from Desktop Linux it's
> still something they ought to do better at

There is more to revenue than direct revenue. There is more to
FLOSS than just linux. There are more markets than just CAD
workstations and desktop. Big markets.

[yotambien]

>>> Nvidia's closed drivers have bugs, including security holes.

>> Of course, because free drivers are also bug free.


Compare OpenBSD's security record with ms-virus-server's.


That's one example (from which I don't have and you haven't given any numbers, anyway). I'm sure you could come up with others pointing to the opposite direction and they would all still mean nothing, for just examples they are. But if we want to play this game, _my experience_ is that many open source applications are rather buggy. I use and enjoy them, but I'm not blind.


Nvidia's closed drivers cause data loss.

This is simply not true.
What, if something hasn't happened to you personally, you think it hasn't happened to anyone?

Definitely not, for the same reason that you don't think that what's happened to you must have happened to everybody else. To be honest, I get your point, but you'll admit that saying "Nvidia close drivers cause data loss" is a bit categorical and missleading.

>> Even if it was, it would have nothing to
>> do with them being closed.

The inability for users to fix it has everything to do with
not having source.

Sorry, users don't fix anything. Under a positive ligth, they use the software and report problems to developers. Under a negative one, they complain without having a clue. That there are sources out there doesn't mean that somebody is going to hack the hell out of them to bring the ultimate product to the masses; even less in a timely manner.

If you think that playing games is more important than security and
data integrity you can expect a very bad experience in your future. Personally, I don't expect to need *any* 3D performance in
the foreseeable future.

Of course I don't think so, and my 3D needs are very modest too. That's why I run the oss driver most of the time, because it works (*). When time ago Bridgman explained the strategy of having a decent, more or less feature complete oss driver and an optimised, fine tuned closed one I thought "bollocks". My first reaction was the typical defensive position. Then I realised that I was already doing exactly that, picking what best suits me according to my needs.

Oss developers are constantly adding more features and improving their drivers, while AMD's released the docs for their cards. I'm not sure what else is wanted. Sure, if you want it _here_ and you want it _now_ and under the conditions that _you_ happen to prefer, you're gonna get frustrated no matter what.



(*)Being rather busy at the moment I haven't play at all for a good while, meaning no fglrx. My laptop's uptime had never been this high.

[duby229]

I don't think that's something ATI controls. They contribute to the radeohHD effort, but it's run by Novell. I'm not sure what ATI's relationship is with "radeon" outside of moral support and possibly some technical assistance.

I'm sure ATI has some influence, but I doubt John or anyone else at ATI is in a position to call one of the open-source driver teams and tell them to cease what they're doing and just work on the other project. ATI might suggest that happen...ATI might have already suggested that happen, but I suspect the personal and theological divides are still too great and ATI cannot force it to happen. And, probably shouldn't, all things considered.

I'm very sure John isn't in a position to make the case to his management that they need to quit working on FGLRX and devote those resources to the open driver. Because like it or not, there's a butt-load of revenue tied to the CAD/Workstation market and almost zero revenue potential in gaming on Linux, which is what you want to see developed.

I'm as sorry as anyone else that Radeon/FGLRX doesn't work any better than it does with games, but I understand why it's not job #1.

FireGL/FGLRX is a pretty good solution for the CAD/Technical workstation segment. That's one area were a lot of people are betting it's going to be possible to make money with Linux-based solutions. It's a (comparatively) huge market and there are a lot of seats at stake. Have you priced a FireGL card, recently?

Look at what happened at SIGGRAPH this year. The Khronos Group threw the gamers under the bus (again) in favor of the development track pushed by the CAD/Workstation faction. When you look at who's funding Khronos that's no surprise, and it's pretty clear as to who's going to control the development of OpenGL for the forseeable future. I don't think they care much about wobbly windows. Or accelerated 3D.

That said, I do think ATI is coming around to the realization that even though there isn't much direct revenue to be had from Desktop Linux it's still something they ought to do better at. Pride if nothing else. And I think they decided to go open-source because it's a perfect approach for what they need to do...it doesn't cost much and what costs there are get split with others. ATI won't incur any support or maintenance liability and that is an important consideration if you don't expect the product to generate any revenue.

The drawbacks are what we see, of course.


Your position is one that I just cant understand... You seem to think that the closed driver is required for this market but in --reality-- a stable and feature complete open driver would serve far better...

Your reasoning for forcing an unstable, buggy, slow, non-standard closed driver on us in totally unacceptable. It has no weight, and is an elaborate excuse at it's finest.

[mityukov]

Your position is one that I just cant understand... You seem to think that the closed driver is required for this market but in --reality-- a stable and feature complete open driver would serve far better...

I don't think somebody thinks differently. But you should take into account that ATI/AMD has it's own interests.

For instance, they reasonably don't like to open code, used in their proprietary driver, though that could the best option for the driver's development -- far more people could participate in its improving, in this case.

On the other side, there are many "tricks", to which AMD spent lot of money, and every competitor will then be able to use their code for free.

What does it means in business? I'm not economist, but "lower expenses" is a key factor in competing. If AMD allows, let say NVidia, to save some money/time on some research and development, to which ATI already spent -- it's bad for ATI (and for us, actually, as for consumers of production from two hardly competing manufacturers).

I personally think, blaming ATI for that is not rational..

[rbmorse]

Your position is one that I just cant understand... You seem to think that the closed driver is required for this market but in --reality-- a stable and feature complete open driver would serve far better...

Your reasoning for forcing an unstable, buggy, slow, non-standard closed driver on us in totally unacceptable. It has no weight, and is an elaborate excuse at it's finest.

I'm not saying this is what I want, but I do believe it is what is happening. I'm not the one who thinks that a closed driver is required...but ATI and nVidia seem to think so.

I happen to agree that a stable and feature complete open driver is desirable, but I don't know who's going to pay for the full-scale development effort you want. Certainly not the Linux gaming crowd.

Frankly, all I see from you is a bunch of rude sanctimony based upon a profoundly ignorant view of the industry and some bad religious dogma.

My view may in fact be "unacceptable", but let's see a business case that might influence the businesses involved to change their thinking.

[Dieter]

>>>>> Nvidia's closed drivers have bugs, including security holes.
>>>> Of course, because free drivers are also bug free.
>>> Compare OpenBSD's security record with ms-virus-server's.
>> That's one example (from which I don't have and you haven't
>> given any numbers, anyway).

"Only two remote holes in the default install, in more than 10 years!"
http://www.openbsd.org/

I don't have numbers for ms-virus-server, MAXFLOAT is only 3.40282346638528860e+38

>> To be honest, I get your point, but you'll admit that saying "Nvidia close
>> drivers cause data loss" is a bit categorical and missleading.

New version: Nvidia's closed drivers sometimes cause data loss.
Better?

>> Sorry, users don't fix anything.

Some users do. I have fixed bugs in lots of programs.
Users that don't have the skills to fix bugs themselves can
ask for help, or hire someone to fix it for them. None of
those options are available if the user doesn't have source.

------

> I happen to agree that a stable and feature complete open driver is
> desirable, but I don't know who's going to pay for the full-scale
> development effort you want.

Take the resources used for closed driver and apply them to FLOSS
driver.

> My view may in fact be "unacceptable", but let's see a business case
> that might influence the businesses involved to change their thinking.

Good quality FLOSS driver -> more sales.

[stan]

On the other side, there are many "tricks", to which AMD spent lot of money, and every competitor will then be able to use their code for free.

You can still open up your code while ensuring that you're not giving your competitors a free ride: it's called CopyLeft (http://www.fsf.org/licensing/essays/copyleft.html). If AMD wants to prevent NVIDIA from stealing code, AMD should license the driver GPLv3 so that if NVIDIA uses the code they'll have to open up their entire code base. Any improvement that NVIDIA makes would be then available for AMD to incorporate.


it's bad for ATI (and for us, actually, as for consumers of production from two hardly competing manufacturers).

Sorry, but that's baloney! GNOME, KDE, XFCE, Enlightenment etc are all open source, yet they still compete fiercely with each other for developers and users.

[bridgman]

You can still open up your code while ensuring that you're not giving your competitors a free ride: it's called CopyLeft (http://www.fsf.org/licensing/essays/copyleft.html). If AMD wants to prevent NVIDIA from stealing code, AMD should license the driver GPLv3 so that if NVIDIA uses the code they'll have to open up their entire code base. Any improvement that NVIDIA makes would be then available for AMD to incorporate.

We looked into this, but GPL and similar licenses only protect the actual code, not the ideas incorporated in the code. It's the ideas and the knowledge that the ideas work which are most expensive to develop -- GPL only prevents a verbatim copy of the code, and that would not make sense for a competitor anyways.

[Dieter]

> We looked into this, but GPL and similar licenses only
> protect the actual code, not the ideas incorporated in the code.

You could patent it.

It doesn't matter how wonderful the secret technology is.
Without FLOSS drivers I can't use it.
If I can't use it I'm not going to buy your chips.

[duby229]

I'm not saying this is what I want, but I do believe it is what is happening. I'm not the one who thinks that a closed driver is required...but ATI and nVidia seem to think so.

I happen to agree that a stable and feature complete open driver is desirable, but I don't know who's going to pay for the full-scale development effort you want. Certainly not the Linux gaming crowd.

Frankly, all I see from you is a bunch of rude sanctimony based upon a profoundly ignorant view of the industry and some bad religious dogma.

My view may in fact be "unacceptable", but let's see a business case that might influence the businesses involved to change their thinking.

Ok, Alright cool by me. I misunderstood, and I apologize.

[duby229]

We looked into this, but GPL and similar licenses only protect the actual code, not the ideas incorporated in the code. It's the ideas and the knowledge that the ideas work which are most expensive to develop -- GPL only prevents a verbatim copy of the code, and that would not make sense for a competitor anyways.

Which is exactly the point. Implementation doesnt really matter. If someone can do something better then you, the GPL actually allows him to do it. If you dont understand the fundemental idea's behind the GPL, then you need to pick it up and read it. Maybe several times.

[grantek]

My belief, coming from someone with at least a minimal knowledge of computer security, is that "the enemy" (eg. nVidia/Intel) has an infinite number of smart techs with an infinite number of electron microscopes and an infinite number of disassemblers figuring out the clever hack that gave you a better generation of cards at a given time. I see compiling the driver as nothing more than simple obfuscation of the code, that doesn't really get in the way of "the enemy" figuring it out, and hurts no one except those that aren't "the enemy".

I know there's complexities like real-world economics of reverse engineering and the advantage a few weeks of development time can give you, and I can imagine the niggling feeling inside the back of an exec's mind that doing this also keeps entry barriers high enough to keep small companies from being a threat, but in the end it harms everyone, and I'll always be pissed off about it.

I have faith that the open-source driver(s) will be good enough for my needs though (graphics acceleration without any DRM nonsense), and I have hope that the proprietary driver will eventually go away, but I understand that the only way that'll happen is if things like DRM go away, and that's a much bigger battle...

Actually, just thinking about the way Digital Rights/Digital Restrictions Management is one of the reasons the proprietary driver exists, what I'd like to see are open-source GPU drivers, developed by the GPU manufacturers, that are so high-performance, prevalent, and well documented/abstracted that it pushes the onus of writing separate "drm drivers" to the content providers themselves :)

[duby229]

Once the DMCA gets pulled, and it will get pulled, we will see DRM fall flat on it's face... Already most major content industries are rapidly shrinking because of it, and when the DMCA gets pulled then they'll be in a situation that will turn those industries on there heads...

The cool thing though is that when it's all done the content industries will come out of it better then they are today. Modern and efficient with digital distribution that isnt severely limited. I cant wait for the DMCA to get pulled. I think it is the very best thing that can happen, and it will happen.

[bridgman]

Which is exactly the point. Implementation doesnt really matter. If someone can do something better then you, the GPL actually allows him to do it.

Right, and that's exactly what a company in a competitive market wants to prevent.

If you dont understand the fundemental idea's behind the GPL, then you need to pick it up and read it. Maybe several times.

Trust me, I have read all the versions more times than I even want to admit. Every stinkin' version is longer and harder to read than the one before :mad:

[drag]

We looked into this, but GPL and similar licenses only protect the actual code, not the ideas incorporated in the code. It's the ideas and the knowledge that the ideas work which are most expensive to develop -- GPL only prevents a verbatim copy of the code, and that would not make sense for a competitor anyways.

Well no copyright license prevents people from copying your ideas or reading the code and duplicating it's functionality. It's outside the scope of copyright law (and this is very much done on purpose).

Even if the GPL said 'you can not use this code to learn anything' it would be unenforcible. Nobody's ideas are sacred from duplication under any sort of law, even patent law. (which is designed for the express purpose of forcing companies to divulge inventions to the general public, not hide them).

You can try to obsufcate the code by releasing it in machine code only form, but there isn't anything that will prevent people from disassembling it or reverse engineering it. Reverse engineering hardware and software is still perfectly legal, and is in fact necessary for a technology driven society.

-----------------

Oh well there isn't any point in telling you this, of course. It's not like it's your decision or likely that anybody would listen to you. You guys are still doing tremendous work and I look forward to my next hardware purchase with that in mind.

----------------

Someday everybody in the hardware world will will realize that refusing to disclose how hardware work to their own paying customers is not a effective way to compete in the market place.

[duby229]

Which is exactly the point. Implementation doesnt really matter. If someone can do something better then you, the GPL actually allows him to do it. If you dont understand the fundemental idea's behind the GPL, then you need to pick it up and read it. Maybe several times.

Right, and that's exactly what a company in a competitive market wants to prevent.

Trust me, I have read all the versions more times than I even want to admit. Every stinkin' version is longer and harder to read than the one before :mad:

So what your saying is that ATi wants to prevent better implementations? That sure is what it sounds like... OK, so now motives and allegiances have been revealed. As they say the truth will out.

[yotambien]

So what your saying is that ATi wants to prevent better implementations? That sure is what it sounds like... OK, so now motives and allegiances have been revealed. As they say the truth will out.

That sure sounds like a nice way of being a demagogue. Here, I'll fix it for you:

"So what you're saying is that ATI wants to prevent better implementations BY THE COMPETITORS?"

It's taking some time, but I'm sure we'll manage to unveil AMD and reveal to the world that they actually are not a charity.

[bridgman]

So what your saying is that ATi wants to prevent better implementations? That sure is what it sounds like... OK, so now motives and allegiances have been revealed. As they say the truth will out.

News Flash !! AMD wants to benefit from its R&D investment to be better than it`s competitors !! Customers are shocked !!

Seriously, companies don`t want to give away all their secrets and let competitors combine them with their technology (which they don`t share) to beat them in the marketplace. There are some business models where being fully open source works, of course, typically where a big chunk of your revenue comes from support and services.

In our case we are opening up programming information wherever possible but don`t plan to open source the entire proprietary driver, although we have opened some bits like the atom bios parser and will probably continue to do so in the future).

I hope this is not a surprise. If it is, I`m sorry I didn`t make it clear in the past. Protecting competitive technology is one of a number of reasons why proprietary drivers still have a place in some industries.

[duby229]

That sure sounds like a nice way of being a demagogue. Here, I'll fix it for you:



It's taking some time, but I'm sure we'll manage to unveil AMD and reveal to the world that they actually are not a charity.

Tell me how the GPL does that? Go ahead. I dare you.

[duby229]

News Flash !! AMD wants to benefit from its R&D investment to be better than it`s competitors !! Customers are shocked !!

Seriously, companies don`t want to give away all their secrets and let competitors combine them with theirtechnology (which they don`t share) to beat them in the marketplace. There are some business models where being fully open source works, of course, typically where a big chunk of your revenue comes from support and services.

In our case we are opening up programming information wherever possible but don`t plan to open source the entire proprietary driver, although we have opened some bits like the atom bios parser and will probably continue to do so in the future).

I hope this is not a surprise. If it is, I`m sorry I didn`t make it clear in the past. Protecting competitive technology is one of a number of reasons why proprietary drivers still have a place in some industries.

News Flash!! Standards bodies and tech consortiums exist!! Standardized coherency and communications protocols already defined and working!! AMD customers shocked that they arent utilizing this wealth of open knowledge!!

Can you again try to tell me why AMD "requires" a closed driver? Is it artificial limitations imposed by ATi? Why cant they use standardized technologies that already exist? And where existing technologies arent adequate why cant they work within these standards bodies and consortiums to create something that is?

[bridgman]

I don't think I'm getting your point here. Standards bodies cover the external stuff, eg. programming APIs (OpenGL), wire protocols (X), etc, not the internal implementations.

To the best of my knowledge there are no standards committees covering the internals of a graphics driver, just the externals and APIs (OpenGL, OpenCL etc.). Standards committees do not cover the internal implementation and that's what a proprietary driver can (somewhat) protect.

[duby229]

I don't think I'm getting your point here. Standards bodies cover the external stuff, eg. programming APIs (OpenGL), wire protocols (X), etc, not the internal implementations.

To the best of my knowledge there are no standards committees covering the internals of a graphics driver, just the externals and APIs (OpenGL, OpenCL etc.). Standards committees do not cover the internal implementation and that's what a proprietary driver can (somewhat) protect.

I think you know exactly what I'm talking about... In the end the goal is to provide compatibility with that external stuff. You can design your hardware however you want to design it, and patent that hardware to protect your intellectual property. You can then put a firmware layer over the hardware to obfuscate it, and to make programming easier. From there what else is there to protect?

And dont give that "firmware isnt open enough" crap. We have a Walmart in my town, and right out in front by the big sliding doors there exists three concrete "stoppers" They are about 4 feet tall, and about 8 inches wide in diameter. Tell Novell to find one and sit on it, then once it's tightly entrenched in there ass, have them spin around on it over, and over, and over, and over, and over, and over, and over, and over.......

[grantek]

OK, now you've lost even me...
- AMD has AtomBIOS, and are commissioning open drivers to suit. They're not ready yet, so if that's what you're annoyed about, I've no problem with you venting :)
- AMD have released/are releasing register-level specs for GPUs, which to me is as low-level an "API" as you can get before documenting sub-instruction algorithms
- AMD may have fancy sub-instruction algorithm stuff that they know how to optimise, but isn't apparent from register-level specs. This is one gap I hope will close in the future, because obfuscation is not ideal but may sorta work in the real world. This is also an area where I'd pick an open driver over a few more FPS, but to some it's a critical difference worth millions.
- AMD has bowed to market forces demanding proprietary crap like Blu-ray DRM, which also keeps the proprietary driver around, and I (like many other Linux users) don't care as long as there's an open API to offload video decoding tasks to hardware designed for it.

[TechMage89]

duby, you have descended into the realm of highly obnoxious.

ATI is providing everything needed to make fully OpenGL complaint open source drivers. They are holding nothing back from us in terms of making fully working, standards compliant drivers.

However, ATI is a company, and they need to make money. In the high-performance graphics industry, special algorithms that give you a slight performance advantage are worth millions. ATI has such algorithms in their closed-source driver so they can be competitive with NVIDIA. However, you wouldn't expect them to just give out those algorithms, worth millions due to the performance advantage they give, so anyone could use them, would you?

Like it or not, proprietary software/algorithms/techniques/whatever exist, and the R&D needed to produce them needs to be recouped, in this case, by giving ATI cards a performance advantage.

If you truly believe that open-source software is superior, duby, you have to believe that the open-source community can come up with even better algorithms to make the open-source driver performance-competitive with the proprietary driver. If that happens, you can be sure there will be a shift in thinking.

Edit: duby your last post totally lost me. What in the world are you talking about?

[NaterGator]

:(
http://img149.imageshack.us/img149/3/threaddirectionyq3.gif

This thread needs to be bifurcated into it's original context and all the squabbling about drivers can go elsewhere.

[oblidor]

News Flash !! AMD wants to benefit from its R&D investment to be better than it`s competitors !! Customers are shocked !!

Seriously, companies don`t want to give away all their secrets and let competitors combine them with their technology (which they don`t share) to beat them in the marketplace. There are some business models where being fully open source works, of course, typically where a big chunk of your revenue comes from support and services.

In our case we are opening up programming information wherever possible but don`t plan to open source the entire proprietary driver, although we have opened some bits like the atom bios parser and will probably continue to do so in the future).

I hope this is not a surprise. If it is, I`m sorry I didn`t make it clear in the past. Protecting competitive technology is one of a number of reasons why proprietary drivers still have a place in some industries.

Fine, just make workable closed source drivers as good as or better than NVIDIA. I have ordered for the 3rd time a ATI card as it seemed we would get good open source drivers. I guess it was a mistake as I have never gotten fglrx to work on my cards. I'll see, if fglrx doesn't work with the 4870 either, I'll return the card and go NVIDIA...

I'm not a charity either handing out money to ATI for useless hardware! :mad:

[oblidor]

However, ATI is a company, and they need to make money. In the high-performance graphics industry, special algorithms that give you a slight performance advantage are worth millions. ATI has such algorithms in their closed-source driver so they can be competitive with NVIDIA. However, you wouldn't expect them to just give out those algorithms, worth millions due to the performance advantage they give, so anyone could use them, would you?

Like it or not, proprietary software/algorithms/techniques/whatever exist, and the R&D needed to produce them needs to be recouped, in this case, by giving ATI cards a performance advantage.


Yes, it is a company depending primarily on that people buy their hardware. For this to happen they need 1) to have working drivers that are as good or better than the competition 2) have better hardware/price than the competition.

However, these algorithms do they also cover tearfree display, 2D
acceleration and proper video playback?

I don't care about +/- 10 fps in some game as long as the card can work properly for what people use them mostly for (gamers not included ;) )

I have no problem with closed source drivers as long as they work. I have a x1650 pro card in my old PC. This card would have been paperweight, had it not been for the open source ati driver. The fglrx driver (I have tested every release) hangs my computer as soon as the driver is used.

So, when they now say they will support linux and also open source is it real? Or just a gimmick to sell more cards to the linux crowd? :confused: