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

[Vim_User]

Exactly... well, I guess it depends on what you mean by "working".

Should have been more clear about that, what I actually meant was: The software developed by P and Q is planned to work on the base of one open source kernel driver.

[johnc]

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.

I stand corrected in my error and thank you for clarifying.

In that case I do agree that it is a good path forward, as it seems it would improve the situation for both camps.

[iznogood]

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 ?

Indeed this is true, but userspace is equally important. What is going to happen with the mesa stack? Are you planning to contribute to that too? This won't be needed, but clearly catalyst works much worse than the open source driver.
And what about the secret optimizations? Aren't there any in the kernel code that you are going to loose?
And why this now, when the open source driver is so good and finished in so many features? Are you dropping the open source driver?

[tuubi]

Yeah, about that... My GTX 660 is tearing like crazy, no matter the options set. In fact it's tearing this very page when I merely scroll. So no, it's not worse than NVIDIA in the slightest.

Use a (OpenGL based) compositor and your tearing disappears, as long as you've enabled vsync in the NVIDIA settings. Personally I run compton with Xfce to get a tearfree experience.

[smitty3268]

...

Come on, read the article and use some common sense.

What is going to happen with the mesa stack?

Nothing. No change to Mesa was discussed here, so the same things that are going on now will continue to go on, just as they have been.

Are you planning to contribute to that too?

They already are, through their OSS team. There was no change to that being discussed anywhere, so there would still be a separate OSS team working on Mesa, and closed source team working on fglrx userspace. They'd just share the same kernel driver.

This won't be needed, but clearly catalyst works much worse than the open source driver.

For desktop users, yes. For AMD's commercial clients, no. At least not yet.

And what about the secret optimizations? Aren't there any in the kernel code that you are going to loose?

According to the article - which you should have read - there are not. They are all in the userspace code.

And why this now, when the open source driver is so good and finished in so many features?

Exactly because of that. It's only now that the radeon kernel driver is in good enough shape that they can consider using it. Perhaps in the future the userspace side of the driver will become good enough they can use that, too, and just drop fglrx entirely on linux, but it isn't there yet like the kernel portion is.

Are you dropping the open source driver?

No, and such a thing was never mentioned, or even slightly hinted at anywhere at all. I have no idea where you are getting such ideas from.

[Nille]

Are you planning to contribute to that too?

AMD still Support the FOSS-Driver. and Drop this support would mean that the Radeon Kernel Module get removed or don't get any new changes

[_ONH_]

@bridgman

Isn't it that simple that a catalyst opengl stack developer, should document its work indpendent of the os.
If he fixes a OpenGl function that behaves not like specified by Koronos then could mark it in the database that it was changed.
As I experienced in the mechanical engeneering the work is documented anyway, and through that it wold just be an other check mark to mark the change summary to be included in a changelog.
To keep special customers changes out of the changelog the mark could simply not getting checked.
In the end the user wouldn't know which game was changed but the linux people would feel not so second class people.
With the linux oss driver there is always a short summary what was changed in a changeset.
I don't see where the big time penalty would be to introduce that in the changelog.

[smitty3268]

With the linux oss driver there is always a short summary what was changed in a changeset.
I don't see where the big time penalty would be to introduce that in the changelog.

It's completely ridiculous that such a thing would take more than 30 seconds for someone to write, just by going through the svn log, or whatever system they use.

On the other hand, i also think it's pretty silly to need one. The only people it would really help would be michael, so he could just copy/paste it into an article every month. For most users, you just try out fglrx and see if if works for you or not, and if you have something in particular you are wondering about you just try the new version or get on here and ask people if it's been fixed. Adding a change log to each driver release isn't going to change that.

[GreatEmerald]

Use a (OpenGL based) compositor and your tearing disappears, as long as you've enabled vsync in the NVIDIA settings. Personally I run compton with Xfce to get a tearfree experience.

So what part of "no matter the options set" did you not get?

[tuubi]

So what part of "no matter the options set" did you not get?

Ah, didn't realize you consider installing and using a dedicated compositor an "option" you can just set, and that might be required depending on your window manager. Never mind then, just trying to be helpful.