If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Mixing open and closed source

IMHO AMD should drop the development of fglrx for some time and focus on doc and code releasing. Last fglrx driver seems to be quite nice already so people shouldn't complain if they know that AMD for the time being is focusing on the docs and open drivers...

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.

In the long run AMD should drop fglrx for good and just develop some blob module for open drivers for things that couldn't be opened like h.264 hardware decoding or other DRM things... It's a waste of resources to develop both open and closed drivers.

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.

Yeah. The unrest in the AMD user camp (raises hand...got parts, I do, I do...) is, I think, due to (snip) along with a glacial pace for the documentation and the honestly opened stuff.

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" ?

Comment

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

Comment

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.

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'.

Comment

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.

Comment

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... >:-)

Comment

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.

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.

Comment

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).

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