fglrx sucks...

[madman2k]

...at supporting the Xorg 2D/ modesetting stack, like EXA and RandR, but it is superior to anything OSS related when it comes to 3D, since it can rely on patented technology like S3TC.
And now there is kernel based modesetting which I imagine is hard to do with closed source driver since it lives in the GPL kernel.

So I am wondering whether it is possible to split out the 3D component of fglrx and make it compatible with MESA, so it basically is only a libGL replacement.
This way all drivers would share the 2D stack and also get the same improvements there, while you could optionally use the faster 3D component.

Since there are many savvy people running around here, I throw it in here.

[duby229]

Variations on this idea have been proposed many times by some very smart people on this forum...

The answer depends on who you talk to.

If your speaking with an open source advocate, he'll tell you that it isnt possible because the 3D driver needs direct access to the command processor. But providing that access to a closed driver would taint the kernel. ATI gets around this right now by using a small GPL wrapper that interfaces with the kernel, and then they use this to communicate with there closed code. Using your idea and some of the variations on it that configuration wont be possible.

On the other hand if your speaking to a proponent of closed source development, they'll try to make the argument that it cannot be protected. In this kind of environment it becomes impossible to ensure the data that is being processed is protected. (aka restricted) (Think DRM) The other side of the closed source argument is that it becomes impossible to protect intellectual property.

In the end neither side is willing to make a compromise so what we end up with is a whole lot of redundant code and a hell of a lot of wasted time, money, and talent....

And guess whos paying for most of this waste? That's right ATi...

[bridgman]

If your speaking with an open source advocate, he'll tell you that it isnt possible because the 3D driver needs direct access to the command processor. But providing that access to a closed driver would taint the kernel. ATI gets around this right now by using a small GPL wrapper that interfaces with the kernel, and then they use this to communicate with there closed code. Using your idea and some of the variations on it that configuration wont be possible.

Actually the shim code is not GPL, it's just delivered in source form.

The main obstacle to running a closed 3d stack over an open kernel driver is that part of the "secret sauce" for making the 3d stack run fast is memory manager code. The fglrx driver has always been primarily a workstation driver (although we are ramping up support of consumer functionality and distros now) and competitive advantage is a big deal there.

Memory management in the open source kernel drivers is much less mature although there has been some good progress over the last year. Until open source memory management advances to the point where we can use the open APIs for memory management and still get performance leadership for workstation it doesn't make business sense to have our 3d driver run over an open kernel driver (unless we are willing to dump all of our proprietary mm code into the open driver, which we don't plan to do).

On the other hand if your speaking to a proponent of closed source development, they'll try to make the argument that it cannot be protected. In this kind of environment it becomes impossible to ensure the data that is being processed is protected. (aka restricted) (Think DRM) The other side of the closed source argument is that it becomes impossible to protect intellectual property.

Yep. This is the 800 pound gorilla in the room. If it turns out that we need to provide a DRM solution for Linux in order to compete in the evolving market then practicaly speaking that means we need to stay with a closed kernel driver. I don't know how that is going to turn out (don't think anyone does), although it's a great topic for starting a fight in the bar after any open source conference :D

This is probably the single most polarizing issue in the Linux world, in the sense that users and developers fall totally into one camp or the other with very little overlap. The one exception is the folks who want the benefits that come with increased market share but don't want to have to deal with things like DRM which (today) seem to be necessary to get that market share.

I don't know exactly how Apple is handling this but there may be some clues there. My guess is that they are running with a closed kernel but I don't know for sure.

In the end neither side is willing to make a compromise so what we end up with is a whole lot of redundant code and a hell of a lot of wasted time, money, and talent.... And guess whos paying for most of this waste? That's right ATi...

It's actually the same people on both sides. If you can reliably predict what will happen with DRM and Linux in the future then we can make more concrete plans today. In the meantime the discussion is academic because if we ported the closed 3d driver over the current kernel drivers performance would go done significantly and you would all be lining up with tomatoes anyways.

