Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
real fglrx 12.3 released
Collapse
X
-
-
@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:
Adobe says - too many video APIs - video APIs thicket on Linux:
Last edited by zbiggy; 28 March 2012, 05:39 PM.
Comment
-
Originally posted by zbiggy View Post@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.
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.
Comment
-
Originally posted by allquixotic View PostBridgman 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.
Comment
-
@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!
Comment
-
Originally posted by bug77 View PostStrange, I was expecting you tested before complaining...
Also I did try with the previous catalyst 12.2 and the open source and they didn't work, no support.
Comment
-
Originally posted by Kano View Post@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 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.Test signature
Comment
Comment