asfdati = super reatrd driver retard crap retard retard retard

[deanjo]

So we can expect Plan 9 support with UVD next week bridgeman?

[rbmorse]

Yes, but it won't support Xv and video will still tear horizontally.

[duby229]

Sorry but you do not state one damn fact in there. You have an unsubstantiated opinion. Again novell has NOTHING to do with the blobs. That's all ATI. ATI has also fulfilled their end of a deal with the foss community by giving the documentation that was requested so that the FOSS community could develop on their own as PER THEIR REQUEST. So put substanciated FACT behind your claims instead of wild accusations based on your speculation. The foss community asked for documentation. They got it. Now go bitch at your favorite foss developer that said that documentation was all they needed.

Considering the first documentation drop was on Sept 12 of last year you have some pretty unrealistic goals (probably from having no driver development experience of your own) of them being able to have the level of support the RadeonHD drivers enjoy now if you think the same level of support could have been done 18 days.

Clearly your method does not work. The closed drivers are total junk. I think the op made that perfectly clear. However I totally disagree with the op that it is the developers fault... It is --NOT--

Now According to you, everything is just peachy the way it is. The problem is that you are wrong.

The facts are there are two sides here, the closed driver, and the open drivers. On the right hand, the closed driver sucks because ATi is -unwilling- to devote the resources needed to develop a closed driver successfully. Then on the left hand you've got Novell diverting scarce and valuable resources on the open drivers by wasting time and money developing dead end code paths.

Clearly niether of these methods are working, as is evidenced by the continuing lack of decent driver either way, closed or open... It's been moree then a year now and I see little progress being made by either camp. ATi --NEEDS-- to adopt a fully open development model. It's the only way they will ever get decent drivers on linux. The market is simply too small for a closed driver, and Novell has an agenda that is dictated to them by "another" company...

And speaking about documentation.... Well, lets just say that I applaud everyone involved, but uuummmm when was the HD3000 series launched? Where is the documentation? Actually, lets just forget about the most recent generation and go back to the last generation... When was the HD2000 series launched? And again where is the documentation? Hell lets even just totally forget about these last few recent generations and discuss video acceleration... Period... Where is the documentation?

Is ATi really fullfilling there end of the bargian? The answer is easily... Hell no.... Not even close.

[deanjo]

Clearly your method does not work. The closed drivers are total junk. I think the op made that perfectly clear. However I totally disagree with the op that it is the developers fault... It is --NOT--

Now According to you, everything is just peachy the way it is. The problem is that you are wrong.

The facts are there are two sides here, the closed driver, and the open drivers. On the right hand, the closed driver sucks because ATi is -unwilling- to devote the resources needed to develop a closed driver successfully. Then on the left hand you've got Novell diverting scarce and valuable resources on the open drivers by wasting time and money developing dead end code paths.

Clearly niether of these methods are working, as is evidenced by the continuing lack of decent driver either way, closed or open... It's been moree then a year now and I see little progress being made by either camp. ATi --NEEDS-- to adopt a fully open development model. It's the only way they will ever get decent drivers on linux. The market is simply too small for a closed driver, and Novell has an agenda that is dictated to them by "another" company...

And speaking about documentation.... Well, lets just say that I applaud everyone involved, but uuummmm when was the HD3000 series launched? Where is the documentation? Actually, lets just forget about the most recent generation and go back to the last generation... When was the HD2000 series launched? And again where is the documentation? Hell lets even just totally forget about these last few recent generations and discuss video acceleration... Period... Where is the documentation?

Is ATi really fullfilling there end of the bargian? The answer is easily... Hell no.... Not even close.

Why are you depending on novell for your FOSS driver? Why are you depending on them at all? You have documentation for up to the R500 but yet the FOSS drivers still can't perform up to the same level as the blobs. Again you have no idea about the resources and work that goes into documentation. Documentation takes more resources then actual coding of drivers as bad documentation leads to bad or useless implementation of code. Perhaps ATI should simply divide resources and funding up accordingly to marketshare. OK so that would be,~90% windows, 7-8% Mac OS and 2% for other OS's. But again, since your such an expert on writing of drivers, I do invite you to write new drivers from scratch and report back to us with your solution, in other words put up or shutup.