The open source kernel drivers will get better with time, and the closed source driver will probably become more open with time, and I expect this will all shake out nicely. In the meantime we need the closed driver for workstation business (unless someone wants to donate a big chunk of money to make up for the loss of business there) so our only option to avoid duplication is to cut the open source effort and I don't think anyone wants to see that.

[duby229]

I really dont want to get into a DRM debate, but I dont think Apple should be taken as an example. I'm of the opinion that Apple violated everything sacred and revered when they released OSX..... And the BSD retards let them do it.... I personally will never, ever again use another BSD based product ever for as long as I live, becouse clearly that group has no moral values.

Actually the shim code is not GPL, it's just delivered in source form.

So it is a GPL violation?

It's actually the same people on both sides. If you can reliably predict what will happen with DRM and Linux in the future then we can make more concrete plans today. In the meantime the discussion is academic because if we ported the closed 3d driver over the current kernel drivers performance would go done significantly and you would all be lining up with tomatoes anyways.

The open source kernel drivers will get better with time, and the closed source driver will probably become more open with time, and I expect this will all shake out nicely. In the meantime we need the closed driver for workstation business (unless someone wants to donate a big chunk of money to make up for the loss of business there) so our only option to avoid duplication is to cut the open source effort and I don't think anyone wants to see that.


You keep claiming that you'd lose business, but you've got no evidence to back up that claim. I'll argue that you'd significantly increase business due to the increase in stability, and uptime.

I've already said this, but I'll rehash it here... Intel is innovating in the linux graphics market... Not you.... Your superior hardware is already playing second fiddle. Intel is the one that is innovating GEM, not you. Intel is the one pioneering KMS, not you. Intel is the one contributing most to DRI2, not you. And the list goes on and on and on.

If you actually wanted to compete, you'd drop your closed driver, you'd tell Novell to fuck off, and you'd put 100% effort into developing a cohesive and well developed ecosystem for open source development. Right now you dont have that and it doesnt look like you ever will.

I'm glad that your developing open source drivers, but they are built on top of Intels innovations for there inferior hardware. As such your drivers will never be as good as they should be. And it really is truly a shame.

[bridgman]

I really dont want to get into a DRM debate, but I dont think Apple should be taken as an example. I'm of the opinion that Apple violated everything sacred and revered when they released OSX..... And the BSD retards let them do it.... I personally will never, ever again use another BSD based product ever for as long as I live, becouse clearly that group has no moral values.

OK, so maybe looking to Apple was a bad idea. Noted :D

So it is a GPL violation?

No -- a GPL violation would be taking GPL code and either publishing it under a less free license or using it to build binaries and not providing the source code. There is no legal problem AFAIK with having non-GPL code in the kernel as long as you don't claim to be GPL if you are not. If the code does not identify itself as GPL then the kernel devs are free to restrict access to certain functions deemed as "internal" but so far that seems to have been managed pretty fairly.

