Announcement

Collapse
No announcement yet.

AMD's Vulkan Driver Will Only Work With The AMDGPU Kernel Driver

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

  • haagch
    replied
    Or you can simply add support for SI in the amdgpu kernel driver and make it so that it can be disabled by a kernel config option, then disable radeon *by default* and put out a notice for distributions that they need to enable radeon and disable SI support in amdgpu as long as they do not ship libdrm+mesa with the new support.

    Or you can provide an installer for the user space drivers like intel does: https://01.org/linuxgraphics/downloa...er-linux-1.2.1

    Leave a comment:


  • bridgman
    replied
    Did you actually read anything I wrote ?

    First, there are a few different ways to achieve the goal you described, with the most obvious ones being (a) Vulkan over libdrm-radeon using radeon kernel driver, (b) Vulkan over libdrm-amdgpu using radeon kernel driver, (c) Vulkan over libdrm-amdgpu using amdgpu kernel driver... not just option (c) as you suggest.

    We will probably end up going with (c) but (b) lets us get there more quickly because we don't need to wait for new userspace to dribble out through distros onto user systems, so we have been exploring both options.

    Second, you think you are reacting to what we have actually been doing for the last year, but in fact you are just reacting to an article Michael wrote. Big difference.

    Originally posted by duby229 View Post
    But in this case if what you are saying ends up being what happens, and the fact that you've known about this for so long already means that those people that bought those cards were wronged by you.
    Um... what do you think I am saying ?
    Last edited by bridgman; 23 January 2016, 01:00 PM.

    Leave a comment:


  • duby229
    replied
    The bottom line will eventually be out of box vulkan support. You need in tree drivers for that. Which effectively means your only option is for amdpu to support all GCN cards. Work with the kernel developers. Don't let retarded political policies harm AMD. Bridman you are the man that can protect AMD from that harm, but you posts in this thread are chalk full of excuses. Come on. man!

    You guys must have known, or intuited that this would happen at least a year ago. What have you done to avoid or prevent it until now? Allowing political injustice is exactly the same thing as sabotage or incompetence. I personally don't have a problem with rebranding. But in this case if what you are saying ends up being what happens, and the fact that you've known about this for so long already means that those people that bought those cards were wronged by you.
    Last edited by duby229; 23 January 2016, 11:44 AM.

    Leave a comment:


  • duby229
    replied
    Damn it, I truly hate VB5. I wrote a few posts in reponse to Bridgman. But they got caught in the moderation que.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    With respect, perhaps you don't understand what I'm saying. The *only* thing I am associating with Linus's policies is the *current* upstream default driver for SI and CI hardware. I have never said *anything* which ties Vulkan support to upstream default support, other than saying multiple times that Michael was drawing a connection where none actually existed. Can you please be a bit more specific about why you think I am blaming (or even hinting) that Vulkan support has anything to do with which driver is enabled upstream by default today ? Thanks.



    Can you use different words here ? I have no idea what you are trying to say.



    No, we're all saying pretty much the same thing, but you (and others) are mixing comments about libdrm level interfaces with comments about kernel drivers (and yes if I were king they would either have different names or fully qualified hierarchical names ).

    Vulkan is definitely only going to be supported on the libdrm-amdgpu userspace interface, not libdrm-radeon or the Catalyst equivalent. The libdrm-amdgpu interface library currently only runs over the amdgpu kernel driver, but we could also run it over the radeon kernel driver if that made more sense (or gave us a better short term solution) than adding SI support to amdgpu. We have been looking at both options in parallel with development of the Vulkan driver.



    You are missing the point again. We can't just remove support from radeon and break every user out there when they upgrade their kernel. First we have to get userspace code which can seamlessly run over either driver on SI/CI hardware, then wait until that code gets out to most users and have a transition/messaging plan for the rest, and *then* we can start looking at switching. I have said this many many times in the last week.

    We have CI code in amdgpu kernel driver today, which makes sense because CI and VI chips are relatively similar from a programming perspective. We do not have SI code in amdgpu kernel driver today, because NI and SI chips are relatively similar from a programming perspective and so it makes most sense to keep them on radeon.

    Using radeon gives us the ability to run immediately on upstream and in-distro kernels, and gives us a known-quality driver stack for all of the other functionality. Using amdgpu on SI/CI means (apart from the porting effort) that to some extent we are starting from scratch in terms of dealing with individual board/system gotchas (you can port quirk code but you can't port "writing the code the way we did just happened to work for those SKUs") and forces us to deploy the kernel drivers out-of-tree for probably 6 months, but also means we get to deal with a single interface for the usermode drivers.

    The big breaking news here is not "AMD isn't supporting XYZ", it's "AMD chose not to answer all of Michael's questions immediately so he made some guesses and people misinterpreted what he wrote".
    You guys don't have a choice, you -must- get together with the kernel team and figure out some method to ensure that all GCN hardware will in fact be supported by Vulkan. That requires amdgpu. The bottom line -is- Vulkan support.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    With respect, perhaps you don't understand what I'm saying. The *only* thing I am associating with Linus's policies is the *current* upstream default driver for SI and CI hardware. I have never said *anything* which ties Vulkan support to upstream default support, other than saying multiple times that Michael was drawing a connection where none actually existed. Can you please be a bit more specific about why you think I am blaming (or even hinting) that Vulkan support has anything to do with which driver is enabled upstream by default today ? Thanks.



    Can you use different words here ? I have no idea what you are trying to say.



    No, we're all saying pretty much the same thing, but you (and others) are mixing comments about libdrm level interfaces with comments about kernel drivers (and yes if I were king they would either have different names or fully qualified hierarchical names ).

    Vulkan is definitely only going to be supported on the libdrm-amdgpu userspace interface, not libdrm-radeon or the Catalyst equivalent. The libdrm-amdgpu interface library currently only runs over the amdgpu kernel driver, but we could also run it over the radeon kernel driver if that made more sense (or gave us a better short term solution) than adding SI support to amdgpu. We have been looking at both options in parallel with development of the Vulkan driver.



    You are missing the point again. We can't just remove support from radeon and break every user out there when they upgrade their kernel. First we have to get userspace code which can seamlessly run over either driver on SI/CI hardware, then wait until that code gets out to most users and have a transition/messaging plan for the rest, and *then* we can start looking at switching. I have said this many many times in the last week.

    We have CI code in amdgpu kernel driver today, which makes sense because CI and VI chips are relatively similar from a programming perspective. We do not have SI code in amdgpu kernel driver today, because NI and SI chips are relatively similar from a programming perspective and so it makes most sense to keep them on radeon.

    Using radeon gives us the ability to run immediately on upstream and in-distro kernels, and gives us a known-quality driver stack for all of the other functionality. Using amdgpu on SI/CI means (apart from the porting effort) that to some extent we are starting from scratch in terms of dealing with individual board/system gotchas (you can port quirk code but you can't port "writing the code the way we did just happened to work for those SKUs") and forces us to deploy the kernel drivers out-of-tree for probably 6 months, but also means we get to deal with a single interface for the usermode drivers.

    The big breaking news here is not "AMD isn't supporting XYZ", it's "AMD chose not to answer all of Michael's questions immediately so he made some guesses and people misinterpreted what he wrote".
    You are wrong on this. As soon as Vulkan gets released a ton of people will wiggle out of the sand and throw massive hissy fits as soon as they realized that their GCN hardware isn't supported. It's going to backfire on you hard. You have a chance to do something about that before it actually happens, but it doesn't sound like you want to.

    Leave a comment:


  • Espionage724
    replied
    Originally posted by bridgman View Post
    .... aaaaand I've been moderated again. Bleah.

    Maybe this is why people are tweeting instead of using forums.

    EDIT - post above has now appeared.
    I wonder what actually triggers the moderation... Somehow this post by a new user externally linking and showing the usual signs of a spam post went right on through the filter http://www.phoronix.com/forums/forum...support-number (Edit: It was some lengthy Yahoo scam support phone thing) and yet there's people with years of history and hundreds of posing being moderated for legitimate discussion.
    Last edited by Espionage724; 22 January 2016, 04:04 PM.

    Leave a comment:


  • Kano
    replied
    @bridgman

    You have to support AMDGPU via DKMS anyway if fglrx relies on it. Interesting would be the libdrm part, does the new implementation need that too?

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by DDF420 View Post
    You need new hardware for Vulkan

    Windows gamer ........... Shouldn't be a problem i upgrade my hardware every second year at the most

    Linux gamer........... We have been betrayed,those bastards are not supporting my 10 year old graphics card,sound the call to arms.
    This.

    Otherwise, NVIDIA was a fairly solid bet, I'd say. NVIDIA is said to support Vulkan and DirectX12 on everything from old Fermi GPUs to the latest Maxwell cards.

    Leave a comment:


  • DDF420
    replied
    You need new hardware for Vulkan

    Windows gamer ........... Shouldn't be a problem i upgrade my hardware every second year at the most

    Linux gamer........... We have been betrayed,those bastards are not supporting my 10 year old graphics card,sound the call to arms.

    Leave a comment:

Working...
X