asfdati = super reatrd driver retard crap retard retard retard

[pedepy]

as i am typing this no text shows in the text box BECAUSE AMD ATI VIDEO DRIVERS ARE CRAP

I hope im not making too many typos. Anyway, composite with 8.9 or 8.8 or whatever sems completly brlen. I just get a white screen of death. I have downgrade to 8.8 and i still get the same problem wich started when i upgraded to 8.9

WHAT THE FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUCK.

im getting real tired of this ... 8.5 was just perfect why did you retard devs go and break everything.

[duby229]

as i am typing this no text shows in the text box BECAUSE AMD ATI VIDEO DRIVERS ARE CRAP

I hope im not making too many typos. Anyway, composite with 8.9 or 8.8 or whatever sems completly brlen. I just get a white screen of death. I have downgrade to 8.8 and i still get the same problem wich started when i upgraded to 8.9

WHAT THE FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUCK.

im getting real tired of this ... 8.5 was just perfect why did you retard devs go and break everything.


I can fully understand your frustration, but chill out dude. It's really not the devs fault. Calling them retarded is pretty fuckin stupid. Blame the people who need to be blamed and that is ATi and Novell.

The developers they have working for them should be applauded for putting up with the bullshit they are forced to endure by there employers. Blame the corporations, it's really there faults for not fully supporting the open source process. This half assed bullshit is really where the source of the problem lies, and that is not the developers fault.

[deanjo]

Blame the people who need to be blamed and that is ATi and Novell.

Oh give me a break, Novell is contracted to help with the drivers. How they can determine what ATi does to appease the FOSS community is entirely on ATi's heads and the owners of 3rd party IP, it has nothing to do with Novell. Novell is simply developing the RadeonHD drivers and has nothing to do with the fglrx drivers. Get your fact straight and spread your FUD with at least some ounce of fact.

[duby229]

Oh give me a break, Novell is contracted to help with the drivers. How they can determine what ATi does to appease the FOSS community is entirely on ATi's heads and the owners of 3rd party IP, it has nothing to do with Novell. Novell is simply developing the RadeonHD drivers and has nothing to do with the fglrx drivers. Get your fact straight and spread your FUD with at least some ounce of fact.


And dragging ass in every possible way while doing it.. Intentionally diverting resources, and forcing it's developers to wate time on dead end code paths.

Dont even try to make Novell out to be the good guy becouse they are not. They --ARE-- the left hand reason why the linux drivers are in the shit state today that they are. The RadeonHD project has put the open source drivers at the very least a full year behind what they could have been, and --should-- have been today. And that --IS-- entirely Novell's fault, and on the right hand it is ATi's fault for giving them the money to do it.

Novell is a puppet.....

It is --NOT-- the developers fault. Those guys deserve every ounce of credit that they can be given. It's unfortunate that ATi has chosen to half ass it's open source efforts. But I honestly believe that if ATi told Novell to suck on a fat nugget, and finally embraced a proper open source model completely, they could have a decent product on there hands. --BUT-- Thats not the case and as it is right now, at this very moment, ATi's superior hardware sucks ass in linux.

Call it what you will, but those are the --FACTS-- whether you like them or not....

[deanjo]

And dragging ass in every possible way while doing it.. Intentionally diverting resources, and forcing it's developers to wate time on dead end code paths.

Dont even try to make Novell out to be the good guy becouse they are not. They --ARE-- the left hand reason why the linux drivers are in the shit state today that they are. The RadeonHD project has put the open source drivers at the very least a full year behind what they could have been, and --should-- have been today. And that --IS-- entirely Novell's fault, and on the right hand it is ATi's fault for giving them the money to do it.

Novell is a puppet.....

It is --NOT-- the developers fault. Those guys deserve every ounce of credit that they can be given. It's unfortunate that ATi has chosen to half ass it's open source efforts. But I honestly believe that if ATi told Novell to suck on a fat nugget, and finally embraced a proper open source model completely, they could have a decent product on there hands. --BUT-- Thats not the case and as it is right now, at this very moment, ATi's superior hardware sucks ass in linux.

