fglrx sucks...

[duby229]

Hold on guys, everyone is running off in different directions here. Most of the work done on radeon in the last 6 months has been either fixes and improvements for older chips or adding new acceleration support that we couldn't do yet in radeonhd because dri support wasn't there yet -- and all that code is now in radeonhd as well. Alex works for AMD, Dave works for Red Hat btw, not the other way round.

The big initial win with radeon was last fall, because it already *had* a lot of code implemented for earlier chips and that code could be used with relatively minor changes for 5xx since the 2d block was the same. In hindsight we probably should have split between 5xx and 6xx rather than between 4xx and 5xx, but these are the things you learn over time.

Which has proven to be a massive mistake. Right now we have the benefit of hindsight which ATi didnt have at that point. OK I understand that. But then you live and learn. At this point the only good solution is to drop Novell right now before they put the open drivers even further behind. Novell has wasted enough of your time, not you need to tell then to suck on your nuggets.

GPL does nothing to protect the underlying IP, just the actual line-by-line code. The only thing that can protect the underlying IP is software patents, and even those are a relatively unsatisfactory solution.

Wow.... Just wow. Talk about profanity. I mean that is just about the most evil thing that plagues our industry, and here you are promoting it as if it is a good and required thing....

If Linux were the only OS in the world none of these discussions would be happening and we would probably be doing exactly what you expect. We need to make sure that opening up things for Linux does not hurt our ability to compete in those other OSes, where most of our sales are made. You guys ask us to understand your issues and needs and we try really hard to do that; why can't you do the same for us ?

You can either do it half-assed, or you could do it full-assed... Right now your efforts are less then ideal, and will probably never be complete. As it is right now your open source code will never really compete.. Sure it'll work OK for most people, but it'll never be really good. And it is entirely ATi's fault for not allocating the required resources for doing right the first time....

[bridgman]

Wow.... Just wow. Talk about profanity. I mean that is just about the most evil thing that plagues our industry, and here you are promoting it as if it is a good and required thing....

Sorry if I wasn't clear. I'm saying that closed source drivers give us a short term solution which is less objectionable than wrapping everything up in software patents.

You can either do it half-assed, or you could do it full-assed... Right now your efforts are less then ideal, and will probably never be complete. As it is right now your open source code will never really compete.. Sure it'll work OK for most people, but it'll never be really good. And it is entirely ATi's fault for not allocating the required resources for doing right the first time....

I have to admit I'm still not following you here. A lot of the cool advances in the Intel open source support were not written by Intel staff and those same people are now implementing the same functionality on Radeon parts.

In the early 2000's most of the X framework development was doing with ATI parts since they had the best documentation for open source development. For the last few years most of the framework development has happened on Intel parts because *they* were the best documented. Now there are two, maybe three vendors with good documentation and hopefully others will join in as well. This allows everything to move ahead faster.

We may compete on closed source drivers but there is less attempt to compete on the open source side than you might think. There is a generally accepted level of functionality, stability and performance that everyone agrees we need to reach and a lot of different groups are working to achieve that level on all hardware -- even NVidia.

It might be worth taking a look through the xorg project tree to get a better feeling for how *little* of the X/DRI stack is hardware-specific. I haven't counted, but if I had to guess I would say that maybe 5,000 lines of Mesa code are specific to a GPU, and maybe 10,000 (including the 5,000) are specific to ATI in general. This is out of >1 million lines of code in Mesa. The xorg tree is similar but the numbers are bigger -- but maybe 17 million lines of code, of which perhaps 50,000 is specific to ATI GPUs.

Maybe I'm wrong and Intel has some secret plan for world domination through competitive advantage in open source Linux graphics but that isn't what I have seen so far. What I have seen is a bunch of companies all trying to push the overall framework ahead as fast and far as possible, and working together much more than you think.

You win by participating in the common effort, not by doing something different from everyone else.

It is pretty rare to see something developed that only works for one vendor. GEM is probably the closest but even there I suspect the issue is that it is biased towards integrated graphics rather than to Intel products only -- and even there everyone agrees that the API has some nice improvements that are worth keeping even if that means the GEM API needs to be implemented over internals from something like TTM.

I hate sounding like I'm downplaying Intel's contributions, but you are crediting them with things that even the Intel folks would disagree with. I'm tempted to ask one of the Intel guys to come in and argue with you for a while, I need to go out and chop firewood

EDIT - it's raining; I'm back.

[DaedalusIcarus]

Just wanted to say:

1) The "bashing" obviously stems from not being able to utilise the ATI hardware to its fullest.
As a consumer, I look at these *beautiful* 4870's delivering near the same performance as a Nvidia 280 and costing just 60% of what such a card costs.
They're insanely good for their price and the image quality is superb, the catch though, is that I have to use Windows to get all this.

