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 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 wqhd@144, 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; 09 December 2016, 12:41 PM.
            Test signature

            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
                Test signature

                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.
                    Test signature

                    Comment


                    • Originally posted by bridgman
                      So "open source is hard, particularly if you ignore the benefits, so we shouldn't do it" ?
                      Not really what I meant. I'm just highlighting the fact that people always complain about Nvidia not open-sourcing drivers, and it's moments like this why that's the case. I'd like things to be open source where possible, but I'm not inclined to complain about something being closed if it grants a better user experience.

                      Comment

                      Working...
                      X