![]() |
|
|||||||
| Open-Source AMD/ATI Linux Technical support and discussion of the open-source Radeon, RadeonHD, and Avivo drivers. |
![]() |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
|
Phoronix: AMD's New Open-Source Strategy Explained
Rumors and speculations have been flying around for months about ATI/AMD opening up the source-code to their Linux display driver or providing their GPU specifications to community developers. This for the most part had started after Henri Richard's statement at the Red Hat Summit earlier this year. Well, those rumors can finally be put to rest. AMD will be providing NDA specifications, an open-source library, and there is a new open-source graphics driver as a result. AMD will continue producing a closed-source proprietary driver; however, they are opening the source-code to a critical library with accompanying GPU specifications for X.Org developers. To get the ball rolling, AMD is also funding the development of a new open-source R500/600 driver. http://www.phoronix.com/vr.php?view=10979 |
|
#2
|
|||
|
|||
|
And here I thought it was cold two days ago... >:-)
|
|
#3
|
|||
|
|||
|
Quote:
Quote:
Edit: just to clarify the last question: because the specs are NDA'd, the open source community can't implement new features on their own, thus the proprietary driver remains in the lead. Does anyone have any thoughts on this?
__________________
ATI fanboy Last edited by Xipeos; 09-06-2007 at 01:04 PM. |
|
#4
|
|||
|
|||
|
i think this NDA is very very very evil thing.
imagine for a second - all current avivo/radeon xorg developers get involved. - they implement all documented functionality - some of them feel like catching up to fglrx is the way to go (because fglrx will have some extra features that won't be in the specs). - ati/amd cancels the nda because they attempted reverse engineering on fglrx (remember bitkeeper and linux?) - finally, they cannot develop opensource driver because of being tainted with NDA (like airlied was). call me paranoid, but that's the danger i can see there. it happened once to airlied, and it might happen again. btw what does "basic video playback" mean. unaccelerated? |
|
#5
|
|||
|
|||
|
|
|
#6
|
|||
|
|||
|
I wonder how many people will receive specs under the NDA. I would prefer that AMD release their specs openly, because releasing under the NDA really hobbles development. For example, I'm interested in driver development but have no expertise and in fact only limited programming experience. I'd never be able to qualify for information under an NDA, but I feel like if I had the information, I might be able to make some minor contributions.
I'm also concerned that AMD insists that the open-source driver will have only "basic" functionality. Does this mean that they will not release all of the specs even to those who sign an NDA, or simply that they're beefing up internal driver development and don't expect open-source developers to be able to match that? Will those who sign up for example, be able to get specs for accelerated video decoding if they want to implement it, or will AMD not provide that information at all? Overall, I'm glad that AMD is finally showing some commitment to getting their hardware well-supported in linux, but I'm concerned that they will hobble the open-source driver in order to keep fglrx ahead. |
|
#7
|
|||
|
|||
|
Despite what it says in the article aobut AMD's Open Source strategy explanation, this looks like R200 all over again. Don't get me wrong, I think it is a very good thing what they are doing, and it could be very beneficial even for non Linux and even Windows platforms (especially the library for talking to the BIOS)... However, this also means that the NDAs most likely apply to those parts of the hardware that either implement third party IP, or the like... So long as the open source drivers don't lag behind as dramatically as the "radeon" driver did for R200 comopared to the "fglrx", I'm OK. After all, it is not AMD's call to open those parts (though I'd like them to disclose those parts too, like the MPEG engine and texture compression (S3TC et al), Z compression algorithms, etc), but since those are licensed from third parties... never gonna happen, unless VIA opens up S3TC and the others open up their specs, it is NOT gonna happen.
It sucks that just like "dependency" hell, we are being held back due to these other dependencies. |
|
#8
|
|||
|
|||
|
Quote:
) sure we will see this again in the future.On the functionality points i think i made, and others too, my self clear to AMD that we want somethings allmost full functional for instance 90% of functionality. I am realistic here because there is things they can't tell us (HDCP, macrovision, ...) and this things are often tightly linked with others functionality so they can't provide all of this, and NDA is likely their for that so we can see how it works but just don't make code for using HDCP or compromissing the whole crypted things while still using others functionality. To sum up, their word: we want a good open source driver and if in the end it outperform the closed source driver than we will clap but we would prefer to be better. So it's a competition but as a developer i am not willing to put little dirty trick to make one app go 5pfs faster and another little hack for another app to win again 3fps. I want a reliable, performant and clean (code) driver.So the show will begin soon
|
|
#9
|
|||
|
|||
|
It would be nice if openning up the hardware would result in openning up programming possibilities.
those video cards have very impressive performance under certain workloads. It would be nice to harness that sort of thing for things like 3D rendering (thinking of Povray and such), media encoding, encryption, or whatever else people can think of. Essentially these GPUs things are like CPUs, aren't they? To me this is something that simply cannot be done nearly as well under Windows due to the static closed-source nature of the OS. It could give Linux quite a advantage and make inroads into more of the low-end/mid-range 3D graphics and movie/tv arena. It could provide very cost-effective performance. Also hopefully this would put more steam behind things like having the LLVM framework support GPUs for graphics programming. This could probably help out Linux desktop quite a bit... http://zrusin.blogspot.com/2007/05/mesa-and-llvm.html Last edited by drag; 09-07-2007 at 04:16 AM. |
|
#10
|
|||
|
|||
|
check this (it's from lwn.net, but for these articles, you have to pay):
http://lists.freedesktop.org/archive...er/027928.html it seems that it is just because the fusion gpu/cpu |
![]() |
| Thread Tools | |
| Display Modes | |
|
|