Now most consumers (me included) can't really discern things all that well, and it's hard to put the blame where it might belong. But from our perspective, it just *doesn't* work as well as the Nvidia offerings at the moment.

Argueing about intel is a completely different matter. I have a X3100 and while it's sweet for notebooks and compiz, it's worth NOTHING in games (my experience).


Anyway, that said, I just purchased a DeLL laptop with an ATI Mobile card. I'm aware your (mobile, at least) linux support isn't exactly stellar (in fact, do you even support the 3650 Mobile Radeon at all ? ), but I thought I'd support you none the less - besides, your chips don't seem to blow up like the Nvidia 84XX and 86XX mobile lines

Anyway. Hopefully you'll recognize that we don't spend our entire day reading up on who does what and therefore forgive us for our mistakes -- and hopefully you'll remember, that there's a lot of users out there eyeing you with increased interest and who are very happy about your recent steps toward improving the Linux ATI experience

[Extreme Coder]

I read all this and I'm wondering, which driver of the two (radeon/radeonhd) will be THE one to use in the future?
If both will have same 3D acceleration (which is the most important thing for me right now), and they will share lots of code (including the use of AtomBIOS) then I don't see why they can't merge or something..

do any of the two drivers support 3D on an X1650 Pro now anyway?

[RealNC]

do any of the two drivers support 3D on an X1650 Pro now anyway?

The radeon driver does for all R500 chips. I'm using it right now (xf86-video-ati from Git) with Compiz Fusion on an X1950XT.

[bridgman]

FYI as of last Friday's merge the radeonhd driver should have full 5xx support as well.

[Extreme Coder]

The radeon driver does for all R500 chips. I'm using it right now (xf86-video-ati from Git) with Compiz Fusion on an X1950XT.

And? How good is it?
I have a few requirements to be able to use it:
1) Be able to use Wine.
2) Decent performance in 3D, I'm not asking for the same performance as fglrx, but I'm asking for playable performance
3) Stable

[Melcar]

And? How good is it?
I have a few requirements to be able to use it:
1) Be able to use Wine.
2) Decent performance in 3D, I'm not asking for the same performance as fglrx, but I'm asking for playable performance
3) Stable

1) Most likely not

2) Every chip I have used (200M, 9600pro, 9800pro, x800gto) with radeon demonstrated a 50% performance deficit over fglrx (even more in some cases). I don't expect R5XX cards to fare any better.

3) If the cards I have used are any indication of the overall behavior of the driver, I would say stable as a rock (definitely better than fglrx)

[RealNC]

And? How good is it?

Well, 3D *looks* well. No screen corruption. Switching from X to a VT also seems very thorough.

There are a few problems though. Page flipping is not available (there's a performance hit without it) and it doesn't seem possible to enable either vsync nor anisotropic filtering or anti-aliasing.

I have a few requirements to be able to use it:
1) Be able to use Wine.

Didn't try

2) Decent performance in 3D, I'm not asking for the same performance as fglrx, but I'm asking for playable performance

Performance is not very good. I'd say about 60% to 70% of what fglrx is able to deliver.

3) Stable

On that one, at least on my system the radeon driver kicks fglrx's butt sky high. No crashes, no lockups, no screen corruption. It just works while fglrx doesn't.

I have hopes for this driver (and radeonhd since as bridgman mentioned it also got R500 support). Even though the support is labeled "experimental", it's more stable for me than fglrx (which is labeled "mature"). Setting it up will require you to use bleeding edge versions of various components though. Kernel 2.6.26 (no way around it), X.Org 1.4.99.06, Mesa 7.1_rc3 and also latest versions of things like libdri and other stuff pulled in by an X.Org update.

[Extreme Coder]

Well, 3D *looks* well. No screen corruption. Switching from X to a VT also seems very thorough.

There are a few problems though. Page flipping is not available (there's a performance hit without it) and it doesn't seem possible to enable either vsync nor anisotropic filtering or anti-aliasing.


Didn't try


Performance is not very good. I'd say about 60% to 70% of what fglrx is able to deliver.


On that one, at least on my system the radeon driver kicks fglrx's butt sky high. No crashes, no lockups, no screen corruption. It just works while fglrx doesn't.

I have hopes for this driver (and radeonhd since as bridgman mentioned it also got R500 support). Even though the support is labeled "experimental", it's more stable for me than fglrx (which is labeled "mature"). Setting it up will require you to use bleeding edge versions of various components though. Kernel 2.6.26 (no way around it), X.Org 1.4.99.06, Mesa 7.1_rc3 and also latest versions of things like libdri and other stuff pulled in by an X.Org update.

Hmm.. Sounds good, I'm OK with 60-70% performance right now, hopefully it will improve.
If anybody can confirm it working with Wine, I will have a go at installing it