RADV: A Community Open-Source Effort To Get Vulkan Working On Radeon

[pal666]

But here's what I don't get - why not nouveau? They need all the help they can get. Instead, you're focusing on giving Vulkan support to GPUs that already have it

because amd deserves help and nvidia doesn't, obviously

[pal666]

I don't trust such announcements until I see the actual code release.

do you trust code releases which draw one triangle on one card?

[pal666]

the AMD blob is said to be more trouble than the FOSS driver, and I don’t feel like switching drivers depending on the application/game I want to run

so much garbage in your reasoning. amd fglrx blob was differen userspace code and different kernel code. amd vulkan blob is all-new userspace code which is intended to be opensourced(so how can this same code after opensourcing be more trouble than open source code? ) and it uses foss kernel driver. and it does not require switching ffs, you can use foss kernel, foss opengl and blob vulkan simultaneously

[ossuser]

I'm hoping for the opposite actually... my first thought when I heard about the project was that rather than working on solutions to replace the parts of our Vulkan stack that we can't open in their current form we could shift focus to the pieces we *can* open and work on integrating those into the project.

@bridgman: Could you tell us some more, what type of problem is this ?

[Nille_kungen]

I though that OpenGL 4,5 would be finished first and maybe some more R600 extensions but vulkan was going to happen anyways it's only a little bit sooner then i expected.
I do think that it's time to start working on vulkan support before it's widely used so thumbs up.

But here's what I don't get - why not nouveau?

Dave have already answered but i still think you should ask one of RedHat's nouveau developers why they doesn't put more energy into vulkan support, but i think the answer would be that there's much work needed prior to that on nouveau.

[starshipeleven]

@bridgman: Could you tell us some more, what type of problem is this ?

He already told it.
The current closed driver shares most of its feature code with other platforms (i.e. windows) as that's what closed source drivers do, they are vendor-specific and (if needed) cross-platform.
Opensource drivers in linux (the best ones anyway) are the reverse of that, they are platform-specific (linux) but multi-vendor (as most of the heavy lifting is in Mesa/Gallium which is shared).

So even if they could drop open code from their current closed blob, it would be like the current DAL situation, a huge monster that isn't using ANYTHING of opensource infrastructure and needs to be beaten into shape for months before it is fit for integration.

So it makes more sense to rewrite from scratch the parts that would still have to be basically rewritten from scratch, and opensource only the specific parts of the closed driver that would benefit the open driver at all.

[Adarion]

Seems fine to me. The unstoppable airlied is at it again, AMD is ready to jump in once they got their stuff through internal reviews and cleanups. And if airlied provides a good basement and AMD cooperates then with their stuff that would be aweseome. Might even shorten the whole development time until we have a user-usable release.
The only bad thing about it is me not having the money to buy a GCN 1.2+ dGPU right now.

[Krejzi]

so much garbage in your reasoning. amd fglrx blob was differen userspace code and different kernel code. amd vulkan blob is all-new userspace code which is intended to be opensourced(so how can this same code after opensourcing be more trouble than open source code? ) and it uses foss kernel driver. and it does not require switching ffs, you can use foss kernel, foss opengl and blob vulkan simultaneously

Actually, I don't think you can do this yet. If I recall correctly, someone (bridgman?) mentioned that the amdgpu kernel code shipped with amdgpu-pro isn't really the same amdgpu from latest drm tree. It contains pieces for vulkan and opencl, which can't be integrated upstream without userspace (policy?).

[log0]

He already told it.
The current closed driver shares most of its feature code with other platforms (i.e. windows) as that's what closed source drivers do, they are vendor-specific and (if needed) cross-platform.
Opensource drivers in linux (the best ones anyway) are the reverse of that, they are platform-specific (linux) but multi-vendor (as most of the heavy lifting is in Mesa/Gallium which is shared).

So even if they could drop open code from their current closed blob, it would be like the current DAL situation, a huge monster that isn't using ANYTHING of opensource infrastructure and needs to be beaten into shape for months before it is fit for integration.

So it makes more sense to rewrite from scratch the parts that would still have to be basically rewritten from scratch, and opensource only the specific parts of the closed driver that would benefit the open driver at all.

You have two devs interested in working on it. I bet they would have made much more progress, than rendering a triangle, if the closed Vulkan driver was available as reference.

If you follow the mailing list, you'll see patches by Marek referring to the Vulkan driver. So what is the big deal?

[chithanh]

I'm hoping for the opposite actually... my first thought when I heard about the project was that rather than working on solutions to replace the parts of our Vulkan stack that we can't open in their current form we could shift focus to the pieces we *can* open and work on integrating those into the project.

Do it like Sun when they open sourced Java: Release all the things you can open source, and let the community figure out how to plug the holes.