Announcement

Collapse
No announcement yet.

RADV Starts Off Another Exciting Week Of Development

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • indepe
    replied
    Originally posted by indepe View Post

    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.

    Leave a comment:


  • indepe
    replied
    Originally posted by bridgman View Post
    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.

    Leave a comment:


  • bridgman
    replied
    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.
    Last edited by bridgman; 01 February 2017, 12:56 PM.

    Leave a comment:


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

    Leave a comment:


  • bridgman
    replied
    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.
    Last edited by bridgman; 31 January 2017, 10:48 AM.

    Leave a comment:


  • gurv
    replied
    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)

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shmerl View Post

    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.

    Leave a comment:


  • indepe
    replied
    Originally posted by bridgman View Post

    ... or until we (or someone) port the audio code from radeon to amdgpu (for SI).
    Generally it seems that all the code anyone is asking for, already exists in some place(s)....

    Leave a comment:


  • bridgman
    replied
    Originally posted by Qaridarium
    best example for this they write to you about a AMDGPU-pro bug and you write back they should write a AMDGPU/Radeon bug-report because the time-pipe process of bug-fixing in the closed driver is "2-4 month" at minimum. and people are really confused by this ... the open driver do have bug-fix pipe timeline of maybe 1-2 days. I had such bug's and bugrepots and bugfixes in the past.
    If the problem is in common code between open and hybrid drivers (which initially seemed to be the case assuming you are talking about discussion with Amarildo) then why not use the open source development process to fix it ?

    Please don't use quotation marks ("2-4 month") to suggest I said something that I did not. As always, feel free to quote what I actually say though, as long as it is not taken out of context.

    For example, quoting me saying "yes" but implying it was my response to a different question would not be acceptable
    Last edited by bridgman; 30 January 2017, 03:58 PM.

    Leave a comment:


  • pal666
    replied
    Originally posted by Xicronic View Post
    At this rate, AMD open-sourcing their Vulkan driver is going to be near-pointless.
    pointlessness works both ways

    Leave a comment:

Working...
X