real fglrx 12.3 released

[slimg00dy]

Actually if this doesn't work you should wait for the driver I mentioned to get posted. I don't think this is it.

I really hope this driver is that you mentioned comes out soon, its running on 1+ week behind the release. Also I hope it suits my needs obviously. I'll wait patiently for now but please expect me to ask the question "does this support the 7850" upon future fglrx and catalyst releases.

[bridgman]

OK, I just heard back from CatalystCreator -- looks like Cat 12.3 *is* 8.951 so that should work for you.

[slimg00dy]

Awesome!!!!! Thank you!!! I'll test this out tonight.

[zbiggy]

@bridgman - you look like someone who has contact with Linux Catalyst team.
Can you tell Linux Catalyst team to drop XvBA completely and provide driver for VDPAU api? XvBA is dead. Nobody except XBMC uses it. And on XBMC XvBA causes problems.

Here are benefits of dropping XvBA and implementing VDPAU driver:
Immediate software benefits 'out of the box':
+ Adobe flash acceleration
+ acceleration in almost every Linux video player
+ nobody uses XvBA so nobody will cry for it when it disappears
+ XvBA hurts Linux. Do not hurt Linux please. Adobe flash developers told this on their flash blog: on Windows we have one video API: DXVA so we implemented it in flash. On Linux with have thicket of video APIs: VDPAU, vaapi, XvBA. So we will not implement video acceleration on Linux at all.
Eventually after community pressure they implemented VDPAU which is the only api which actually is mature and works.

AMD Workforce savings:
+ Catalyst Linux developers can concentrate on developing only Radeon driver for VDPAU - not whole XvBA api and its documentation. It is better to provide working vdpau driver and have immediate use in many players and Adobe flash than providing broken and limited, badly documented proprietary XvBA api and broken driver for it which means AMD does not exist on Linux as a video accelerator.
+ S3 Graphics company (VIA GPU division) implemented vdpau for its Chrome video cards to gain all the benefits described here. If small and unpopular S3 could have done this why big AMD can not?
+ if open source community was able to do galliumm vdpau acceleration for Radeon using shaders why paid developers at AMD can not do this for uvd where most of work is already done in hardware.

Legal benefits:
+ vdpau api/library is LGPL licensed
+ whole source code of vdpau library is freely downloadable including documentation and debug libraries for driver developers.
+ vdpau is NOT proprietary - Nvidia wants every GPU designer to use it - especially AMD and Intel. Even in publicly available vdpau api documentation libvdpau_ati.so.1 and libvdpau_intel.so.1 are mentioned as examples. They developed and gave you vdpau for free - why not just use it when the most of work was already done?

Sources:
vdpau programming:
ftp://download.nvidia.com/XFree86/vd...tml/index.html
here Nvidia says about libvdpau_ati.so.1 and libvdpau_intel.so.1:
ftp://download.nvidia.com/XFree86/vd...nsys__x11.html
Here is vdpau wiki which says everything:

http://en.wikipedia.org/wiki/VDPAU

Adobe says - too many video APIs - video APIs thicket on Linux:

http://blogs.adobe.com/penguinswf/2010/01/welcome_to_the_thicket.html

[bug77]

Awesome!!!!! Thank you!!! I'll test this out tonight.

Strange, I was expecting you tested before complaining...

[allquixotic]

@bridgman - you look like someone who has contact with Linux Catalyst team.
Can you tell Linux Catalyst team to drop XvBA completely and provide driver for VDPAU api? XvBA is dead. Nobody except XBMC uses it. And on XBMC XvBA causes problems.

Bridgman is the manager of the open source graphics team at AMD. He's not really supposed to have a whole lot of dealings with the Catalyst team, because they work on two completely separate drivers. No doubt they avoid talking about detailed technical things, because it's possible that the Catalyst team could leak encumbered IP accidentally to the open source team and it might get out {And then AMD would lose their signed contract with The Devil (err, I mean, the MPAA a.k.a. the SS) -- ohnoes! :O :P}

At best, he's a colleague to the guys who work on the Catalyst driver. But I am really doubtful that he would have any persuasive sway with the Catalyst team when it comes to the features offered by Catalyst, because that's not his driver. He's probably just slightly more persuasive than a random member of the public if he were to blatantly walk up to the Catalyst team and start telling them what he thinks should be included (or not included) in Catalyst.

I do have some direct contact with the Catalyst team, but I still can't put to-do list items on their plate. They still independently decide what to do (or not do) with their driver.

[Acidphase]

Bridgman is the manager of the open source graphics team at AMD. He's not really supposed to have a whole lot of dealings with the Catalyst team, because they work on two completely separate drivers. No doubt they avoid talking about detailed technical things, because it's possible that the Catalyst team could leak encumbered IP accidentally to the open source team and it might get out {And then AMD would lose their signed contract with The Devil (err, I mean, the MPAA a.k.a. the SS) -- ohnoes! :O :P}

At best, he's a colleague to the guys who work on the Catalyst driver. But I am really doubtful that he would have any persuasive sway with the Catalyst team when it comes to the features offered by Catalyst, because that's not his driver. He's probably just slightly more persuasive than a random member of the public if he were to blatantly walk up to the Catalyst team and start telling them what he thinks should be included (or not included) in Catalyst.

I do have some direct contact with the Catalyst team, but I still can't put to-do list items on their plate. They still independently decide what to do (or not do) with their driver.

I agree it's really tough to get the attention of company developers, just look at the gaming industry 90% of the time the developers are tied up implementing things to make money and the PR guys get slammed with ideas and suggestions. This is sort of the same here the best thing to do is just keep the notion alive among the Linux community eventually it will get someones attention not as fast as other OS's but their are proud Linux users whom are also developers it just what they're allowed to do and when things get the okay or go ahead. I have feeling if canonical was aware and involved with the issue it might get attention slightly faster, but that's just speculation on my part.

[Kano]

@bridgman

The supported pci-ids did not change at all from 12-2 to 12-3 when you look at the fglrx kernel module. from 12-1 to 12-2 only 2 ids where added (679e and 990a). So the only change could be in the control file to get rid of unsupported hardware. And the devs needed so long to do that, really really bad joke. That whole control/signature file thing is pure crap, give it up!

[slimg00dy]

Strange, I was expecting you tested before complaining...

Sorry if I was complaining. its just that my card has been in a box for a week and I've been using this loud Nvidia card which is driving me crazy.

Also I did try with the previous catalyst 12.2 and the open source and they didn't work, no support.

[bridgman]

@bridgman

The supported pci-ids did not change at all from 12-2 to 12-3 when you look at the fglrx kernel module. from 12-1 to 12-2 only 2 ids where added (679e and 990a). So the only change could be in the control file to get rid of unsupported hardware. And the devs needed so long to do that, really really bad joke. That whole control/signature file thing is pure crap, give it up!

The PCI IDs in the code determine which hardware the driver will *try* to run on. The code might work perfectly, or be buggy, or fail to run at all.

The PCI IDs in the control file show which hardware the driver has passed QA on.

Once testing and bug fixing on specific hardware is completed, the IDs in the control file are updated to reflect that these binaries form a production driver for the hardware it's running on, whereas previously it displayed a "hey this might run but be aware it's not a production driver" message.

The time and effort is not to add IDs to the control file (that's all automated anyways) but to do the testing, bug fixing and re-testing required to pass QA on the hardware and make it appropriate to mark the resulting binaries as production-ready in the control file.