Not sure if there is any non-GPL code pushed into the kernel tree itself or if it is all in loadable modules; one more thing for me to learn ;(

You keep claiming that you'd lose business, but you've got no evidence to back up that claim. I'll argue that you'd significantly increase business due to the increase in stability, and uptime.

If we didn't also lose a big chunk of performance at the same time that is possible, but I don't see customers paying the same price for something that runs 20-30% slower. If you follow the IRC chatter (today in radeon is a good example) you'll see some clear signs that the current open source driver is not the foundation we want to be building on.

I've already said this, but I'll rehash it here... Intel is innovating in the linux graphics market... Not you.... Your superior hardware is already playing second fiddle. Intel is the one that is innovating GEM, not you. Intel is the one pioneering KMS, not you. Intel is the one contributing most to DRI2, not you. And the list goes on and on and on.

Sorry, isn't DRI2 more of a Red Hat initiative (Kristian H) ?

http://hoegsberg.blogspot.com/

It's also RH people doing most of the kernel modesetting work AFAIK.

http://airlied.livejournal.com/61839.html

If you follow the ML and IRC discussions GEM is seeming to be too specific to Intel HW to be a good solution for our parts, so Dave (RH) is working on a combination of GEM and TTM (Tungsten) APIs for ATI/AMD graphics. I think this is mentioned in the previous link.

Keith has been pioneering things in X for a long time and hopefully he will keep doing so. He did it at HP, at SuSE, and now he is doing it at Intel. That said, the innovations come from a lot of different companies not just Intel. I don't want to sound like I'm downplaying Intel's contribution here -- they have done a lot of good things for open source -- but if you dig deeper you may find that you are crediting Intel for work and leadership done by other people, including both independent developers and the teams at Tungsten, Red Hat and Novell.

If you actually wanted to compete, you'd drop your closed driver, you'd tell Novell to fuck off, and you'd put 100% effort into developing a cohesive and well developed ecosystem for open source development. Right now you dont have that and it doesnt look like you ever will.

Again, if someone wants to put up the money in case we lose workstation business the way we everyone expects, we can talk. The open source kernel drivers are simply not ready for commercial workstation use today.

I'm glad that your developing open source drivers, but they are built on top of Intels innovations for there inferior hardware. As such your drivers will never be as good as they should be. And it really is truly a shame.

I think we covered this above. The open source community is driven by innovations from a number of people and companies, not just Intel. Dig a little deeper, OK ?

[RealNC]

What would it mean for AMD to put their proprietary memory manager into the kernel tree and GPL it? Are you afraid that others would steal it? The GPL does not allow them to do that. If they would rip the memory manager they would have to open up their code too.

I'll just quote Greg Kroah-Hartman here:


The very good side effects of having your driver in the main kernel tree are:

The quality of the driver will rise as the maintenance costs (to the original developer) will decrease.
Other developers will add features to your driver.
Other people will find and fix bugs in your driver.
Other people will find tuning opportunities in your driver.
Other people will update the driver for you when external interface changes require it.
The driver automatically gets shipped in all Linux distributions without having to ask the distros to add it.

As Linux supports a larger number of different devices "out of the box" than any other operating system, and it supports these devices on more different processor architectures than any other operating system, this proven type of development model must be doing something right :)

From what you said till now, it seems that AMD does not want the open source devs to come up with a high-performance memory manager because that would cost you the competitive edge. They want a low-performing MM in the kernel while only their closed MM is fast. The conclusion is that for AMD the open source devs are an enemy.

A high-performing, in-tree MM will eventually happen. So why not go ahead right now and put the code in there anyway.

[madman2k]

@bridgman:
still intel is showing the way in the respect, that they started the work on a high-performance memory manager, while AMD is still too afraid of their competitive advantage. This argument is basically as absurd as in the opening the specs discussion.

its sad to hear that there actually is no technical reason for such a merge. but obviously the mind change for a fully open source strategy takes a while.

[duby229]

Hello again. Sorry for the late response guys... I had an issue to take care of...

If we didn't also lose a big chunk of performance at the same time that is possible, but I don't see customers paying the same price for something that runs 20-30% slower. If you follow the IRC chatter (today in radeon is a good example) you'll see some clear signs that the current open source driver is not the foundation we want to be building on.

And it is entirely ATi's own fault. They'll never get the foundation that is right to build on if they dont allocate the required resources to make it. Instead you've got your resources split between just a handfull of guys that they have on there own payroll, a few guys at Redhat and a few guys at Novell.. I'm of the opinion that you guys need to tell Novell to suck on an orange, and then hire the guys that they get rid of. You can deny it, but I know for 100% fact that your investing a huge sum of resources providing Novell with both money and documentation. Reallocate that waste into something more productive. Novell over the last year has already proven that they dont have what it takes. Any further investment is a total waste of time and money. Drop them now while you still can.

