AMD Linux
Mixing open and closed source
The skill sets are surprisingly different. We do horse-trade resources back and forth but in general we need people with legal and IP background to work on doc and code releasing.Originally Posted by val-gaav
This sounds great and it's an option we do consider, but so far it's not looking that good. Might be possible to have some of the display driver code relying on open source, but most of the acceleration stack (drm, xv*, opengl) will need to be closed source in the future for a couple of reasons :
1. If we're ever going to play protected video (DVDs, HD/BD) then we have to protect the decoded bitmaps all the way to the frame buffer, and we can't do that in an open driver.
2. For workstation business we invest a lot of money in performance-related driver work and wouldn't want to open source that because some of that work *is* useful to competitors.
Since we're not playing protected video today we could convert to use more open source in the short term, but by the time we finished that it would probably be time to start converting back
IMO the best strategy is to have open AND closed drivers and use each one where it fits best.
AMD Linux
This confuses me a bit. When we announced the open source initiative we talked about display and 2d in 07 and 3d in early 08. Everyone was really excited that things would be happening so soon. Now display is out, 2d is coming, we're within a few weeks of that schedule and things are "glacially slow". Did someone else post a much more aggressive schedule that I missed, or is this just honest impatience and "internet time" ?
Last edited by bridgman; 02-01-2008 at 01:39 PM.
AMD Linux
Ahh, I think I see the problem. We did a bunch of interviews back at the initial announcment, and I talked about roadmap and schedule in many of them. When I go back and look at the articles it looks like many of them didn't bother with that much detail. Michael was pretty much the only one who asked technical questions and we spent more time talking about implementation plans, how far the open source support would go, differences between the GPU generations, AtomBIOS and the like.
I talked about roadmap and schedule so much I literally never wanted to discuss the subject for the rest of my life, particularly since all the schedules were based on putting together a big heap of estimates, but for all that apparently the roadmap didn't get out to the public as much as I thought.
So...
Sequence of implementation is display/modesetting, then 2d acceleration, then 3d acceleration, then video. The reason for that sequence is :
- a display/modesetting driver is quite useful on its own, albeit a bit sluggish with those big monitors you all seem to have (runs real fast on my 17")
- you need display first or you can't see what you're doing for the other phases
- 2d acceleration hardware doesn't really change much from earlier ASICs -- only real change is with R6xx where it's emulated by the command processor. Existing code *and* existing documentation were sufficient, although I need to re-release the R200 era docs so new developers can join in
- 2d acceleration was also a nice safe way to get the DRM going which could then serve as a foundation for 3d
- programming model for the 3d hardware didn't seem much different from earlier ASICs (as long as we weren't trying to take advantage of all the new features) but we weren't 100% sure and needed time to put documentation together.
- video in 5xx+ ASICs is completely different from earlier ASICs, since we took most of the dedicated image processing hardware out of the overlay and used the space for more shaders. The good news is that we can do cooler things with shaders than fixed hardware -- bad thing is that it means video support has to come *after* 3d support whereas on previous ASICs it was easy to do first
The schedule we expected was roughly :
- display/modesetting lighting up in 3Q07
- 2D acceleration lighting up in 4Q07
- 3D acceleration lighting up in 1Q08
- video acceleration lighting up in 2Q08
By "lighting up" I mean "working for most users, enough functionality for many people, but we'll be adding features and handling corner cases & systems for months afterwards.
If anyone has heard different roadmaps, please let me know.
Last edited by bridgman; 02-01-2008 at 02:08 PM.
Junior Member
This is exactly why I proposed to 'not care' about protected content some time ago and release what you can for non-protected content. Just release enough information that the open source driver can implement video playback of non-protected video.
You will not be in legal hot water if you do so obviously, while still making sure that the open source driver does 'everything'.
AMD Linux
That's something different, and we are still going to try to do that. I'm just warning everyone that unless we find a way to enable use of UVD in an open driver without compromising the DRM in the closed driver I can't say that we will go any further than the IDCT/MC acceleration. We do DRM and decode in the same block, so exposing one without exposing the other is not necessarily possible.
We've got no problem with trying to enable decoding of non-protected content in the short term, assuming we can get around DRM and legal risks. I just have a problem with proposing to move fglrx on top of an open source driver if we would have to move it all back again to play protected content in the future.
Linux Game Publishing
I was thinking it was going to be a bit quicker than that ("Internet Time" and all...) - but now that we're seeing what you have in mind, it's not QUITE so bad. It's still faintly problematic for the parties needing something substantive now- but it's even nicer looking than I'd thought before. I'm still frustrated, but there's definitely a real plan, we're close to it after all, and the light at the end of the tunnel's not the train coming back to run us over the third or fourth time... >:-)
Senior Member
I think most people will use the open drivers once those will be complete...
By my experience it will be hard for fglrx to top open drivers on some fields. One may argue fglrx will improve .... well maybe,but who will report bugs to you guys ? I mean if everybody use open drivers (and I'm sure most people will if the quality is ok) the fglrx will experience problems. That's why the "blob module" seemed a better solution for me.
As for protected content support... Are there really users who want that ? From the other topic on phoronix forums I came to conclusion it was more a wish for hardware decoding but not for playing protected drmed content(just for normal unprotected h.264).
Anyway AMD sure is the best right now when it comes to contact with community. Thanks for that and for your answers Bridgman... and time you spent here and various irc chanels. That's one of the reasons which made me choose a notebook with rs690 with the hope for future support
About the "glacially slow" issue I think some people get a bit impatient because they already own ati hardware... that's all.
Last edited by val-gaav; 02-01-2008 at 04:29 PM.
AMD Linux
Honestly, I don't know. If we conclude that there will never be a demand for protected video playback then that opens more options for the future. On the other hand, the Dell preloaded SKU ships with LinDVD today. DVD doesn't need the same kind of protection that HD/BD requires so it's not an issue for today, but if Dell sees demand for DVD today then that will probably translate into demand for BD tomorrow, and that *does* need protection right down to the kernel drivers.
What I expect is that more people will use the open source driver than the closed source driver, but the people using the closed source driver will continue to enthusiastically express their feelings when they're not happy with it
Besides, what happens when Crysis shows up on Linux ?
EDIT - I just noticed this is the Intel docs thread. We should move somewhere else. Keith and others put in a lot of hard work to get those docs out -- let's show them some respect
Senior Member
well right now dell offers laptops with intel graphics so I wonder what will intel and dell do with BD ? they don't have closed drivers...
[EDIT]
someone with mod powers should split this topic
Last edited by val-gaav; 02-01-2008 at 06:06 PM.
AMD Linux
Mixing open and closed source
Good question. Right now it's a chicken/egg situation -- no secure driver, no certified player, no problemwell right now dell offers laptops with intel graphics so I wonder what will intel and dell do with BD ? they don't have closed drivers...
Of course nobody knows if there's a market for a certified player app that can legally play HD/BD on Linux anyways.
Posting Permissions
Reply With Quote