The Slides Announcing The New "AMDGPU" Kernel Driver

[phoronix]

Phoronix: The Slides Announcing The New "AMDGPU" Kernel Driver

Today to kick off XDC, AMD announced its rolling with its new Linux driver model that includes the development of a new kernel DRM driver...

http://www.phoronix.com/vr.php?view=MTgwODA

[89c51]

Will this lead to an only Open driver in the future. I mean there is no point in maintaining two different drivers (i am leaving pro outside) once mesa reaches feature parity with the closed one. And hopefully OpenGL next will be open only.

[nanonyme]

I do hope they're not heading towards the trap of implementing interfaces usable only with closed drivers and getting kicked out of kernel

[DIRT]

Im here to debug and drink mtdew, and I'm all out of mtdew.

Way to go amd! If the new drivers perform in every other game as good as they do in valve games, I'm definitely going to by amd hardware for my next build. Have an old phenom II x4. Want to upgrade.

[entropy]

I like the general idea!

However, how big is the chance this attempt will be rejected?

I mean, it's basically officially intended to serve as a shim layer.
Please correct me, but AFAIK that's not allowed in the mainline tree.
IMHO that's sufficiently different compared to the current AMD/Nvidia
glue-code approach to cause troubles.

[Ardje]

I already was impressed with the quality of the radeon drivers (having finished metro last light with the radeon drivers, because it would not run on fglrx).
This development only proves that I have chosen right with my wallet.
Although I just replaced my 2x Vapor-X HD-4890 with a single R9-270, I would happily buy an R9-300 if that means running the latest and greatest and being able to switch back and forth between fglrx and open radeon amdgpu drivers.

[Dukenukemx]

I'm not sure if this should make me happy or upset?

[bridgman]

I like the general idea!

However, how big is the chance this attempt will be rejected?

I mean, it's basically officially intended to serve as a shim layer.
Please correct me, but AFAIK that's not allowed in the mainline tree.
IMHO that's sufficiently different compared to the current AMD/Nvidia
glue-code approach to cause troubles.

Why do you say "intended as a shim layer" ? AFAIK this is exactly the opposite.

[entropy]

Why do you say "intended as a shim layer" ? AFAIK this is exactly the opposite.

I guess that may concern the "Please correct me" part.

However, this module is now officially announced to (also) interact with a blob.
So some interfaces need to be exported with EXPORT_SYMBOL, right?

Is it safe to assume this will be ok for the relevant kernel people?
I don't say it isn't - just asking.
Maybe there is no issue at all...

Edit: Or ist that the blob is userland only?

[uid313]

Sounds like a good case for interfaces and abstract base classes.

But you can't use C++ in the kernel, its only C.