Call it what you will, but those are the --FACTS-- whether you like them or not....


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.

The RadeonHD project has put the open source drivers at the very least a full year behind what they could have beenConsidering 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.

[adamk]

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.


Unless something has happened recently, there is no documentation available for r600 and newer GPUs. Just r500 and older, all of which are supported by open source drivers.

Adam

[_txf_]

I would like to point out that whilst initially RadeonHD was a waste of time and did not develop very fast (primarily due to developer hubris). they are now more or less in parity and as a result most developments should contribute towards a working driver.

[yotambien]

WHAT THE FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUCK.

Oh, man, I usually don't like whining but you just made up my day.

:D

[deanjo]

Unless something has happened recently, there is no documentation available for r600 and newer GPUs. Just r500 and older, all of which are supported by open source drivers.

Adam


There is some documentation available now with more forthcoming. Sometimes I get a sense that people don't realize how much work is involved with technical documentation.

[Melcar]

There is some documentation available now with more forthcoming. Sometimes I get a sense that people don't realize how much work is involved with technical documentation.

Yeah, it takes time. People at AMD don't just wake up one day and say "here, Mr. FOSS driver developer guy, have all our GPU documentation". There is a long and tedious process involved before any sort of documentation can be released.

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.

....

Couldn't agree more. It sometimes baffles me why people keep bitching at AMD over the state of the FOSS drivers

[val-gaav]

Well Jade may have a nice conspiracy theory on how Novel is trying to sabotage KMS and prevent it from getting into the kernel. :)

[RealNC]

That's what happens when you buy MS Windows-only hardware (ATI+NVidia).

[bridgman]

How did we become Windows-only ? We have drivers for Mac OS, Linux, a couple of embedded OSes, plus open source drivers which run on Linux, FreeBSD and Solaris and probably a few more embedded OSes.

[deanjo]

How did we become Windows-only ? We have drivers for Mac OS, Linux, a couple of embedded OSes, plus open source drivers which run on Linux, FreeBSD and Solaris and probably a few more embedded OSes.

Ya but where is Plan 9 love :p

[bridgman]

D'oh !!

You're right; no Plan 9 driver. Yet :D

Last time I saw Plan 9 run was on a 6502, I think. That's definitely going to need video acceleration in the GPU ;(

