Announcement

Collapse
No announcement yet.

AMD Zen 2 Improvements For LLVM Have Been Held Up For Months By Code Review

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

  • AMD Zen 2 Improvements For LLVM Have Been Held Up For Months By Code Review

    Phoronix: AMD Zen 2 Improvements For LLVM Have Been Held Up For Months By Code Review

    Back in February for LLVM Clang 9.0 was the initial AMD Zen 2 "znver2" enablement, but like the GCC support at the time it was the very basics. With time GCC picked up Zen 2 scheduler improvements and other work while sadly in the case of LLVM the improvements are still pending...

    http://www.phoronix.com/scan.php?pag...uler-LLVM-Pend

  • #2
    Interesting to know how long a code review takes for LLVM and what is the backlog on their review schedule. If Intel submits theirs a year in advance so that it gets included in time, that is a pretty serious backlog.

    Comment


    • #3
      There's always a long lead time for development. It just gets worse with certain projects depending on the amount of code and its potential impact of the aoftware stack. Look how long it takes for new additions to make their way through the Linux Kernel review.

      Comment


      • #4
        This is not a problem of LLVM code review process, rather a failure of AMD’s developer.

        He sent the patch in Aug 18, he got some review comments. Then he updated patch after 2 months (!) in Oct 19.

        So, blame AMD.
        Last edited by pyler; 10-19-2019, 05:11 PM.

        Comment


        • #5
          Michael should change the title of article

          Comment


          • #6
            Originally posted by pyler View Post
            This is not a problem of LVM code review process, rather failure of AMD’s developer.

            He sent the patch in Aug 18, he got some review comments. Then he updated patch after 2 months (!) in Oct 19.

            So, blame AMD.
            Yep, it's pretty apparent that AMD as a company doesn't understand how important it is to work upstream. Just look at how the community has needed to commit temperature reading support for every iteration of AMD's CPUs, and how perpetually under-staffed their Linux GPU team is. They should feel embarrassed.

            Comment


            • #7
              Same happened with the AMD Linux driver for the MP2 I2C controller. Someone from AMD dropped code on the mailing list, took four months for one iteration and another month for the second, and then disappeared before the code was in shape for merging. Someone from the community had to pick it up to beat the code into a mergeable state.

              Apparently, the way that AMD assigns engineering time to their software is wholly incompatible with how FOSS projects operate.

              Comment


              • #8
                If I was AMD and I had a choice between delaying a capital intensive project just so I could get some code into FOSS, or getting the product out on the street generating revenue.....I am sure i would choose revenue first. And with AMD down to the bare bones budget wise, I don't find it surprising that they are behind on any of their FOSS work.

                Comment


                • #9
                  Originally posted by edwaleni View Post
                  If I was AMD and I had a choice between delaying a capital intensive project just so I could get some code into FOSS, or getting the product out on the street generating revenue.....I am sure i would choose revenue first.
                  That's a false choice. You don't need to delay a product, you start the software development earlier. Other companies manage to do this, and this hurts AMD's adoption in the server space.

                  Comment


                  • #10
                    Anyways, GCC has that in the codebase, so you know what to do

                    Comment

                    Working...
                    X