The Slides Announcing The New "AMDGPU" Kernel Driver

[dungeon]

OK, I think this would make a lot more sense for you if you stopped calling it "unified opensource solution around blobs" since it is exactly the opposite

That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"

Yes, it means more developers working on the open source code, ie moving developer focus from closed source to open source for those components. Isn't that exactly what you wanted ?

Yes i like that generally if it serve for opensource driver, i don't care if it serve for blobs . I understand for you (and company) both might be the same (only for different kind of users), but for me - nope .

[dungeon]

Yes i like that generally if it serve for opensource driver, i don't care if it serve for blobs .

And more importantly what i think is that is true for the opossite - blob users also don't care about opensource one .

[agd5f]

so bridgeman, thx for some info, so there are coming some features to the free driver because of that unification, thats the "bribe" I talked/asked for.

And why would it be bad if the free driver would support opengl 4.0 too? sounded like that no opensource driver user need that

It will be great when the open source drivers support OpenGL 4.x, but it won't happen overnight. We have customers that need that functionality now and we have a driver tha supports it now, so it makes sense to enable that at least as an interim step.

Another question would be, if the old chips/cards or the current are not using this new architecture, first is that really the case, I get that there will be a seperate blob with its old kernel part, but will there really be 2 different radeon drm modules for older cards and newer?

And if thats really the case would it be really hard to backport some stuff from the new drm module to the old one?

For old hardware, the existing open source and clsoed source drivers will continue to work. For new hardware, there will be a new kernel driver and the existing userspace drivers will work with the new kernel driver. E.g., the mesa radeonsi driver will support both new and old kernel drivers and the same is the case for the closed source user space drivers.

[entropy]

Can you comment on what the expected advantages are for the open stack, having a shared kernel DRM driver?

[agd5f]

Can you comment on what the expected advantages are for the open stack, having a shared kernel DRM driver?

More AMD developers working on the shared kernel driver.

[droste]

That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"

Don't say "opensource users" when you actually mean "I"

[xeekei]

More AMD developers working on the shared kernel driver.

And AMD's whole Linux business relies on the kernel driver being uptodate and maintained. And since Linus won't allow stuff in the kernel that is only used by proprietary code, AMD will be forced to advance the open driver in pretty much the same pace as Catalyst. This is good.

[dungeon]

Don't say "opensource users" when you actually mean "I"

Ah well not only I, once when Debian package amdgpu driver and put it into right place, i will send you a link

[bridgman]

That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"

No, there are fewer blobs. Catalyst has always been there, you just weren't thinking about it before

blackiwid, remember why proprietary drivers exist in the first place -- they let vendors share big chunks of code across multiple OSes without leaking design info from those proprietary operating systems. That in turn lets vendors give you more features sooner without doubling or tripling the development costs.

There is no mandate that proprietary drivers *have* to be better, it's just that they get somewhat of a free ride compared to Linux-specific driver development so it's probably more correct to say they get a head start as a consequence of code sharing.

[entropy]

More AMD developers working on the shared kernel driver.

If it turns out to be synergetic, that sounds like an advantage.

One more question:

Is it realistic to assume that a rather large delta between the closed userspace part and kernel DRM will be supported?
For instance, a kernel 2-3 years older than the closed userspace part and vice versa?