EDIT - holy *&^%*(!, it's still going. It has Live CDs and everything. There's even an internation Plan 9 conference coming up in a few weeks. It's in Greece, unfortunately. Wouldn't you know it, there's an Intel employee on the conference Program Committee :eek:

http://plan9.bell-labs.com/plan9/

Looks like there are Plan 9 drivers for ATI graphics, but only up to R2xx. Maybe we can fix that.

[flami]

I'm wondering if its a bad omen if your OS's and mascots name are references to (arguably) the worst movies of all times ^^ .

( yes I went there ! )

[bridgman]

I always wondered if the Plan 9 OS would have been more successful with a different name. It came out of Bell Labs a long time ago (back in the days of 8-bit CPUs) -- but I have to admit it has survived a lot longer than I expected.

[deanjo]

Plan 9 is going through a bit of a revival for some unknown reason. I guess OS Junkies gotta have them all.

[Ex-Cyber]

Last time I saw Plan 9 run was on a 6502, I think.Given the who, what, and when of Plan 9's origins, I submit that it was more likely a 68020. On the other hand, a 6502-based system with a network interface could be programmed to speak 9P and thereby integrate into a Plan 9 system...

[bridgman]

Yeah, I was wondering that after posting. I do vaguely remember it being a 32-bit OS out of the box.

[deanjo]

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

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

[Zhick]

Srsly, I don't understand why you guy's get so worked up about video-decode-acceleration. I just played 8 720p videos at the same time just for fun, and things were still smooth and cpu-usage wasn't even 90% for most of the time. Now I'll admit my system is probably not the slowest one out there, but it's also faaar from top-notch/up-to-date (C2D E6600).

[Melcar]

Srsly, I don't understand why you guy's get so worked up about video-decode-acceleration. I just played 8 720p videos at the same time just for fun, and things were still smooth and cpu-usage wasn't even 90% for most of the time. Now I'll admit my system is probably not the slowest one out there, but it's also faaar from top-notch/up-to-date (C2D E6600).


Not everyone has C2Ds (or a fast CPU for that matter).

[Zhick]

Not everyone has C2Ds (or a fast CPU for that matter).Yes, but if you've got an old/slow CPU, it also seems unlikely to me that you have a new and modern GPU that could do all that decoding for you.
Edit: I don't think decode-acceleration has no point at all, but imho there are far more important things at hand (like vsync, OpenGl-2.1 support, ...).
And more important: Afaik there's already a functioning decode-acceleration for Gallium3d, so implementing mc and stuff now would probably be duplication of efforts.

[Melcar]

Yes, but if you've got an old/slow CPU, it also seems unlikely to me that you have a new and modern GPU that could do all that decoding for you.
Edit: I don't think decode-acceleration has no point at all, but imho there are far more important things at hand (like vsync, OpenGl-2.1 support, ...).
And more important: Afaik there's already a functioning decode-acceleration for Gallium3d, so implementing mc and stuff now would probably be duplication of efforts.


You never know. Vendors are always coming up with weird cut down versions of current gen GPUs for "ancient" interfaces (PCI cards are still showing up). These particular GPUs, while definitely not "powerful", are still capable of good HD content playback on their own. Similarly, some of the higher end AGP cards are more than capable of such playback, but since those particular platforms are stuck with rather slow CPUs, not being able to use the GPU for HD can be a real problem. And if anything, having the feature is important if at least for the principal of the thing.

[Melcar]

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.


I'm guessing he's referring to financial backing.

[bridgman]

I'm a bit confused by this discussion. There *is* a lot of work and progress going on -- it's just that much of the focus has shifted from radeon and radeonhd to drm and mesa. There is a lot of work going on with memory management and kernel modesetting (KMS requires memory management) -- and memory management is also the pre-requisite for full OpenGL, DRI2, and a host of other improvements (even Gallium has a sorta-kinda dependency on memory management and DRI2).

[Melcar]

I'm a bit confused by this discussion. There *is* a lot of work and progress going on -- it's just that much of the focus has shifted from radeon and radeonhd to drm and mesa. There is a lot of work going on with memory management and kernel modesetting (KMS requires memory management) -- and memory management is also the pre-requisite for full OpenGL, DRI2, and a host of other improvements (even Gallium has a sorta-kinda dependency on memory management and DRI2).


It's just people being impatient, that's all.

[bridgman]

Yeah, it's easy to forget that X11 has been evolving for 21 years already :eek:

[_txf_]

You never know. Vendors are always coming up with weird cut down versions of current gen GPUs for "ancient" interfaces (PCI cards are still showing up). These particular GPUs, while definitely not "powerful", are still capable of good HD content playback on their own. Similarly, some of the higher end AGP cards are more than capable of such playback, but since those particular platforms are stuck with rather slow CPUs, not being able to use the GPU for HD can be a real problem. And if anything, having the feature is important if at least for the principal of the thing.

I was under the impression that the pci bus bandwidth is insufficient for hd video decoding (and certainly not at bitrates from things like bluray).

Now consider windows... Nobody can argue that graphics drivers are far more complete under windows, but do those agp cards advertise hd video video playback? do the drivers support it on those cards?

I know We don't have to accept the limitations that windows users have but will users of those older cards be able to take advantage of them on windows?

[Melcar]

I was under the impression that the pci bus bandwidth is insufficient for hd video decoding (and certainly not at bitrates from things like bluray).

Now consider windows... Nobody can argue that graphics drivers are far more complete under windows, but do those agp cards advertise hd video video playback? do the drivers support it on those cards?

I know We don't have to accept the limitations that windows users have but will users of those older cards be able to take advantage of them on windows?


There are people with such hardware combinations out there. Doesn't make that much sense, but what can you do.
Another example would be small HTPC boxes. People usually go for smaller budget cards and cheap CPUs. Being able to handle HD content comfortably on that <$40 GPU would be nice, but currently you need a "beefy" CPU for it (and you may not want such a "beefy" CPU for your HTPC).
Proper HD content playback has become rather important in today's home computing environment, so not having it ticks off a lot of people.

[duby229]

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.

Perfectly good questions... The problem comes down to the size of the linux market share. Simply put the bottom line is that AMD does not have enough people working on the linux portion of there propriatary code base. Maybe 5 people max, maybe... That's just simply not enough people to maintain a propriatary driver. It's just not. FGLRX is doomed. On the other hand if AMD paid those same 5 people to work on the open driver that would almost double the number of people working on the open drivers.

Can you imagine how much further along we'd be today if we had almost double the number of open source driver developers? Clearly it would have to be well organized. Throwing more people at the problem isnt going to fix it. But throwing people at specific problems will. Set aside a group of people to work on the DDX driver, and another to work on the DRI driver, and maybe another to work on Mesa.... There --IS-- enough parallelism to support more developers. Graphics drivers are big hairy monsters that have many different components with many different complexities.

And none of this even mentions those folks that Novell is using ATi's money to work around in worthless circles.

[sundown]

Yeah, it's easy to forget that X11 has been evolving for 21 years already :eek:

I was thinking how good an option the open driver will be, just by witnesing how much X sucks :confused:

[mgc8]

Srsly, I don't understand why you guy's get so worked up about video-decode-acceleration. I just played 8 720p videos at the same time just for fun, and things were still smooth and cpu-usage wasn't even 90% for most of the time. Now I'll admit my system is probably not the slowest one out there, but it's also faaar from top-notch/up-to-date (C2D E6600).

Sorry, but I can give you ten more examples where the opposite happens. The truth is that HD video playback in Linux is a mess no matter what graphics platform is used -- none has any acceleration.

HD is a complex issue and it's not only resolution but also bit-rate and the ammount of movement that influence outcome. For example, I currently use an E8400 (3Ghz) with mplayer on an Intel G35 and guess what, it competely chokes on high-bitrate 1080p -- just try the (in)famous birds scene from Planet Earth.
Another machine, a 2.7 Ghz AthlonX2 with nVidia 6150 on-board video chokes even on 720p content with lots of movement (various animation movies come to mind).

So basically if you want flawless playback for HD content nowadays you must either overclock to something above 4Ghz or use video acceleration, the way it's done in *win.

Part of the problem is that we don't have decent software players either, that is a sad truth and perhaps an F/OSS shortcoming, seeing as commercial alternatives do it better (for example, *none* of the available free back-ends uses multi-core... so even with an Octa-core 3Ghz processor you're stuck at the same performance as a single-core).
On the other hand, having some sort of hadware acceleration would go a long way towards helping the situation, and it would allow people to use a low-cost processor and GPU in a HTPC for example, things you just can't do today (certainly a 40$ GPU can do a lot more for acceleration than a 1000$ Quad-core CPU, but you just don't have the option).

