RADV Starts Off Another Exciting Week Of Development

[smitty3268]

And if not details, may be some rough ETA for completing this tedious process?

Don't expect it anytime soon. I think they're focusing on OpenCL right now, and that may take the rest of the year. Vulkan is likely 2018 at the earliest, assuming there's still any point by then.

[gurv]

bridgman why do you never answer anything related to open sourcing the Vulkan driver or adopting RADV?
I may very well be worrying for nothing, but I get the feeling AMD dropped any plan to do open source work on Vulkan (can't see the reason though, so I'm confused right now)

[bridgman]

I do answer, but if I don't have information I can release there isn't much I can say. That's not the same as not answering.

What I can say is same as before, (a) work is proceeding on it and (b) we are discussing options for dealing with radv vs our implementation.

[gurv]

Ah great, thanks for answering!
I must not have paid enough attention in that case.
Good to know it's still worked on anyway

[bridgman]

Not sure I agree. This is a similar situation to Gallium3D - yes the driver is smaller and simpler but the part that's gone is the common code. That is hard to write the first time and does need some ongoing optimization, but to a large extent it is reuseable across multiple GPUs and vendors.

The shareable, re-useable common code goes into the game engine or app, but most of the HW-specific code does not. The only exception there is that high level synchronization mechanisms get replaced with lower level ones, typically again requiring HW specific work.

With that gone, all that's left is the HW-specific code which is arguably the hardest part to maintain since every new generation needs new (or at least different) code. There is some ability to share code with Mesa GL (mostly the compiler) but I don't think writing the driver is as easy as you suggest.

[indepe]

With that gone, all that's left is the HW-specific code which is arguably the hardest part to maintain since every new generation needs new (or at least different) code. There is some ability to share code with Mesa GL (mostly the compiler) but I don't think writing the driver is as easy as you suggest.

This also seems true in so far as AMD's Vulkan driver is much faster than RADV, although that might be just because RADV is very much work in progress.

Hopefully at some point AMD will open source its driver so that both can learn from each other, if not join in some way.

[indepe]

This also seems true in so far as AMD's Vulkan driver is much faster than RADV, although that might be just because RADV is very much work in progress.

Hopefully at some point AMD will open source its driver so that both can learn from each other, if not join in some way.

If Vulkan does a good job of separating the HW-specific code from the common code, that should be huge benefit for both AMD and open source Linux.