Announcement

Collapse
No announcement yet.

It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel

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

  • Originally posted by Linuxhippy View Post
    I guess nobody seriously expects anybody else than AMD putting serious effort and maintenance into this codebase (development of the open-source radeonsi-driver is also almost exclusivly done by paid AMD OSS developers).
    I'm afraid that's not how it works.
    If the devs need to rework some of the common DRM code, that is used by DC, they will have to also touch DC.
    If the DC code there is overly complicated, it makes their job harder.



    I really don't understand the hate on Dave's goal: to have a maintainable codebase, which to users translates as faster and less error prone development of our beloved GPU drivers. Nothing prevents anyone from using a pre-built kernel that includes DC or building it themselves (it's open source after all...).

    Comment


    • Originally posted by Sonadow View Post
      Now that upstream has made clear their intent to never mainline AMDGPU DC.
      I don't believe upstream stated that. The HAL should not be mainlined, but not DC itself.

      Comment


      • Originally posted by Ansla View Post
        My Acer XF270HU works fine here over DP with either RX 480 or the onboard GPU of Kaveri. Except for audio or freesync, of course. If it doesn't work over HDMI it probably has to do with missing HDMI 2.0 support.
        Ofc, HDMI 1.4 can't handle [email protected], I'm using DP1.2.

        Well, some users (including myself) have reported about this problem at least with Hawaii and also Tonga, iirc.

        Interesting that it works for you with Kaveri, whose DCE is a few iterations older than Hawaii's and Tonga's. Could you tell me which exact kernel version you are using? Are you using radeon or amdgpu for Kaveri?

        Comment


        • This feel bad. For a second I thought: buy a mac

          Comment


          • Originally posted by Sonadow View Post
            Bridgman:

            Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?

            For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?

            Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?

            I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
            In case Bridgman does not see this, anyone else out here able to answer some of my questions? Thanks very much...

            Comment


            • Originally posted by Sonadow View Post
              Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?

              For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?

              Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?

              I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
              The situation before was:

              - initial code pushed for public review
              - lots of issues raised
              - we're working on implementing changes that address the issues raised
              - in the meantime we are lighting up new hardware with DC anyways
              - as we resolve initially identified issues it's likely new ones may be identified
              - we don't know how long it will take before we can get upstream but are continuing to work on it

              After this dramatic event, the situation is :

              - initial code pushed for public review
              - lots of issues raised
              - we're working on implementing changes that address the issues raised
              - in the meantime we are lighting up hardware with DC anyways
              - as we resolve initially identified issues it's likely new ones may be identified
              - we don't know how long it will take before we can get upstream but are continuing to work on it

              (in case it's not obvious, nothing has changed)

              A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second meaning that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.

              Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.

              Michael really needs to change the article - seems like everyone is posting and getting all worried based on the article and not reading any of the comments before going ahead and making things even worse. I'm trying to be on vacation and can't spend all day responding to basically the same "I didn't read the other comments so this looks bad what do I do" posts over and over again.
              Last edited by bridgman; 12-09-2016, 12:41 PM.

              Comment


              • Gee, and people wonder why Nvidia doesn't open source anything. It's exactly moments like this why I support closed-source software. I'm not saying AMD should close this source code and I'm not saying closed-source is better, but if they approached this in a closed-source manner, they wouldn't be in this situation.

                As an AMD user, I don't blame Dave for his decisions - AMD should have known what they were getting into. Yes, this situation sucks, but they put themselves in it.

                Comment


                • Originally posted by Sonadow View Post
                  In case Bridgman does not see this, anyone else out here able to answer some of my questions? Thanks very much...
                  Bridgman sees all, although he doesn't always have time to respond to all

                  Comment


                  • Originally posted by bridgman View Post

                    The situation before was:

                    - initial code pushed for public review
                    - lots of issues raised
                    - we're working on implementing changes that address the issues raised
                    - as we resolve initially identified issues it's likely new ones may be identified
                    - we don't know how long it will take before we can get upstream but are continuing to work on it

                    After this dramatic event, the situation is :

                    - initial code pushed for public review
                    - lots of issues raised
                    - we're working on implementing changes that address the issues raised
                    - as we resolve initially identified issues it's likely new ones may be identified
                    - we don't know how long it will take before we can get upstream but are continuing to work on it

                    A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second one that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.

                    Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.
                    Thanks, but I think you misunderstood me.

                    What I meant was that without the DC abstraction layer, what will the state of hardware support for AMDGPU be? I don't own any GCN hardware right now so it's not like I can even fool around with the driver to see what works and what doesn't. I'm more interested in knowing whether without the DC layer, will AMDGPU still be capable of providing launch-day (or close to launch day) compatibility with Linux, assuming the latest kernel is used? Or will it take much longer for AMD to get new hardware to at least activate KMS on Linux?

                    And if it does light up, what works, and what won't work without the DC layer? 1440P over HDMI achievable?

                    Comment


                    • Originally posted by Sonadow View Post
                      Thanks, but I think you misunderstood me.

                      What I meant was that without the DC abstraction layer, what will the state of hardware support for AMDGPU be? I don't own any GCN hardware right now so it's not like I can even fool around with the driver to see what works and what doesn't. I'm more interested in knowing whether without the DC layer, will AMDGPU still be capable of providing launch-day (or close to launch day) compatibility with Linux, assuming the latest kernel is used? Or will it take much longer for AMD to get new hardware to at least activate KMS on Linux?

                      And if it does light up, what works, and what won't work without the DC layer? 1440P over HDMI achievable?
                      I didn't misunderstand you at all. We will still be sharing code, it's just that the current DC abstraction layer will probably need to change at least for Linux (ideally for all platforms), which implies a change in the code sharing model.

                      We will also still be lighting up hardware with "DC the code" whether or not it is upstream at the moment.

                      Comment

                      Working...
                      X