AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

[Vim_User]

- Major changes in the driver to be able to use the radeon kernel module, which will take a significant amount of developer time? Resources are scarce, so, we'll maintain only one set of kernel interfaces instead of two, reduce our maintenance burden, and free up developers to even think about Mantle.

Sou you mean once the switch to the radeon kernel module is made the "free" developer time does not have to be put into working on the radeon module for release-day support of new hardware and implementing missing features that fglrx supports, but radeon not? Still the same question, where would they magically get that time from if they don't even have the time for proper changelogs?

[GreatEmerald]

Yeah, tearing vs stuttering, the "choose your poison" of the modern graphics experience. I hope Gsync takes off, and won't be Nvidia exclusive, to fix that one.

I wish it was a choice. But I get tearing and nothing else. (Well, to be honest, nouveau doesn't tear. But it does lock up the GPU. That's slightly worse.)

Sou you mean once the switch to the radeon kernel module is made the "free" developer time does not have to be put into working on the radeon module for release-day support of new hardware and implementing missing features that fglrx supports, but radeon not? Still the same question, where would they magically get that time from if they don't even have the time for proper changelogs?

That's oddly worded. The point of this is that instead of two teams maintaining two different kernel drivers, it would be two teams maintaining one, which means more time for them to work on something else.

[bridgman]

Sou you mean once the switch to the radeon kernel module is made the "free" developer time does not have to be put into working on the radeon module for release-day support of new hardware and implementing missing features that fglrx supports, but radeon not? Still the same question, where would they magically get that time from if they don't even have the time for proper changelogs?

Maybe I don't understand your question, but isn't having all our kernel driver developers (from open and closed source teams) working on one kernel driver rather than two totally different ones likely to improve things ?

[Alejandro Nova]

Sou you mean once the switch to the radeon kernel module is made the "free" developer time does not have to be put into working on the radeon module for release-day support of new hardware and implementing missing features that fglrx supports, but radeon not? Still the same question, where would they magically get that time from if they don't even have the time for proper changelogs?

It's an interesting question. At least if part of the fglrx team ends contributing to the kernel upstream, you'll have your changelogs. But that doesn't answer the question.

The only real answer seems to be... let's wait and see...

[Vim_User]

Maybe I don't understand your question, but isn't having all our kernel driver developers (from open and closed source teams) working on one kernel driver rather than two totally different ones likely to improve things ?

Of course it will improve things. But some people (in this case Alejandro Nova) have posted the opinion that it will give free time for the Catalyst developers, for example to work on Mantle support, but there are things that simply have to be done first to even have the possibility to make this happen, like good support for the new R5/7/9 cards and in the future release-day support for new hardware (you can hardly say: we consolidate the driver development for the price that you can use new hardware in Linux half a year later). So there will be no free developer time for those developers, they simply have to work on the same things on a different kernel module.

[johnc]

Maybe I don't understand your question, but isn't having all our kernel driver developers (from open and closed source teams) working on one kernel driver rather than two totally different ones likely to improve things ?

Doesn't that mean that the 100% open source driver (the current Radeon) will die from lost resources?

To me I see this move as essentially giving up on the full open source driver. I don't necessarily think it's a bad move -- I prefer the binary blobs myself -- but it seems that many here who are beaming smiles aren't quite picking up on this subtle reality.

[bridgman]

Doesn't that mean that the 100% open source driver (the current Radeon) will die from lost resources?

To me I see this move as essentially giving up on the full open source driver. I don't necessarily think it's a bad move -- I prefer the binary blobs myself -- but it seems that many here who are beaming smiles aren't quite picking up on this subtle reality.

I don't understand the logic you're using -- you're basically saying "if I have M developers working on one kernel driver, and N developers working on another kernel driver, P developers working on the open source userspace stack and Q developers working on the closed source userspace stack, if both M and N work on the same kernel driver then P will go away ?

[johnc]

I don't understand the logic you're using -- you're basically saying "if I have M developers working on one kernel driver, and N developers working on another kernel driver, P developers working on the open source userspace stack and Q developers working on the closed source userspace stack, if both M and N work on the same kernel driver then P will go away ?

It wasn't really clear (or obvious): is it AMD's intention to make P go away (internally) and just provide a single driver option?

[Vim_User]

It wasn't really clear (or obvious): is it AMD's intention to make P go away (internally) and just provide a single driver option?

As I understand it it is AMD's intention to make both, P and Q, work on the radeon kernel driver, so that we have tow userspace drivers, but only one kernel driver.

[bridgman]

Exactly... well, I guess it depends on what you mean by "working". P and Q are development teams working on the userspace bits and they would *keep* working on their respective userspace bits, but those userspace bits would work on a common kernel driver. M and N are the kernel driver development teams.

The plan doesn't work without a good open source userspace stack.