I understand that mode setting will be in the kernel soon so that code will be moved out of the DDX driver. The only other thing the DDX needs to worry about is 2D and Video, which I understand the 2D acceleration code is pretty solid in radeon. Video needs to be rewritten but that is strictly 100% due to ATi wasting even more time and money on DRM. Which is such a massive waste that there is no other rival. If ATi had developed proper video hardware from the beginning there wouldnt be any problem with video acceleration.

Then the mesa driver, which I understand still needs alot of work, but this is exactly why you need to get on the ball and allocate the resources needed to get it up to par. If you had started it at full speed this time last year instead of dragging your feet and wasting time with Novell, and wasting even more time porting your new propriatary code base from windows, and then even more time and money trying to work around your flawed DRM laden video hardware,it would already be done.

At this point ATi is totally screwed once Intel gets a top end competitor.

[crumja]

I agree. ATI seems to be investing their resources unwisely. Novell's radeonhd project, which uses devs paid by ATI, has so far been slow and behind the curve because of their insistence on programming registers directly. Radeon, with Alex Deucher and David Airlie, has done a much better job of supporting the new hardware and adding cool features (DRI2, KMS, EXA perf, 3D, etc.) even though they're not being paid by ATI (afaik).

That begs the question - why not just scrap the radeonhd project and focus all the devs' energies on radeon?

As for an improved MM, Keith Packard and GEM are leading the way for Intel in terms of beefing up perf. Maybe the radeon guys can get their driver using GEM and/or TTM soon. Also, Intel is doing work on underlying improvements in Mesa. 7.1 should be out soon and that has a bunch of cool features and hopefully perf improvements planned. The work on Mesa will spill over and benefit all drivers.

[duby229]

with Alex Deucher and David Airlie, has done a much better job


I agree they are doing a much better job... I think that Alex is payed by redhat with funding from ATi, and Dave is payed directly by ATi as an AMD employee.

So in addition to that they have a group at Novell that is also being paid by AT, and the folks that work directly for ATi writing the linux code for the closed driver that isnt covered by the common code. In addition they are still paying developers to port as much of the windows driver as possible to the common code base. They still have to do a bunch of video acceleration, and crossfire, and some 2d acceleration. And by the looks of how unstable fglrx is, probably a lot more...

I'm not sure what the exact number is, but I'd take a guess that ATi is paying somewhere round about 30 full time employees, working on these various projects and 26 of them are entirely wasting there talent. And all of them are highly skilled. Not many people are up on Linux graphics and driver development. So you know these guys are making a good buck.

[crumja]

http://www.csn.ul.ie/~airlied/ says David is an employee of redhat, though as I implied in my post, I have no knowledge of whether they are being indirectly financed by ATI/AMD.

From what I understand from past phoronix articles, ATI/AMD originally contracted Novell to develop radeonhd under NDA for the new cards while simultaneously releasing specs, though at a later date than the ones available to the devs. The guys from radeon then started to implement features using Atombios and the released specs and did so at a much faster pace.

