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

  • #81
    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.

    Comment


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

      Comment


      • #83
        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.

        Comment


        • #84
          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.
          Test signature

          Comment


          • #85
            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

            Comment


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



              m saying ?
              You have lready said a: isn't going to happen, and b: requires contributions outside of AMD. So what does that leave? Pretty obvious huh? And for those of you that knew it already, it must have been obvious for a long time now.

              Yes, I'm responding to an article, but you must have known or intuited that this would be a problem a long time ago. You have and have had knowledge that I don't have. Of course I responded to an article. Your policy of trying to keep everything to yourself till the last second right before it backfires on you is part of that problem.

              Comment


              • #87
                We live a universe that abides fractal dynamics. What happens tends to happen. Outside developers don't tend to contribute to AMD's graphics drivers. AMD is itself responsible for bringing up the OSS drivers for their hardware. They've done a fantastic job at it and have developed top notch drivers for Linux. Expecting that suddenly things will change and AMD doesn't have to support their hardware because Option b: is available is pretty dumb considering that it almost certainly -won't- happen. If AMD is saying that they are relying on Option b:, then we all might as well forget about Vulkan on SI.

                EDIT: Like I already said the bottom line is out of box Vulkan support. Options a: and b: aren't going to happen. That leaves only c: and only AMD is in a position to make that happen.
                Last edited by duby229; 23 January 2016, 02:00 PM.

                Comment


                • #88
                  Originally posted by duby229 View Post
                  You have lready said a: isn't going to happen, and b: requires contributions outside of AMD. So what does that leave? Pretty obvious huh? And for those of you that knew it already, it must have been obvious for a long time now.
                  I have said that we have pretty much rejected (a) but I have emphatically NOT said that (b) requires contributions outside of AMD.

                  Where do you think you read that ?

                  Originally posted by duby229 View Post
                  Expecting that suddenly things will change and AMD doesn't have to support their hardware because Option b: is available is pretty dumb considering that it almost certainly -won't- happen. If AMD is saying that they are relying on Option b:, then we all might as well forget about Vulkan on SI.
                  Seriously, what makes you think option (b) means "AMD doesn't have to support their hardware" ? And again, what makes you think that option (b) has anything to do with relying on outside contributions ?
                  Last edited by bridgman; 23 January 2016, 01:55 PM.
                  Test signature

                  Comment


                  • #89
                    No, no and no. The most of as we don't care about Amdgpu, Radeon and what goes to what. We need zero day open source Vulkan support for all SM5 hardware (HD5-6 series included). If we can have that, then we may see some good native ports.

                    Comment


                    • #90
                      Originally posted by haagch View Post
                      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
                      Not sure what I'm failing to make clear here, but the problem with disabling radeon by default too quickly is that if any user picks up a new kernel build (Linus requires that new kernels be able to replace old kernels) and they aren't already running userspace that can transparently switch over to amdgpu then every user who does that gets broken.

                      It's not just a matter of talking to distros, although individual distros still might be good test cases before flipping the switch upstream.
                      Test signature

                      Comment

                      Working...
                      X