Announcement
Collapse
No announcement yet.
RADV: A Community Open-Source Effort To Get Vulkan Working On Radeon
Collapse
X
-
Originally posted by stqn View Postthe 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
Comment
-
Originally posted by bridgman View Post
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.
Comment
-
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.
Originally posted by schmidtbag View PostBut here's what I don't get - why not nouveau?
Comment
-
Originally posted by ossuser View Post@bridgman: Could you tell us some more, what type of problem is this ?
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.
Comment
-
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.Stop TCPA, stupid software patents and corrupt politicians!
Comment
-
Originally posted by pal666 View Postso 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
Comment
-
Originally posted by starshipeleven View PostHe 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.
If you follow the mailing list, you'll see patches by Marek referring to the Vulkan driver. So what is the big deal?
Comment
-
Originally posted by bridgman View PostI'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.
- Likes 1
Comment
Comment