Here's to hoping either Intel or AMD come up with hardware HD support in Linux, I for one don't have much hope from the green guys even though I always appreciate nice surprises :)

[sundown]

Hurray to mgc8. I am all for decent HD playback. Although I don't know who is to blame, AMD or X :)

[SolidSteel144]

I really hope they get off their asses and fix this mess.

[Moronix]

hahaha, the opening post was funny. I'll tell you why some people are so pissed. It's because of the hype of some new, up and coming ati linux drivers that was toted around a while back. If it had all been quiet and if nvidiaphobic fanboys hadn't spread lies around, there would be more seeing the glass half full about fglrx. Even with that said they won't give in to the fact this driver fails.

[deanjo]

Sorry, but I can give you ten more examples where the opposite happens. The truth is that HD video playback in Linux is a mess no matter what graphics platform is used -- none has any acceleration.

Not really true. Accelerated dirac playback is available Nvidia cards supporting Cuda.

http://www.cs.rug.nl/~wladimir/sc-cuda/

[enzobelmont]

i'm running my linux box with radeon driver instead fglrx because of xorg 1.5 and it is a lot of pain...

surely it will not be supported for this month release...

what a frak!!! shame on you ATI.

[mgc8]

Not really true. Accelerated dirac playback is available Nvidia cards supporting Cuda.
http://www.cs.rug.nl/~wladimir/sc-cuda/

