Announcement

Collapse
No announcement yet.

Trying AMDGPU-PRO 17.10 On Ubuntu 17.04

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

  • Trying AMDGPU-PRO 17.10 On Ubuntu 17.04

    Phoronix: Trying AMDGPU-PRO 17.10 On Ubuntu 17.04

    In early April AMD released the AMDGPU-PRO 17.10 driver as their first hybrid proprietary driver update in some time. With this update came support for Ubuntu 17.04.2 (and also 16.10, unofficially) but to little surprise it doesn't work out-of-the-box with this week's Ubuntu 17.04 release. But it can be made to work...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Typo:

    ​​​​​​
    Originally posted by phoronix View Post
    So then I fell back to Linux 4.8.0 from the Ubuntu Mainline Kernel PPA. Linxu 4.8 is what's used

    Comment


    • #3
      Originally posted by tildearrow View Post
      Typo:

      ​​​​​​
      Thanks
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        I don't understand what the point of a hybrid stack is if the driver package overrides the open source components of the hybrid stack in the first place. Wasn't the whole point so to improve distro integration by using the upstream components as packaged by the distro? Obviously that wasn't the point, but then wth was the point?

        Comment


        • #5
          Could anybody even download that driver for Ubuntu currently? It seems consistently broken here

          Just as info as i won't try it again, it does not work for me even on 16.04.2 with all default

          edit: nope, consistently show it wants to download 37.2 MB crap, while proper size should be 115.8 MB - cut at 1/3
          Last edited by dungeon; 16 April 2017, 01:13 PM.

          Comment


          • #6
            Originally posted by phoronix View Post
            With this update came support for Ubuntu 17.04.2 (and also 16.10, unofficially)​​​
            I guess you meant 16.04.2 there

            Comment


            • #7
              I think you meant AMD released a driver for 16.04.2.

              Also:
              Hopefully it won't take AMD too long before they officially support Ubuntu 17.04
              good one.

              Comment


              • #8
                Originally posted by duby229 View Post
                I don't understand what the point of a hybrid stack is if the driver package overrides the open source components of the hybrid stack in the first place. Wasn't the whole point so to improve distro integration by using the upstream components as packaged by the distro? Obviously that wasn't the point, but then wth was the point?
                Correct, that was not the point. The point was to avoid splitting resources between open and closed drivers, and have all of the Linux developers working on more or less the same code.

                Using more of the distro's built in components is definitely desireable and may happen over time, but it can't happen yet until more of the AMDGPU-PRO-specific code is able to get upstream - mostly DAL/DC and the IOCTL functionality used only by closed-source drivers at the moment.
                Test signature

                Comment


                • #9
                  Originally posted by bridgman View Post

                  Correct, that was not the point. The point was to avoid splitting resources between open and closed drivers, and have all of the Linux developers working on more or less the same code.

                  Using more of the distro's built in components is definitely desireable and may happen over time, but it can't happen yet until more of the AMDGPU-PRO-specific code is able to get upstream - mostly DAL/DC and the IOCTL functionality used only by closed-source drivers at the moment.
                  Well, I ure do hope it's a learning experience at minimum. We can all make stupid decisions, but only the wisest learn from them. I personally think the lesson that should be learned here is to develop your code in the public on the upstream repository from the first and -with- the people that are ultimately responsible for reviewing it. It's p[lainly obvious that what you are saying is that -because- you didn't develop your code with the upstream project, it contains code that the upstream project doesn't. And ultimately the upstream developers responsible for reviewing the code don't like it, which exacerbates the problem and stretches it out through time.

                  EDIT: In other words, you attempted to do less work, but the end result is that it doesn't work right and will end up as far more work.
                  Last edited by duby229; 16 April 2017, 01:32 PM.

                  Comment


                  • #10
                    Originally posted by duby229 View Post
                    Well, I ure do hope it's a learning experience at minimum. We can all make stupid decisions, but only the wisest learn from them. I personally think the lesson that should be learned here is to develop your code in the public on the upstream repository from the first and -with- the people that are ultimately responsible for reviewing it. It's p[lainly obvious that what you are saying is that -because- you didn't develop your code with the upstream project, it contains code that the upstream project doesn't. And ultimately the upstream developers responsible for reviewing the code don't like it, which exacerbates the problem and stretches it out through time.
                    With respect, you are kinda missing the point here. The Vulkan driver was built on top of pre-existing code which was never intended for Linux let alone for open sourcing, and the workstation GL driver was never intended to be open sourced. Neither of those were candidates for developing in public. We could have written a new driver from scratch rather than leveraging existing code but that would have meant shipping our first serious Vulkan driver now-ish rather than over a year ago.

                    The timeline for an open driver would have worked out roughly the same either way but we had a good Vulkan driver out there a year sooner, and IMO you are seeing the benefits of that in terms of games coming out now that use Vulkan.

                    The DAL/DC driver was largely developed in public but the upstream code base changed (eg atomic modesetting) more quickly than the team was able to keep up with. (apologies for the bad English but I wasn't able to think of a better way to word it)
                    Last edited by bridgman; 16 April 2017, 01:42 PM.
                    Test signature

                    Comment

                    Working...
                    X