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

  • #11
    Originally posted by gururise View Post
    ahhhhhhhhhhhhh.. and its the average Linux user that gets screwed again!
    Yup! That's true.

    Comment


    • #12
      As much as I might not like it as Linux user owning AMD cards this is undeniably a good call. DC/DAL abstraction layer would make future evolution of DRM hard as any change that would require that abstraction layer to change could get pushback "oh, but this will break things on Windows for us". Even if that was not the case it would restrict DC changes to be done by AMD devs, as nobody else would be able to test compatibility of those changes against a non-public code.

      Comment


      • #13
        Looking at Harry's email and Dave's response I think there is some kind of disconnect that we'll need to work through.

        Harry was saying "rather than trying to do a big bang switchover to DAL how about if we start using it just for future HW and that way if it turns out to need further re-factoring there won't be any impact on currently supported HW", and talked about the changes that we were still working on and planned to have finished before proposing it for upstreaming, but Dave's response suggests the email came across to him as some kind of "if you don't take DC as it is now there will be no future ASIC support" ultimatum.

        We will be adding upstream support for future chips whether or not we can get DAL/DC upstream - but we can provide much better-tested and more feature-rich code if we can share the tricky parts across multiple platforms. If we wrote "the perfect native Linux display driver" and then used the same code on other platforms then we absolutely would have a HAL in the Linux driver, just one that the maintainers liked. I don't think for a moment that Dave would then suddenly reject the native driver just because we started using it on other platforms.

        Michael, any chance you could tone down the article ? I really don't think it represents what is actually happening here.

        Other posters, please don't be flaming Dave - he is doing his job.

        Thanks...
        Last edited by bridgman; 09 December 2016, 12:25 AM.
        Test signature

        Comment


        • #14
          Originally posted by c2h5oh View Post
          As much as I might not like it as Linux user owning AMD cards this is undeniably a good call. DC/DAL abstraction layer would make future evolution of DRM hard as any change that would require that abstraction layer to change could get pushback "oh, but this will break things on Windows for us". Even if that was not the case it would restrict DC changes to be done by AMD devs, as nobody else would be able to test compatibility of those changes against a non-public code.
          Have to disagree here. Everyone is jumping to conclusions much too soon. We have been sharing code from other platforms with the upstream open source drivers for a long time, and if we take the same position that other vendors have done when submitting cross-platform code (oh you can't change that because it will break some other platform) then we deserve to have our code rejected the same way everyone else's has.

          But that is not what we are saying and not what we are doing. It may be what is being heard though, and that's a problem we need to fix ASAP.
          Test signature

          Comment


          • #15
            Reading forward in that email series I am also seeing a lot of "Instead of abstracting around possible deficiencies in various kernel subsystems, work with us to improve those subsystems to better serve your driver's needs (which will likely also help others' drivers along the way)"

            Comment


            • #16
              Originally posted by Qaridarium
              I think you are wrong! FLOSS is better from the start one
              There easily can be poor quality FOSS code. Just because it's FOSS doesn't make it good quality. Anyway, above comment wasn't constructive.

              Comment


              • #17
                Originally posted by bridgman View Post
                Looking at Harry's email and Dave's response I think there is some kind of disconnect that we'll need to work through.

                Harry was saying "rather than trying to do a big bang switchover to DAL how about if we start using it just for future HW and that way if it turns out to need further re-factoring there won't be any impact on currently supported HW", and talked about the changes that we were still working on and planned to have finished before proposing it for upstreaming, but Dave's response suggests the email came across to him as some kind of "if you don't take DC as it is now there will be no future ASIC support" ultimatum.

                We will be pushing upstream code for future chips whether or not some s - but we can push much better-tested and much more feature-rich code if we can share the tricky parts across multiple platforms. If we wrote "the perfect native Linux display driver" and then used the same code on other platforms then we absolutely would have a HAL in the Linux driver, just one that the maintainers liked. I don't think for a moment that Dave would then suddenly reject the native driver just because we started using it on other platforms.

                Michael, any chance you could tone down the article ? I really don't think it represents what is actually happening here.

                Other posters, please don't be flaming Dave - he is doing his job.

                Thanks...
                I guess it will depend ultimately on where the hardware capability is implemented in relationship to where the hal is implemented? I guess what I mean is something like, Right now DC is kernel > hal > hardware support, but what you think would make the kernel devs happy would be kernel > hardware support > hal. Does that make sense?

                Comment


                • #18
                  Micro Kernel FTW!!! No... Okay I'll see myself out.

                  Comment


                  • #19
                    Originally posted by Ouroboros View Post
                    Well, I guess I'll be manually patching and building the kernel for DAL/DC instead of waiting. Hopefully they make the patches easily accessible assuming they haven't already.

                    I don't really like Airlie's attitude throughout the reply, but he makes good points in the last paragraph. Expecting perfection and for them to perfectly conform his standards and maintain it separately which is exactly what they're trying to avoid is a bit unreasonable, though that's the feeling I get from it.

                    It'd be nice if they could properly discuss what their options are, where they can compromise, and what they have planned for the future if it's merged. Again, this is assuming they haven't already; I haven't been following it. The 'My way or the highway' response doesn't help anyone when they know it's not possible.
                    I don't think you understand what the drm folks are complaining about.
                    BOTH airlie and vetter had the same issue with this latest rfc. The difference is that airlie wasn't being circumspect.
                    Take a look at the ml and read through the very brief thread (six or seven missives, I behave).
                    Maybe bridgman is aware of something that's not apparent to me, but the fact that agdf said (AIUI) that the hal had to stay because otherwise they just don't have the resources to do validation as well, means that the most we can hope for, in the near future, is an Android-type situation. Over time the delta will get smaller (assuming they work to improve the drm abstractions do they more closely resemble what AMD needs from them) but that core HAL may not go away for awhile.
                    Of course, it's still very early days. Maybe this really is a miscommunication. Maybe they can work on their validation "framework" as they diverge from the HAL?


                    ​​​​​​@Qaridarium
                    Take a page from bridgman and try to be classy. You can get the same info across without causing misery.
                    Last edited by liam; 08 December 2016, 11:52 PM.

                    Comment


                    • #20
                      This is really sad. Ever since I've learned about the work AMD is putting to create an amazing driver the way it should be made (and the progress of it over this year) more and more I've shared the feeling of many: I'll get an AMD card/my next card will be AMD (vega).

                      I hope that what's happening here is just a temporary setback and a communication problem. Also, thanks for all you've done so far bridgman. Hopefully we'll find a reasonable option/solution for this problem soon.

                      Comment

                      Working...
                      X