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

  • #71
    Well, after reading this thread, I'm personally convinced that if AMD doesn't support Vulkan on -all- GCN cards, there will be an explosive backfire. And I think bridgmans excuse of blaming it on linus is asinine.

    EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.

    EDIT: So we've got multiple AMD employees saying multiple incompatible things. One says Vulkan will only work on amdgpu, another says only GCN 1.2 and up will be supported on amdgpu (and blames that on linus torvalds), another says amdgpu will support older GCN revisions out of tree eventually.....

    Come on AMD. You can do better. (Fuck the out of tree bullshit. Fuck the blame game on linus bullshit.) Put -ALL- GCN support in amdgpu and get it upstreamed. If that requires removing GCN support from radeon, then that is exactly what it requires.
    Last edited by duby229; 21 January 2016, 01:01 PM.

    Comment


    • #72
      Most Devs will not support Vulkan or DX12 if it works only on GCN and Kepler+ GPUs, they need support for HD5-6 series and Fermi. Even today, most of them have D3D9 legacy support, eventually legacy will be replaced with D3D10. They all say that they need Vulkan and D3D12 for all SM5 GPUs. So the best will be an extension to Amdgpu to support Radeon IOCTLs (HD5-6 series not excluded).

      Comment


      • #73
        Originally posted by duby229 View Post
        Well, after reading this thread, I'm personally convinced that if AMD doesn't support Vulkan on -all- GCN cards, there will be an explosive backfire. And I think bridgmans excuse of blaming it on linus is asinine.
        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.

        Originally posted by duby229 View Post
        EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.
        Can you use different words here ? I have no idea what you are trying to say.

        Originally posted by duby229 View Post
        EDIT: So we've got multiple AMD employees saying multiple incompatible things. One says Vulkan will only work on amdgpu, another says only GCN 1.2 and up will be supported on amdgpu (and blames that on linus torvalds), another says amdgpu will support older GCN revisions out of tree eventually.....
        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.

        Originally posted by duby229 View Post
        Come on AMD. You can do better. (Fuck the out of tree bullshit. Fuck the blame game on linus bullshit.) Put -ALL- GCN support in amdgpu and get it upstreamed. If that requires removing GCN support from radeon, then that is exactly what it requires.
        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".

        Comment


        • #74
          *bridgman bangs head on screen since EVERY SINGLE STINKIN' LONG-ENOUGH-TO-BE-USEFUL POST GETS MODERATED !!!!!

          Guess I do need to start saving before I post... if nothing else it would be interesting to see if the same text posted multiple times gets moderated every time...
          Last edited by bridgman; 21 January 2016, 06:56 PM.

          Comment


          • #75
            Originally posted by bridgman View Post
            *bridgman bangs head on screen since EVERY SINGLE STINKIN' LONG-ENOUGH-TO-BE-USEFUL POST GETS MODERATED !!!!!

            Guess I do need to start saving before I post... if nothing else it would be interesting to see if the same text posted multiple times gets moderated every time...
            I never type extensive posts directly into the browser. Once I get past a couple paragraphs, I switch to a real text editor and paste it back to the browser when I'm done. There's also a browser extension called "it's all text" that does this automatically, but it doesn't work for websites that use customized javascript-infested text entry fields.

            Comment


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

              Comment


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

                Comment


                • #78
                  @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?

                  Comment


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

                    Comment


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

                      Comment

                      Working...
                      X