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
    ahhhhhhhhhhhhh.. and its the average Linux user that gets screwed again!

    Comment


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

      Comment


      • #13
        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


        • #14
          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; 12-09-2016, 12:25 AM.

          Comment


          • #15
            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.

            Comment


            • #16
              Originally posted by bridgman View Post
              f we wrote "the perfect native Linux display driver"
              It is a hard lesson for you to learn and i told you this in the past that in the F(L)OSS world the commercial bullshit code is not allowed. you just did not listen and you pushed your own theory out of a anti-opensource theorie of F(L)OSS is as bad as commercial code and only with much more effort the code come to FLOSS standard.
              I think you are wrong! FLOSS is better from the start one and there is no way to lower this standards to commercial bullshit style code standards.
              Last edited by Qaridarium; 12-08-2016, 11:44 PM.
              Phantom circuit Sequence Reducer Dyslexia

              Comment


              • #17
                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


                • #18
                  Originally posted by Qaridarium View Post
                  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


                  • #19
                    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


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

                      Comment

                      Working...
                      X