Accelerating a codec nobody's ever heard of hardly counts. When that same research can be applied to h.264 or vc-1 or any of the common codecs out there *and* in a F/OSS application like ffmpeg/gstreamer/etc., the situation will be different. Until then my comment still stands.

I also happen to think (as I've stated in my original post) that the OSS community has failed in delivering this type of functionality -- as your link points out, it would be possible to do it using CUDA or Stream or other ways that don't necessarily use the hardware accelerating path on the card, but nobody has so far done it -- while a proof-of-concept CUDA h.264 encoder exists in the commercial world, nothing like that has appeared on our side, even though CUDA works perfectly well in Linux too... That of course is unfortunate.

[deanjo]

Accelerating a codec nobody's ever heard of hardly counts.

If your suggesting a coded that the pirate "scene" doesn't use then your right. Then again they don't know about ogg as well and just finally clued into h.264 and mkv as a container format.;)


When that same research can be applied to h.264 or vc-1 or any of the common codecs out there *and* in a F/OSS application like ffmpeg/gstreamer/etc., the situation will be different. Until then my comment still stands.


There are a few XBMC contributors working on that as we speak with Cuda.


I also happen to think (as I've stated in my original post) that the OSS community has failed in delivering this type of functionality -- as your link points out, it would be possible to do it using CUDA or Stream or other ways that don't necessarily use the hardware accelerating path on the card, but nobody has so far done it -- while a proof-of-concept CUDA h.264 encoder exists in the commercial world, nothing like that has appeared on our side, even though CUDA works perfectly well in Linux too... That of course is unfortunate.


Well the Cuda h.264 isn't a proof of concept, it does exist commercially and is available but we are not talking about encoding here but decoding. A large part of the issue here is that in the #1 used OS, such solutions is not needed (GPU assisted decoding) as it has had good acceleration for quite some time so it falls pretty much on the *nix crew to come up with such solutions. Until solutions such as openCL gets adopted as the "defacto" GPGPU standard in the *nix side of things, I can't see it improving. Nobody in the *nix world wan't to develop for one specific piece of hardware (OK scientific community excluded which they seem to have embraced Cuda). Let's face it, a developer doesn't want to have to write code for every single variation of GPU computing. Things will improve I'm sure once a standard is adopted until then developers could very well be painting themselves into a corner if the choose a solution that only serves some configurations but not a large majority of them,

[psycho_driver]

hahaha, the opening post was funny. I'll tell you why some people are so pissed. It's because of the hype of some new, up and coming ati linux drivers that was toted around a while back. If it had all been quiet and if nvidiaphobic fanboys hadn't spread lies around, there would be more seeing the glass half full about fglrx. Even with that said they won't give in to the fact this driver fails.

Sadly there is truth in this. fglrx is still WAY behind nvidia's proprietary driver.

[mgc8]

If your suggesting a coded that the pirate "scene" doesn't use then your right. Then again they don't know about ogg as well and just finally clued into h.264 and mkv as a container format.;)

Well, although a valid point, the "original" bluray discs happen to be using the same codecs (h.264 and vc1) and at much higher bitrates, which means having those codecs supported would be worthwhile even outside the "scene".

There are a few XBMC contributors working on that as we speak with Cuda.
Nice to hear that! Hope they submit their patches upstream and share the fun... great news anyway!

Let's face it, a developer doesn't want to have to write code for every single variation of GPU computing. Things will improve I'm sure once a standard is adopted until then developers could very well be painting themselves into a corner if the choose a solution that only serves some configurations but not a large majority of them,
That is true. Indeed, a common platform/api/etc. for GPGPU is sorely needed... maybe apple will have luck with their openCL initiative :)