The State Of Open-Source Radeon Driver Features

[bridgman]

And despite what you say I don't think DRM on linux is even an issue at all. I'm convinced that anybody who uses linux in the first place doesnt care one tiny little bit about DRM, otherwize they wouldnt be using linux. They only things that implement DRM is the proprietary drivers and EVERYTHING else circumvents it. I can't name a single proprietary video player that works well on linux. All of the OSS players are able to work by circumventing DRM.

I think DRM is nothing more than an excuse.

What do you think I said.

One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.

[duby229]

Don't think we have ever said that.

Remember the idea was "we provide info, community writes the driver", not "AMD writes the driver".



Don't understand this. We run on the common kernel and mesa development cycles. The X driver releases are aligned with kernel & mesa, but the X driver doesn't change much these days since most of the code is now in the kernel.

Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it. My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.

And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

[duby229]

What do you think I said.

One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.

But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

Like I said DRM sounds like a big fat excuse.

[agd5f]

And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

As has been stated previous on a number of occasions, certain features (like UVD) might not be able to be released at all, so we can't target a particular timeline when it's not clear whether that feature will be able to be released at all. We can't speak to when/if something like UVD will be released until all the internal discussions have been resolved and we can say yes or no.

[agd5f]

But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

Like I said DRM sounds like a big fat excuse.

Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.

[bridgman]

Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it.

Ahh, so you want to change the deal and have us fund a lot more of the open source driver work. Guess you never watched Transporter

My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.

Remember that fglrx is judged internally against 3D workstation requirements (slow changing enterprise distros, no compositors, very strong 3D focus). Consumer and business client requirements are different and I agree the open source driver is a better fit there.

And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

OK, so you're talking about release of programming information not development. Totally different.

Remember that we said from the start we were *not* committing to release UVD information, so knock that off your list. I did commit to *trying* and we are making progress there, so complaining that "it's been missing for years" and blaming process is kinda missing the point.

Power management a bit different but not much -- it went from being "trivial" to "really complex" while we were focused on getting caught up with display/2D/3D driver functionality. We didn't catch that in time (my fault) but have been working on it pretty hard and making good progress. Again, remember that as hard as writing the code is, releasing the programming info is even harder.

[bridgman]

But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux? Like I said DRM sounds like a big fat excuse.

Huh ?? Are you possibly thinking that DRM is an isolated little piece of the driver stack ? If so, please understand that it's not like that at all.

[crazycheese]

And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

MESA OpenGL level has progressed.
AMD attitude has not
They are straight, completely driver-type agnostic, highly passive player unless you bribe($$$) them
Current bribe list:
- microsoft ($$$$$$$)
- hollywood ($$$$$)

Ask yourself, how can you build anything stable on unstable ground?

There is also very high probability that (should AMD hardware be released) Android driver will be
- DRMed
- closed source
- financed as seperate entity, cannibalizing on Linux stack

:begin subliminal message:
And BTW, your arguing has no use, because you will not be given answers, but excuses.
If you want your arguing to have response and attitude as if you are customer, buy Windows
They know how to make open Linux driver better, not you Linux user
:end subliminal message:

[duby229]

Well, I just want to say thank you. I disagree with you completely on DRM and FGLRX, but there is nothing I can do about it.

Please don't misunderstand, I think you guys are doing a fantastic job. And it is good to hear that power management work is coming along. I know that UVD is probably never going to be supported and that when OpenCL gets into a better state at that point an opencl video decoder will be attempted.

[duby229]

Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.

I'm saying the should eliminate fglrx completely and maintain zero trees.