Announcement

Collapse
No announcement yet.

A Number Of Radeon & AMDGPU Fixes Queue Up For Linux 4.6

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

  • #11
    I wonder what distro can you get with a recent kernel release.
    I'm on Xubuntu and it is on 3.16.

    I really like the idea of OEM AMD drivers being embedded in the kernel and not having to poke them in myself (with bad results sometimes)
    I'm currently on 15.02 of the FLGRX driver and it's performance on my HD7870 is pretty sad considering it was blazing fast in windows and I played everything on high settings at 1080p.

    Comment


    • #12
      Originally posted by Detructor View Post
      radeonsi is MESA stuff and obviously has a config UI.
      And how is that UI called?

      Originally posted by Detructor View Post
      And the closed-source userspace driver for the AMDGPU kernel-driver will most probably have it's own UI.
      Why can't the open-source amdgpu driver use the same GUI as the closed-source amdgpu-pro driver?

      I thought amdgpu-pro is kind of an "add-on" for amdgpu?

      Why don't we get the Radeon Software GUI for Linux?

      Radeon Software is even using Qt, isn't it?

      Boggles me why Windows gets a Qt based GUI whereas Linux does not...

      bridgman and agd5f :

      Could you say something about this, so that I do not need to "spam the bug tracker", like I already did for Intel by the way:



      ?

      Comment


      • #13
        Originally posted by bridgman View Post
        The way things are going I think we're likely to see code before we see a roadmap, which is the opposite of what I was expecting a couple of weeks ago. There are a lot of other projects being planned at the same time for the same set of developers so we can't really set dates for one project until the others are worked out as well. That doesn't interfere with working on the code in the short term though...
        Thanks for the update! I agree, I've not seen you post a roadmap for SI support, only the "ask again in a week" statement.

        Personally, I'd rather see something closer to production-ready for VI first even if it means I have to wait a little longer for support on my CI card.

        I'm seeing a lot of effort being put into making Mesa 12.0 a great release for AMD graphics so thanks to you and the team for that.
        Last edited by ResponseWriter; 07 April 2016, 07:06 PM. Reason: Clarify roadmap statement.

        Comment


        • #14
          Please would you kindly inject some powerplay love for the mobile parts Iceland/Topaz and so on...

          Comment


          • #15
            Originally posted by pq1930562 View Post

            And how is that UI called?



            Why can't the open-source amdgpu driver use the same GUI as the closed-source amdgpu-pro driver?

            I thought amdgpu-pro is kind of an "add-on" for amdgpu?

            Why don't we get the Radeon Software GUI for Linux?

            Radeon Software is even using Qt, isn't it?

            Boggles me why Windows gets a Qt based GUI whereas Linux does not...
            I'm not sure of the name. In Gnome Shell it's the 'Display' entry. I'm not sure what more one needs than being able to arrange the displays and their resolution. Never got the point of the Catalyst thing. If I want AntiAliasing in a game, I'll configure that in that specific game. Not in the driver.

            About AMDGPU, as I understood it, AMDGPU is the kernel driver (same as the radeon driver) while radeonsi / AMD closed-source driver is the user-space driver. I'm not entirely sure how that works, as I thought that the kernel has a rule about one driver/device and the kernelspace radeon driver powers the same GPUs that the AMDGPU kernelspace driver powers, and I also don't understand how the radeonsi driver can work with both the radeon driver and the AMDGPU driver.

            It could well be that we get the QT UI, but I doubt it to be honest. Mainly because I doubt that they capsuled the UI well enough from the driver itself to make that possible.

            Comment


            • #16
              Originally posted by bridgman View Post

              So that's actually nothing like what I said, although I agree your interpretation is amusing. BTW when did we announce a roadmap and could you please send me a copy ?

              What I said is that I think we will see initial code before the roadmap, not finished / QA'ed / performance optimized code.

              If I thought we could provide production code that quickly then even I could put that information in a roadmap
              Took me a while to find it: https://www.phoronix.com/forums/foru...-support/page9

              When I first read it, I thought it's meaning was that there would be a detailed plan/roadmap published the week after that post. At least that's what I get from the last two sentences.

              Comment


              • #17
                Originally posted by Detructor View Post

                Took me a while to find it: https://www.phoronix.com/forums/foru...-support/page9

                When I first read it, I thought it's meaning was that there would be a detailed plan/roadmap published the week after that post. At least that's what I get from the last two sentences.
                Read it again; I can see why you might come to that conclusion but he only says they're working on it. No mention of publishing anything, just that they'll have a better idea. That's obviously taken longer to come up with than anticipated.

                But then...

                Originally posted by bridgman View Post

                CIK support is in the driver but disabled upstream by default. SI support is not in the driver yet, although one of our devs and one community dev have been doing some work on it. We're working out next steps now.
                So the statement about having code before a roadmap makes sense.

                Either way, it seems like the priority right now is having a usable replacement for Catalyst/Crimson ready for the Ubuntu LTS release, or at least before the current LTS 'expires.'

                Comment


                • #18
                  Yep, I was thinking about something higher level, eg do we give Catalyst Linux one more revision or focus on amdgpu hybrid (or amdgpu libdrm over radeon), and what the timing would be.
                  Test signature

                  Comment

                  Working...
                  X