Announcement

Collapse
No announcement yet.

Running The AMD Radeon R9 Fury With AMD's New Open-Source Linux Driver

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

  • Running The AMD Radeon R9 Fury With AMD's New Open-Source Linux Driver

    Phoronix: Running The AMD Radeon R9 Fury With AMD's New Open-Source Linux Driver

    Now that Linux 4.2 is set to be released today, out on the horizon we have to look forward to Linux 4.3 kernel. Set to be merged into Linux 4.3 will be in the initial open-source AMD driver code for supporting the Radeon R9 Fury graphics cards. This open-source Fury support is the focus of our testing today with it being the first time powering up this Fiji GPU outside of Catalyst.

    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
    As always you should buy what has currently working drivers and Fiji isn't there yet. Catalyst isn't a solution for desktop users. If you are using any AMD product on any desktop environment, you should be using OSS drivers. Fiji looks good, it just needs more time for the drivers to get finished. I'm still hoping and praying that AMD can figure out a strategy to get launch day OSS driver support working for future new generation hardware launches.

    Comment


    • #3
      Originally posted by duby229 View Post
      I'm still hoping and praying that AMD can figure out a strategy to get launch day OSS driver support working for future new generation hardware launches.
      IIRC we had already reached that point with CI. The transition to amdgpu took a lot of work though, and that delayed support for VI (Iceland/Topaz, Tonga, Fiji).

      We should be caught up again for next gen though.

      it was mentioned by John Bridgman of AMD that there is no legal/IP issues blocking the open-source power management support for these newer graphics processors. The issue is not enough developer resources... "The issue is writing the code and getting it working."
      It's not a "number of developers" issue, just that this time we spent the developer effort for IP review earlier than usual, so rather than waiting for IP review you're waiting for the code to be written. The only point I was trying to make was that there shouldn't be anything like the usual IP delay once we have the code working internally.
      Last edited by bridgman; 30 August 2015, 01:28 PM.
      Test signature

      Comment


      • #4
        For VI users, new release of my livecd included amdgpu support(llvm 3.8, kernel 4.2-rc8, mesa 11.1-devel, xf86-video-amdgpu, all firmwares).
        Gputests and lightsmark available out of the box.

        Comment


        • #5
          Originally posted by duby229 View Post
          As always you should buy what has currently working drivers and Fiji isn't there yet. Catalyst isn't a solution for desktop users. If you are using any AMD product on any desktop environment, you should be using OSS drivers. Fiji looks good, it just needs more time for the drivers to get finished. I'm still hoping and praying that AMD can figure out a strategy to get launch day OSS driver support working for future new generation hardware launches.
          I agree that you should only buy what has proven working drivers, and I strongly feel the open source drivers should be used. I've been using the open source drivers for a long time and in my experience they're fantastic. Now that OGL 4.0, 4.1, and 4.2 are supported (at least for radeonSI), they're even more appealing.

          I'm sure AMD will get release-day drivers working (or at least close to it) once they catch up with everything else. As the article states, the AMD open source staff is small and struggling to keep up with the workload. Personally, I kind of wish AMD would step away from adding GL specifications to mesa and let Intel take care of that. That being said, I'm a little suspicious why intel is so slow to get things done. Their hardware is simpler, they've had a HUGE head start with their linux drivers, their linux team is relatively large, and nobody is expecting good performance from them. Intel could single-handedly complete mesa if they really wanted to.
          Last edited by schmidtbag; 30 August 2015, 01:31 PM.

          Comment


          • #6
            In fact most people should -only- use the OSS drivers. If you use a desktop environment, then you should be using the OSS drivers.

            EDIT: I don't agree that Intel should single handedly write OpenGL specs. That's their biggest problem, they got stuck on a "We must stand alone" mentality. And it's hurting the rest community, it doesn't need to be worse.
            Last edited by duby229; 30 August 2015, 12:49 PM.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Personally, I kind of wish AMD would step away from adding GL specifications to mesa and let Intel take care of that.
              If anything I think our devs would like to do more rather than less -- at the moment we are mostly adding GL level support to the HW-specific driver not the common code.

              Originally posted by schmidtbag View Post
              That being said, I'm a little suspicious why intel is so slow to get things done. Their hardware is simpler, they've had a HUGE head start with their linux drivers, their linux team is relatively large, and nobody is expecting good performance from them. Intel could single-handedly complete mesa if they really wanted to.
              I don't think the intel devs would agree about their hardware being simpler. My impression (from various developer rants) is that NVidia HW is the easiest to program, AMD/ATI is somewhat more difficult, and Intel maybe even more so. They do have fewer SKUs and don't need to worry about separate fast device memory though, which is nice.
              Last edited by bridgman; 30 August 2015, 01:34 PM.
              Test signature

              Comment


              • #8
                Originally posted by duby229 View Post
                In fact most people should -only- use the OSS drivers. If you use a desktop environment, then you should be using the OSS drivers.
                Whoops I actually misread part of your original post, but it seems we're on the same page anyway.
                EDIT: I don't agree that Intel should single handedly write OpenGL specs. That's their biggest problem, they got stuck on a "We must stand alone" mentality. And it's hurting the rest community, it doesn't need to be worse.
                Mesa is open source. What difference does it make if only one company contributes to it if all the other drivers will benefit from that code? Also, what exactly has intel done that's hurt the community? I'd say they've improved it more than hurt it. Nvidia, on the other hand, I know has been a burden.

                Originally posted by bridgman
                If anything I think our devs would like to do more rather than less -- at the moment we are mostly adding GL level support to the HW-specific driver not the common code.
                I understand that, but there are AMD-specific issues that have yet to be completed. GL specifications apply to all brands, so if Intel (who has sufficient manpower) were to code that themselves, AMD's devs can use their resources to work on things no other company has any obligation to work on. I'm happy with AMD getting as much as they have got done and I won't complain about them working on things, I personally just feel AMD's priority should be issues specific to them.
                Last edited by schmidtbag; 30 August 2015, 01:43 PM.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  Whoops I actually misread part of your original post, but it seems we're on the same page anyway.

                  Mesa is open source. What difference does it make if only one company contributes to it if all the other drivers will benefit from that code? Also, what exactly has intel done that's hurt the community? I'd say they've improved it more than hurt it. Nvidia, on the other hand, I know has been a burden.
                  I could mention beigenet for one, which ultimately stems from their refusal to move on to gallium. And their OpenMP code for two, which which ultimately stems from Xeon Phi essentially being x86.

                  EDIT:
                  Originally posted by schmidtbag View Post
                  I understand that, but there are AMD-specific issues that have yet to be completed. GL specifications apply to all brands, so if Intel (who has sufficient manpower) were to code that themselves, AMD's devs can use their resources to work on things no other company has any obligation to work on. I'm happy with AMD getting as much as they have got done and I won't complain about them working on things, I personally just feel AMD's priority should be issues specific to them
                  Thing is, OpenGL is not exactly a one size fits all type thing. There are a lot of hardware specific functions that vary from one architecture to the next. Plus all the vendor specific extensions on top of that. It's up to game designers to make sure they implement their code using the OpenGL specs the way they are intended. And it's up to the driver developers to make sure that they implement the specs as closely possible. And it varies from one architecture to the next and one vendor to the next.
                  Last edited by duby229; 30 August 2015, 02:02 PM.

                  Comment


                  • #10
                    Michael, thanks for all the benchmarks. These AMDGPU benches had finally made me subscribe to premium.

                    Also, can anyone explain how the AMDGPU and Catalyst are going to interact with Mesa in the picture? I seem to either forgotten or missed it somewhere. Is the idea to have Mesa/Catalyst be something the user can switch? So the AMDGPU is a framework where a User-space OpenGL implementation is plugged in to?

                    Comment

                    Working...
                    X