Anyways, most of that is idle speculation, but you're definitely right in that it seems to be a major waste of resources. I don't see why we need two open-source drivers for the same cards. With that said, there have been some sharing of code as evidenced by the latest patches to hit radeonhd, which are taken from radeon. Also, it seems that the radeonhd devs have been under some pressure from AMD (http://www.phoronix.com/scan.php?page=article&item=radeonhd_atombios&num=1), possibly due to not providing good returns for the investment heh.

[madman2k]

and wasting even more time porting your new propriatary code base from windows, and then even more time and money trying to work around your flawed DRM laden video hardware,it would already be done.
I agree that with you that Ati has wasted time and money on funding radeonhd, but hey it was their first attempt on Open Source.
But I dont think they wasted their time on polishing fglrx. If there was not fglrx we would not be able to play any newer game even now, since the OSS graphics stack just sucks right now.
A friend of mine has an linux laptop with an intel chip and while its all cool as long you stick with 2D and simple 3D it totally breaks down when it comes to gaming. Many games dont even start, because there is this or that patented extension missing.

Then there is DRM, for which a closed source stack is a requirement. Although I dont need it its up to Ati deciding if its worth keeping fglrx just for that.

My initial idea was to use as much as possible of the OSS driver for fglrx, so the latter would get all the improvements like DRI2, KMS and EXA for free. This more work would be put in the OSS driver while we would as well keep the advantages of an closed source driver.

[bugmenot]

I agree that with you that Ati has wasted time and money on funding radeonhd [...]
Hm, I can't see why the money is wasted. radeon supports so many old models and it makes sense to start from a new base for only new chips. And afaik the radeon 3d support was only possible because they could use code from radeonhd. For me both projects make perfect sense. Radeonhd seems more stable to me, maybe even "cleaner", it runs perfectly here and I just hope to get 3d for my 780G onboard chip soon... :)
And what about the mac modells of graphic cards without atombios? I am happy that there is radeonhd. And even if radeon makes "cooler features", radeonhd can easyly adopt them and everyone is happy?

[duby229]

Anyways, most of that is idle speculation, but you're definitely right in that it seems to be a major waste of resources. I don't see why we need two open-source drivers for the same cards. With that said, there have been some sharing of code as evidenced by the latest patches to hit radeonhd, which are taken from radeon. Also, it seems that the radeonhd devs have been under some pressure from AMD (http://www.phoronix.com/scan.php?page=article&item=radeonhd_atombios&num=1), possibly due to not providing good returns for the investment heh.

So in the end what we end up with is two radeon drivers going by different names using the same code (And even more so after the mode setting code gets stripped out and put in the kernel.)....So what exactly is the point?

[duby229]

I have to split my responses up a little bit, but I just wanted to thank you so much for bringing up some very good points.

I agree that with you that Ati has wasted time and money on funding radeonhd, but hey it was their first attempt on Open Source.
But I dont think they wasted their time on polishing fglrx. If there was not fglrx we would not be able to play any newer game even now, since the OSS graphics stack just sucks right now.


That is not true at all. Right now the fglrx driver is plagued by instability. Across all product lines. Radeon is fairly stable. It works reliably and in some instances has feature support that fglrx doesnt have. The perfect example of that is Daves recent work on tearless video playback. Another example is seemless VT switching. Yet another example is better wine compatibility. fglrx does not have a single benefit over radeon. Not even a single one. The only problem with radeon is that ATi has --not-- allocated the required resources to get 3d support up to par, and they still have to work around there flawed video hardware due to DRM.


A friend of mine has an linux laptop with an intel chip and while its all cool as long you stick with 2D and simple 3D it totally breaks down when it comes to gaming. Many games dont even start, because there is this or that patented extension missing.


Again wrong. Intels open source graphics driver uses Mesa for its OpenGL implementation. And while yes Mesa is not the most modern OpenGL implementation it is new enough to run every single native linux game right now. You may have some problems with wine, but you'd get those same problems using any open source driver, and that is due entirely to the wine developers using opengl functions that arent available in mesa. Blame wine it is 100% there fault.


Then there is DRM, for which a closed source stack is a requirement. Although I dont need it its up to Ati deciding if its worth keeping fglrx just for that.


Sorry but this is again wrong. Lets take AACS for example. It is already cracked. You do not need any form of hardware based DRM to play back AACS restricted content. The only thing we are waiting for now is the proper playback support in open source players like mplayer, or xine-lib or ffmpeg. It's going to happen whether ATi or Hollywood likes it or not.... DRM will be cracked. And the DRM hardware will be worked around... Its totally inevitable and any resource devoted to DRM is a complete waste of time.


My initial idea was to use as much as possible of the OSS driver for fglrx, so the latter would get all the improvements like DRI2, KMS and EXA for free. This more work would be put in the OSS driver while we would as well keep the advantages of an closed source driver.

Which wont happen. I've explained why in my response to your opening post.

[bridgman]

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.

RealNC, you are completely missing the point with your comments about open source being the enemy. Our competitors are other hardware vendors, not other software developers -- it's just that writing code and making it public makes not only the code but the concepts and methods available to other hardware vendors. Intel is not in the high performance 3d space right now so they don't have as much to protect in that regard as ATI and NVidia. A year or two from now this will all be academic anyways since the open source memory management will have matured (probably with some help from us) enough that this will not be an issue.

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.

crumja, when you talk about "underlying improvements in Mesa" are you talking about Gallium ? Mesa 7.1 is pretty much locked and I'm not aware of any underlying changes there other than a lot of vendor-specific improvements for Intel, Radeon and Nouveau.

Bottom line, I find this whole thing puzzling and borderline offensive. A lot of the work on memory management over the last year or two was driven by Tungsten Graphics and Red Hat, not just Intel -- but you are completely ignoring their contributions in order to make a better argument to bash us with. Are you sure this is the right thing to do ?

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 ?

[crumja]

bridgman: Thanks for clarifying. I thought though that the recent news about r500 and rs690 support all featured the radeon driver.

As for the Mesa changes, I was referring to "Packard had mentioned that many performance improvements will be taking place from low-level chip optimizations to improving the quality of the Mesa project." from http://linux.chinaunix.net/news/2006-10-23/3000.shtml

Some questions: Since the hardware docs are out there, will the MM in the OSS drivers ever become as good as the one in fglrx?

[bridgman]

crumja: it gets confusing because most of the recent 5xx/690 announcements were related to 3d (mesa, drm) and those components are used by both radeon and radeonhd drivers. The problem was that until recently radeonhd didn't have all the code needed to fully use those 3d components so most of the development work was done with radeon.

The big deal about yesterday's merge to radeonhd master is that it puts both drivers on roughly equal footing when it comes to acceleration support. I think there are still a few differences (accelerated rotation comes to mind) but for the first time we are now able to do ongoing acceleration work in radeonhd almost as easily as in radeon, so this is kind of a big deal.

Memory management needs HW docs but the biggest challenge is that doing mm right is just a huge design task, since you are optimizing across a bunch of different clients, usage scenarios and CPU/GPU designs.

re: Mesa changes, now I understand. That is a 2006 article so many of those changes are already happening. Some of those are Intel initiatives, but a lot of different groups are contributing to improving the X/DRI framework. One important thing to understand is that when Keith talks about framework improvements those are not necessarily Intel projects. Keith was a leader in X development long before he joined Intel and one of his ongoing contributions is periodically providing a "big picture" view of where all the projects (some Intel, some not) are heading so that they can all stay in sync as much as possible. I doubt that even Keith would want you to think of all those as Intel projects.

re: will MM in open drivers ever become as good as in fglrx ? Probably, at least I expect it to get as good as fglrx is today. It's mostly the same issue as with the rest of the 3d stack -- the open source community has some really talented developers so the open stack will absolutely go as far as is possible with a relatively "clean" design. Once you get into performance optimizations for specific market segments though, that's where you start to see differentiation between open and closed source code since the open source devs have little interest in doing that kind of optimization work while it is a big part of what lets one HW vendor differentiate itself from the competition. The problem is that the optimizations are expensive to develop but easy to duplicate in another driver -- which is why there is a business argument for keeping them proprietary.

[SavageX]

Again wrong. Intels open source graphics driver uses Mesa for its OpenGL implementation. And while yes Mesa is not the most modern OpenGL implementation it is new enough to run every single native linux game right now.

Uh, actually Nexuiz is one native game which is troublesome on Mesa. Using open drivers I *can* play Nexuiz on e.g. a Radeon 9000 mobility (which doesn't support pixel shaders and stuff) with very low details and I assume by now Intel hardware may be on the same level of "OpenGL as it used to be eight years ago", but most likely it'll crash once you try to use some of the more advanced stuff done with GLSL. I have yet to see working, *reliable* GLSL (without segfaults here and then) on any open driver setup. This isn't just a matter of more eye-candy but also a matter of speed.

fglrx *does* offer something compared to the open drivers: A rather fast, mostly working and feature-complete 3D stack. Too bad the 2D stack is having its share of problems (video shouldn't be rocket science).

What I'd *love* to see of course are open drivers with fast, reliable and up-to-date 3D support - the 2D part apparently works rather good already (yay!) on most hardware. Up to the day this happens I'm mostly glad fglrx is still around to give me something usable for 3D.

Rest assure that binary blob won't stay long on my system once the open drivers catch up, though.

[RealNC]

RealNC, you are completely missing the point with your comments about open source being the enemy. Our competitors are other hardware vendors, not other software developers -- it's just that writing code and making it public makes not only the code but the concepts and methods available to other hardware vendors. Intel is not in the high performance 3d space right now so they don't have as much to protect in that regard as ATI and NVidia. A year or two from now this will all be academic anyways since the open source memory management will have matured (probably with some help from us) enough that this will not be an issue.
Hopefully. The original statement claimed that putting the existing but closed MM in the kernel is bad for ATI/AMD. The logical conclusion here is that you actually don't want a good open sourced MM to happen.

If you want a good MM in-kernel, why not putting it in there right now? If you don't want a good MM in-kernel because it's bad for business, why would you allow one to happen (in one year with help from you)?

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.
I simply don't believe that both ATI as well as NVidia have not already completely and thoroughly 101% reverse engineered each other's hardware by now :D

(Of course no one's going to admit that anyway.)

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 ?
Because we see things like this one: http://youtube.com/watch?v=_ImW0-MgR8I&fmt=18 and want to have this experience too! You're not giving it to us. Intel and NVidia does :p

Edit:
I *do* have all those effects active as we speak... with xf86-video-ati that is. Yes, on an R580. fglrx is completely non-suitable for a good working compiz fusion.

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

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

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

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


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 ;)

[RealNC]

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 ;)
OK, I've just installed Wine (1.1.0) and tried to run "Soft Shadows Benchmark 1.5.4". It won't run. Error: "Your hardware does not support OpenGL 2.0".

Notepad.exe runs fine :D

[legume]

and it doesn't seem possible to enable either vsync nor anisotropic filtering or anti-aliasing.

Kernel 2.6.26 (no way around it)

I didn't try when I had my rv530 in, but vsync and aniso may be possible with driconf.

You don't need kernel 2.6.26, you just need to build the drm modules from git against your configured kernel tree and copy them (drm.ko,radeon.ko) over to /lib/modules/2.6.X/kernel/drivers/char/drm/

I don't know exactly what you have to install/do to get enough of a kernel tree in place for a distro as I had a full kernel tree already - LFS.

Didn't try wine, etqw didn't work as it needs a higher OpenGL version.

Other games were OK for me, plenty of fps on an X1600pro - tested nexuiz,et and several other ioquake3 based games.

[RealNC]

I didn't try when I had my rv530 in, but vsync and aniso may be possible with driconf.

You don't need kernel 2.6.26, you just need to build the drm modules from git against your configured kernel tree and copy them (drm.ko,radeon.ko) over to /lib/modules/2.6.X/kernel/drivers/char/drm/

I don't know exactly what you have to install/do to get enough of a kernel tree in place for a distro as I had a full kernel tree already - LFS.
Thanks for the tip. I went back to 2.6.25 and installed the x11-drm package from Git. Everything went automatic (Gentoo rox :D)

vsync works now with OpenGL applications. But not with Compiz. I guess that's another issue entirely (AIGLX). Why on earth didn't the world go towards XGL, everything was working perfectly there :P I hope Linux folks will one day have a system where everything actually works. Before I die, that is.