[bridgman]

I think I do actually understand duby229's points, even if I don't agree with all of them.

1. There is no question that we could move more quickly on open source drivers if we were not spending any resources on closed source drivers. The debatable point is whether we would be able to build and sustain a competitive advantage in high performance workstation graphics if we only had open source drivers (assuming our major competitor had closed drivers). My feeling is "no" but it is something we will continue to think about.

The non-obvious point is that shifting developers over from fglrx would not have made as much difference as one might hope, since adding more developers won't help with writing documentation, reviewing IP etc. I think you will find that doc releases are more or less keeping pace with development progress in the X/DRI community as a whole, although the obvious gap is that we could be running basic Xv and 3D on 6xx/7xx if the IP side had gone a bit faster.

2. The early development efforts did cost us time and cause more divisiveness in the community than any of us would have liked to see. If that divisiveness were to continue forever I think we would all be unhappy, but the reality here is that we do *not* control the open source development community and things like this *will* happen from time to time unless we take everything in house.

Would it have been easier to make fast initial progress in a conventional top-down management structure ? No question -- but that is not how we chose to approach open source. I think we end up with a stronger development community this way, even if it is kind of stressful for a while.

3. The 3D engine docs for 6xx/7xx are definitely taking longer than we had expected -- I wanted to see this out in June. Part of the delay is a result of time spent on other things (like dealing with development community conflicts) but also the DRM-related issues were worse than I expected and it took longer than expected to figure out how to get the engine running without a bazillion lines of proprietary driver code.

4. Duby229, the only place I disagree with your recent comments is "video acceleration" (presumably you mean decode acceleration ?). We never committed to deliver decode acceleration other than my statement that "I felt it was likely we would be able to open up the IDCT block, but that would happen after 6xx 3D". Nothing has changed there. I know everyone wants UVD, but I'm still saying "no but we will look at it, and UVD2 is more likely than UVD".

