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.
Last edited by bridgman; 02-01-2008 at 01:39 PM.
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.
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.
You will not be in legal hot water if you do so obviously, while still making sure that the open source driver does 'everything'.
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.
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.
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
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.