Announcement

Collapse
No announcement yet.

Intel Begins Volleying Open-Source Patches Around Intel AMX

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

  • Intel Begins Volleying Open-Source Patches Around Intel AMX

    Phoronix: Intel Begins Volleying Open-Source Patches Around Intel AMX

    Intel updated their instruction set extensions programming reference guide that along with other additions now details the Intel AMX (Advanced Matrix Extensions) coming with Sapphire Rapids Xeon CPUs next year...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Are extensions like that and TSX automatically available to AMD?

    Comment


    • #3
      Originally posted by Dr.N0 View Post
      Are extensions like that and TSX automatically available to AMD?
      AFAICT, yeah. Intel and AMD have a patent cross-licensing agreement on all things x86 ISA. (Nividia does not, all you Jensen h8ters might note). So AMD can implement AMX if it wants to. One might note r.e. AVX-512, AMD has yet to want to. Doesn't mean they won't ever, or might not adopt AMX, but these hardware extensions always come with trade-offs.

      Here's an interesting reddit: https://www.reddit.com/r/Amd/comments/9kfjgu/avx512_is_intel_exclusive/e6ynu38/
      Last edited by pipe13; 27 June 2020, 04:40 PM.

      Comment


      • #4
        Originally posted by pipe13 View Post
        One might note r.e. AVX-512, AMD has yet to want to.
        Given the amount of headaches associated with it, I'd say this was a good call.

        The most insidious thing about it is that light usage of AVX-512 can result in performance penalties that significantly outweigh the benefits. For AVX-512 heavy workloads, it's definitely a net-win, but it probably comes at the cost of substantial die area.

        I think AMD's position is that if you could really benefit from AVX-512, then you'd do far better by just moving the workload to a GPU.

        Comment


        • #5
          It sure would be embarrassing if AMX on a Sapphire Rapids CPU were slower than the same workload on a desktop processor's Gen12 iGPU. I wouldn't be too surprised...

          Comment


          • #6
            Originally posted by pipe13 View Post

            AFAICT, yeah. Intel and AMD have a patent cross-licensing agreement on all things x86 ISA. (Nividia does not, all you Jensen h8ters might note). So AMD can implement AMX if it wants to. One might note r.e. AVX-512, AMD has yet to want to. Doesn't mean they won't ever, or might not adopt AMX, but these hardware extensions always come with trade-offs.

            Here's an interesting reddit: https://www.reddit.com/r/Amd/comments/9kfjgu/avx512_is_intel_exclusive/e6ynu38/
            Thanks a lot for the detailed answer!

            Comment


            • #7
              Originally posted by coder View Post
              Given the amount of headaches associated with it, I'd say this was a good call...
              I think AMD's position is that if you could really benefit from AVX-512, then you'd do far better by just moving the workload to a GPU.
              Quite likely, given Vega's compute abilities. My own experience with nvblas tends to bear that out. Intel does not yet have a dGPU; it's understandable they would have focused on CPU extensions. We'll see how it plays out.

              Comment


              • #8
                Originally posted by coder View Post
                Given the amount of headaches associated with it, I'd say this was a good call.

                The most insidious thing about it is that light usage of AVX-512 can result in performance penalties that significantly outweigh the benefits. For AVX-512 heavy workloads, it's definitely a net-win, but it probably comes at the cost of substantial die area.

                I think AMD's position is that if you could really benefit from AVX-512, then you'd do far better by just moving the workload to a GPU.
                An alternative way to implement AVX-512 is only implementing the decoder part and keep the core ALU as 256-bit. AMD did this to AVX-2 in Zen 1/Zen+.

                Considering the benefit/cost, and currently even real AVX-512 modules are not running at full clock, this might be the most realistic way to adopt AVX-512.
                Last edited by zxy_thf; 27 June 2020, 11:36 PM.

                Comment


                • #9
                  Originally posted by zxy_thf View Post
                  An alternative way to implement AVX-512 is only implementing the decoder part and keep the core ALU as 256-bit. AMD did this to AVX-2 in Zen 1/Zen+.

                  Considering the benefit/cost, and currently even real AVX-512 modules are not running at full clock, this might be the most realistic way to adopt AVX-512.
                  They could, but I don't see a good reason to.

                  It would make sense for compatibility if software requiring avx-512 was ubiquitous. But thanks to Intel market segmentation games avx-512 is available only in high end parts, and thus any software with avx-512 support will have fallback paths.

                  By implementing avx-512 decoding only AMD would make software with a avx-512 hard requirement more attractive, but would provide worse performance than the Intel hardware with full 512 bit data paths. They would essentially improve the competitive positioning of Intel, not themselves.

                  Comment


                  • #10
                    AVX-512 is supposedly going to be added to Zen 4. I think the primary reason it hasn't been included yet is it takes up a lot of die space for a feature that isn't yet widely used, so AMD can save money by leaving it out for now.

                    Comment

                    Working...
                    X