If decode acceleration were such a hot priority for the development community someone would have written an XvMC driver for 3xx-5xx, since all of the information for MC is already out there (it's done on the 3D engine even in our drivers) and since MC is still (AFAIK) the biggest single time-waster in the software decode path for both SD and HD standards. The reality is that all of the developers I know who *could* implement XvMC today don't see it as a real high priority compared to the things they are already working on.

[duby229]

Why are you depending on novell for your FOSS driver? Why are you depending on them at all? You have documentation for up to the R500 but yet the FOSS drivers still can't perform up to the same level as the blobs. Again you have no idea about the resources and work that goes into documentation. Documentation takes more resources then actual coding of drivers as bad documentation leads to bad or useless implementation of code. Perhaps ATI should simply divide resources and funding up accordingly to marketshare. OK so that would be,~90% windows, 7-8% Mac OS and 2% for other OS's. But again, since your such an expert on writing of drivers, I do invite you to write new drivers from scratch and report back to us with your solution, in other words put up or shutup.

Clearly you have no clue what your talking about. An open source development effort requires a community effort. Not one guy working for AMD developing radeon in his spare time. And certainly not Novell, with there clearly biased agenda,developing radeonhd independently behind closed doors using documentation that is currently under NDA.

It's not me that needs to put up or shut up, it's definitely ATi....

[duby229]

I think I do actually understand duby229's points, even if I don't agree with all of them.

1. There is no question that we could move more quickly on open source drivers if we were not spending any resources on closed source drivers. The debatable point is whether we would be able to build and sustain a competitive advantage in high performance workstation graphics if we only had open source drivers (assuming our major competitor had closed drivers). My feeling is "no" but it is something we will continue to think about.

The non-obvious point is that shifting developers over from fglrx would not have made as much difference as one might hope, since adding more developers won't help with writing documentation, reviewing IP etc. I think you will find that doc releases are more or less keeping pace with development progress in the X/DRI community as a whole, although the obvious gap is that we could be running basic Xv and 3D on 6xx/7xx if the IP side had gone a bit faster.

2. The early development efforts did cost us time and cause more divisiveness in the community than any of us would have liked to see. If that divisiveness were to continue forever I think we would all be unhappy, but the reality here is that we do *not* control the open source development community and things like this *will* happen from time to time unless we take everything in house.

Would it have been easier to make fast initial progress in a conventional top-down management structure ? No question -- but that is not how we chose to approach open source. I think we end up with a stronger development community this way, even if it is kind of stressful for a while.

3. The 3D engine docs for 6xx/7xx are definitely taking longer than we had expected -- I wanted to see this out in June. Part of the delay is a result of time spent on other things (like dealing with development community conflicts) but also the DRM-related issues were worse than I expected and it took longer than expected to figure out how to get the engine running without a bazillion lines of proprietary driver code.

4. Duby229, the only place I disagree with your recent comments is "video acceleration" (presumably you mean decode acceleration ?). We never committed to deliver decode acceleration other than my statement that "I felt it was likely we would be able to open up the IDCT block, but that would happen after 6xx 3D". Nothing has changed there. I know everyone wants UVD, but I'm still saying "no but we will look at it, and UVD2 is more likely than UVD".

If decode acceleration were such a hot priority for the development community someone would have written an XvMC driver for 3xx-5xx, since all of the information for MC is already out there (it's done on the 3D engine even in our drivers) and since MC is still (AFAIK) the biggest single time-waster in the software decode path for both SD and HD standards. The reality is that all of the developers I know who *could* implement XvMC today don't see it as a real high priority compared to the things they are already working on.

I'm glad that you've come to an understanding on some issues. That's all I ask. And as far as video decode,even if it was on the 3d engine I'd be perfectly happy. Of course I'd want it to be XV capable, but if it ran on the 3D engine to make it work, that'd be perfectly acceptable.

And as for your debatable point... Absolutely yes. The bottom line is that a stable open source driver is a whole lot better then a buggy unusable closed driver. And I'm 100% convinced that all of your customers will agree.

[deanjo]

Clearly you have no clue what your talking about. An open source development effort requires a community effort..

No it doesn't require it. There are plenty of 1 man FOSS projects out there. Does it help if the community aids? Yes it does. Which is EXACTLY the reason why FOSS should not be dependent on Novell's or ATI's efforts other then documentation. As Bridgeman pointed out, the MC documentation for the r300-500 has been out for quite some time now and still there is no implementation of it.

[duby229]

No it doesn't require it. There are plenty of 1 man FOSS projects out there. Does it help if the community aids? Yes it does. Which is EXACTLY the reason why FOSS should not be dependent on Novell's or ATI's efforts other then documentation. As Bridgeman pointed out, the MC documentation for the r300-500 has been out for quite some time now and still there is no implementation of it.

Not the size and complexity of a modern graphics driver. I dont think you fully understand what is involved. It's not just a few lines of code.... You got the DDX driver, the Mesa driver, and the DRI driver and each of these components have there own complexities. Developing a modern graphics driver requires a range of individuals, each with there own specialties. Everyone has a unique background....

It's because there isnt enough people.And that isnt there fault. It's Novell and ATi's fault. Stop trying to blame the developers. These guys are doing a surprisingly good job, despite the lack of documentation, and man power. Novell has consistently diverted resources, and ATi has consistently wasted resources. I think it is well past time for some consolidation.

[mirv]

Not the size and complexity of a modern graphics driver. I dont think you fully understand what is involved. It's not just a few lines of code.... You got the DDX driver, the Mesa driver, and the DRI driver and each of these components have there own complexities. Developing a modern graphics driver requires a range of individuals, each with there own specialties. Everyone has a unique background....

It's because there isnt enough people.And that isnt there fault. It's Novell and ATi's fault. Stop trying to blame the developers. These guys are doing a surprisingly good job, despite the lack of documentation, and man power. Novell has consistently diverted resources, and ATi has consistently wasted resources. I think it is well past time for some consolidation.

Sorry, I'm apparently ignorant of some of the developments here - just how is lack of people working on an open source driver the fault of Novell or ATI? I would imagine that the lack of people is more the responsibility of the community (which demanded documentation) as a whole.