Announcement

Collapse
No announcement yet.

AMDGPU DC Pull Request Submitted For Linux 4.15 Kernel - 132,395 Lines Of Code

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

  • #31
    Originally posted by stupotace View Post
    From what I understand, there's actually incentive to merge it because it will be easier to keep it updated along with the kernel which means that any other development that goes along with it will also be kept more in sync with latest kernel development. Yes, they could dump it and forget it, but assuming they have plans to continue development, it's actually better for both AMD and kernel devs to get it merged.
    Will be, or could be easier? I can definitely see the potential in your statement, but the fact of the matter is, incomplete or faulty code will inevitably be a burden. Although we should be able to rely on AMD to clean up the code once its merged, we can't. The fact of the matter is, such problems should've have been spotted during their development process and fixed before continuing to the next stage of development. It is because of this why people like Linus need to be wary. This is no minor submission and if they spot problems just by scratching the surface, who knows what else could be brought down with it.

    I'm sure the DC devs are capable, but it really feels like they're rushing things. I understand why, but this rushing isn't helping anyone.

    Comment


    • #32
      Originally posted by sa666666 View Post
      ...

      Might make a company wonder if doing the right thing for Linux is actually worth their time. I'm not sure what the proper solution is, TBH. I'm glad that AMD is doing what they do, and I support them by buying their hardware. But in some ways I could also see a company saying "F*ck it" and just not supporting Linux at all.
      It's worth it, if company aims for long term support of their products. Linux way demands some code quality. And, code quality helps at code maintenance. And, if something gets into the kernel, it's supported very long.

      Comment


      • #33
        Originally posted by schmidtbag View Post
        Will be, or could be easier? I can definitely see the potential in your statement, but the fact of the matter is, incomplete or faulty code will inevitably be a burden. Although we should be able to rely on AMD to clean up the code once its merged, we can't. The fact of the matter is, such problems should've have been spotted during their development process and fixed before continuing to the next stage of development. It is because of this why people like Linus need to be wary. This is no minor submission and if they spot problems just by scratching the surface, who knows what else could be brought down with it.

        I'm sure the DC devs are capable, but it really feels like they're rushing things. I understand why, but this rushing isn't helping anyone.
        All code is a burden in some form or another. I don't think AMD's history over the past 3 years shows that they will dump the code and ignore bugs. The major concerns were with code architecture, and from my understanding they addressed the main sticking points. No giant code base is ever perfect and it will always be in need of refactoring in some form or another. The question at this point isn't if it's perfect (it never will be), it's a matter of have they fixed the major architectural offences. From what I've read, it seems like the answer is yes.

        Comment


        • #34
          Looking forward to Linus comment to the pull request.
          Need to prepare popcorn and beer but in the end he'll accept. Just to show Nvidia the finger

          Comment


          • #35
            Originally posted by sa666666 View Post
            I also wonder sometimes if they'll stick with it. Consider the case from the outside. AMD tries to do things the 'Linux' way (which is right, IMO). But it ends up taking over a year of back and forth, and the code still isn't in mainline. So quite a lot of work to integrate with the Linux way of doing things. But a better result in the end.

            Whereas Nvidia does everything their own way, and as a result doesn't have to communicate and/or coordinate with anyone. So they can use their Windows driver code essentially unchanged, with little work on the Linux side.

            In the end, the group doing the right thing (AMD) are having to do much more work, and some would say are essentially being penalized for doing things the right way. And the group doing the wrong thing (Nvidia) have much less work to do, and as a result have a more performant driver with quicker releases (but not the Linux way of doing things).

            Might make a company wonder if doing the right thing for Linux is actually worth their time. I'm not sure what the proper solution is, TBH. I'm glad that AMD is doing what they do, and I support them by buying their hardware. But in some ways I could also see a company saying "F*ck it" and just not supporting Linux at all.
            Isn't this the painful period to get the infrastructure in place that will make supporting Linux and future architectures easier on the long run?

            I.e. won't Navi be less painful as a result for AMD and Linux users?

            Comment


            • #36
              Originally posted by sa666666 View Post
              Might make a company wonder if doing the right thing for Linux is actually worth their time. I'm not sure what the proper solution is, TBH. I'm glad that AMD is doing what they do, and I support them by buying their hardware. But in some ways I could also see a company saying "F*ck it" and just not supporting Linux at all.
              I see it as the penalty they have to pay for being the underdog. In order to court big commercial & institutional users, they need to offer more assurances, such as being more open.

              I see it as similar to their OpenCL push, and the reason that didn't work too well is because they took an attitude of "build it and they (the app/lib developers) will come". Nvidia, on the other hand, was basically bribing academics and researchers to use CUDA in key sectors like HPC and deep learning. It would've been pretty cheap for AMD to do the same thing (and they have been, more recently), but now it's basically too late to catch up and thus we have their HIP effort.

              Comment


              • #37
                Originally posted by Sethox View Post
                the other just pure and simple quality control for our precious kernel that makes Linux great.
                it is not your kernel. and kernel already contains code with worse quality than dc. nothing is gained from users using same code out of tree with slower development speed

                Comment


                • #38
                  Originally posted by R41N3R View Post
                  I will decide to whether buy a Vega 56 or 64 :-)
                  buy 64 liquid cooled, it should be quieter

                  Comment


                  • #39
                    Originally posted by lucrus View Post
                    I bet Linus will accept it.
                    easy bet, he was willing to accept it year ago

                    Comment


                    • #40
                      Originally posted by debianxfce View Post
                      Kernel developers do not want support other than intel, this patch has been long available and not used in the mainline kernel:
                      https://raw.githubusercontent.com/gr...v4.13%2B.patch
                      you are lunatic, this patch adds intel support

                      Comment

                      Working...
                      X