HI! After thinking a lot about this (and also chating with cxo on the irc channel) I decided to post...
The idea is to have a binary library on top of the opensource driver, which would have all the special top secret features into it, developed by AMD/Ati.
This binary library would be completely optional but it would benefit both, AMD/Ati and also the opensource community. This would speed up the driver development (and indirectly the implementation of GEM/TTM, Gallium, DRI2) giving us a stable driver that has compatibility with every distro and AMD/Ati would be able to create this library on top it and bring advanced features to every user.
This features would include OpenGL 2D/3D optimization routines for workstation users (mainly FireGL cards), also UVD Accel for normal users and maybe a fast implementation of OpenCL on top of Gallium.
I have also asked Bridgman about this on the "Ask ATI" dev thread .
Source of the idea: http://en.wikipedia.org/wiki/Intel_GMA#intel_hal.so
Well, thanks for your attention, Phoronix rocks!
Hi! As Bridgman said in other posts, there are some parts of documentation/code that they can't opensource because of legal/competitive issues... The library can solve that problem for the people who need those features.
But that won't be the important part for the community, the benefit for us would be to put all the effort in the opensource drivers, because AMD/Ati would help to implement all the features which don't have legal/competitive problems.
I'm really interested in speed up the development, actually the efforts are so divided that we will get optimized drivers in a lot of time. In the other way, using the library, we can use this features in the short term and replace them with time, so the binary library will be smaller.
I think that people need to use something that works well, and as Nille said, currently some features are only in determined drivers, but it would be ok to have the library on top of an opensource (very stable) driver.
There's no point investing or working in something that by definition has no future.
Bridgman said somewhere that UVD was going to be documented.
If you want proprietary drivers Activate it and if not dont use it.
So what's the point with releasing all these specs ?
There are three main problems with this approach :
1. For the 3D driver, the performance isn't just a function of "a secret module" (say, the shader compiler) but from the integration of the entire stack including big chunks of the kernel driver (memory management and command submission). If all those bits aren't used together then the performance is going to drop pretty fast.
2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet. Until the "what does Linux want to become ?" discussions settle down (if ever) I don't think it makes sense to take the driver in a direction (closed source 3D mixed with open source modesetting) where we would have to completely discard in order to deliver a secure legal BD solution.
3. For UVD, having a small binary module in an otherwise open source driver doesn't really protect the code at all; it's just too easy to reverse-engineer a closed source module if everything around it is open source. I believe Intel dropped the idea themselves, at least that's the impressino I get from the various articles mentioning it.
For clarity, issue #1 is a big enough problem before even considering #2 and #3.
I think the combination of opening up the install/packaging scripts (on phorogit) plus making the drivers more "chatty" so that problems can be diagnosed and fixed more quickly will go a long way to making the driver more tolerant of system-to-system variations.
Last edited by bridgman; 02-05-2009 at 10:04 AM.
Well, after reading your post I arrive to a conclusion...
1- As I see, it would be at least very difficult to implement this kind of approach in the opensource driver in order to add 3D optimizations because of the integration between the opensource and the binary parts. I am not a xorg developer but what about supporting only certain versions of the opensource stack, you know something like "AMD Performance Libs version xxx are compatible with Radeon/Mesa version xxx" so they will stay syncronized.
2- About BD and DRM, I think that they aren't (and maybe won't be) used in Linux... The normal user would be playing home-made h264 or xvid content or at least downloaded from internet.
3- UVD critical information, that would be a problem too, if it is difficult to protect it with this approach we would fall in a legal issue. Maybe there is some way to turn this around or maybe not, I'm not sure.
This has left me a doubt... Would it mean that libva binary approach is insecure too? Will this slow down the development of libva api?
Well, thanks for all your attention again...
Bridgman said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "
popper said:"thats a shame, we are looking at months at the very least then!"
Bridgeman said:"I think the attraction of the [NV cuda] library is that it makes it easy to retrieve the decoded frame, while most of the decoder implementations supplied by HW vendors tend to only output to the screen simply because that was the main requirement.
We make a similar capability available to ISVs :
popper said:"yep,that about covers it for basic needs it appears, your average dev and indeed Pro coders such as BetaBoy and the CoreAVC coders dont really need that much help once they have the right library and docs access it seems, BetaBoy said he wanted to support ATI UVD in CoreAVC and related apps but you dont give them or the open SW coders access to the ATI UVD."
Bridgeman said:"For open source, yes, but I expect fglrx will have it sooner."Quote: 01-08-2009, 07:48 PM
Originally Posted by popper
thats a shame, we are looking at months at the very least then!
until those UVD header and UVD docs become available, IF ever, we are going nowere, but i assume and really hope Bridgman is hard on the case regarding that vital UVD review, and doing what he can to push it, and its related documentation to the top of the things to get done by someone? inside AMD/ATI ASAP , would that someone be you Bridgeman as the key person?
Last edited by popper; 02-05-2009 at 01:20 PM.
So the implementation of UVD will be slow, we don't have even the specs...
Also we aren't sure about which of them are going to be reviewed, because there is UVD (R600 chips) and UVD2 too (R700 chips, more posibilities to be opened)...
I have a Radeon HD2400 (rv610) and I'm not sure if the opensource driver would support UVD on it.