Announcement

Collapse
No announcement yet.

Intel's oneDNN Continues Improving Support For Non-Intel Hardware

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

  • Intel's oneDNN Continues Improving Support For Non-Intel Hardware

    Phoronix: Intel's oneDNN Continues Improving Support For Non-Intel Hardware

    Earlier this year was the surprising move of Intel's oneDNN neural network library adding AArch64 support and that was then complemented by adding IBM POWER support to this neural network library that is part of their oneAPI collection. Now with the latest oneDNN 2.0 beta they have furthered the support and performance for non-Intel hardware...

    http://www.phoronix.com/scan.php?pag...e-Arm-Plus-IBM

  • #2
    That's pretty cool, but, why would they do that? Seems like a lot of effort for basically aiding a rivaling architecture. That would be like Nvidia making CUDA drivers for AMD.

    Comment


    • #3
      Originally posted by schmidtbag View Post
      That's pretty cool, but, why would they do that? Seems like a lot of effort for basically aiding a rivaling architecture. That would be like Nvidia making CUDA drivers for AMD.
      What's the number one complaint with CUDA? That it's Nvidia-only. What's the number one complaint with ROCm? It's reputation for being pain in the ass to even get working. What is this? The opposite of those.

      Intel making their product available in as many places as possible, on as much hardware as possible, as easily as possible means more people will see value in adopting it as a solution for their needs regardless of what they already have or are doing. When it comes time for hardware upgrades, pairing some new Intel hardware with your existing Intel software stack makes sense. Dominate on one front to make the other front more appealing.

      EDIT: IMHO, Intel saw what happened with AMD over the past 8 years with their open embrace and are now outdoing them on the open software side. Oh, a driver. Hold my beer. They learned their lesson with the ICC. Who needs the ICC when there's the GCC and LLVM? Who needs CUDA when there's oneAPI?
      Last edited by skeevy420; 29 October 2020, 09:27 AM.

      Comment


      • #4
        Originally posted by skeevy420 View Post
        What's the number one complaint with CUDA? That it's Nvidia-only. What's the number one complaint with ROCm? It's reputation for being pain in the ass to even get working. What is this? The opposite of those.
        CUDA is Nvidia-only because it is within Nvidia's interest to make sure that all the money they dump into it yields a profit. Since CUDA is free, that's not going to happen if people buy their competitors' products for all the work they put into it. Trust me, I find it irritating - there is CUDA-based software I'd really rather run on AMD if I could, but I have no choice but to use some old, slow, power-hungry Kepler GPU to do so, because I don't feel like buying a new Nvidia GPU for 1 program. But, I don't blame Nvidia for the route they take. Clearly, it's working well for them.
        Intel making their product available in as many places as possible, on as much hardware as possible, as easily as possible means more people will see value in adopting it as a solution for their needs regardless of what they already have or are doing. When it comes time for hardware upgrades, pairing some new Intel hardware with your existing Intel software stack makes sense. Dominate on one front to make the other front more appealing.
        Sure, the easiest way to increase popularity is to increase accessibility. But, that isn't the only solution, case in point: CUDA. CUDA is not widely accessible yet it completely dominated over OpenCL, because it was so much more polished and easier to implement. That isn't to say Intel can't/won't achieve the same, but they're banking on the idea that what they're making will be popular, where hopefully that popularity will get more volunteers or other companies involved where they don't have to pitch in as much. Unless Intel has some sort of trick up their sleeves that makes OneDNN perform better on their hardware, I just don't see the financial incentive for them to actively contribute toward competing products.

        Bear in mind, this is different compared to Intel's contributions to Mesa, because their contributions are for themselves first, and anyone else who wants to mooch off them is able to. What Intel is doing with OneDNN is as if Intel were to make additions specifically for amdgpu, nouveau, or freedreno.

        So, I'm not confused about Intel making this open-source, I'm confused why they're making contributions that only benefits their competitors.
        Last edited by schmidtbag; 29 October 2020, 10:07 AM.

        Comment


        • #5
          My own theory why they are making these contributions is that the benchmarks will favor their hardware. Is oneDNN going to exploit Altivec with PowerPC?
          Their git even mentions "Future ISAs may have initial support in the library disabled by default and require the use of run-time controls to enable them." Regardless, I doubt any other architecture will show similar performance than AVX512_CORE_AMX or future instruction sets will offer. Make it compatible for everything, but everything else is slower.

          Comment


          • #6
            Originally posted by schmidtbag View Post
            So, I'm not confused about Intel making this open-source, I'm confused why they're making contributions that only benefits their competitors.
            Because Intel knows that x86 Intel hardware isn't the end all of the computing world and that plenty of machines are already using a mix of AMD, Intel, ARM, Power, and more CPUs with multiple AMD or Nvidia GPUs attached. Not all of them will want to buy all new hardware just to try out Intel's new thing. What good is a solution if it only utilizes a fraction of what your system is capable of or vendor locks you into specialized hardware? A hardware-fluid software solution, even if they have to support their competition's hardware, provides a way to not vendor lock anyone into any one setup or scenario.

            Comment


            • #7
              Originally posted by skeevy420 View Post
              Because Intel knows that x86 Intel hardware isn't the end all of the computing world and that plenty of machines are already using a mix of AMD, Intel, ARM, Power, and more CPUs with multiple AMD or Nvidia GPUs attached. Not all of them will want to buy all new hardware just to try out Intel's new thing. What good is a solution if it only utilizes a fraction of what your system is capable of or vendor locks you into specialized hardware? A hardware-fluid software solution, even if they have to support their competition's hardware, provides a way to not vendor lock anyone into any one setup or scenario.
              What good is investing in a solution you created if your competitors' products can utilize it better than your own? That isn't to say it will be better on competing platforms, but Intel is setting themselves up for that to happen. Intel isn't exactly known to be kind to their competitors.
              It's taking many years for servers to switch from Xeon to Epyc, because even though they're binary compatible, there is still a layer of vendor locking involved.
              As mentioned before, Nvidia vendor-locks CUDA and that's been working out great for them.

              In a consumer perspective, vendor locking is terrible and unproductive. In a business perspective, it can (isn't always) the easiest way to maximize profit. Although Intel has skilled and perhaps even altruistic engineers, they are still incredibly greedy at the corporate level, which is why them working on this doesn't make sense to me. Intel has repeatedly shown to care more about their investors than their customers, and currently, their investors are losing interest.

              For the record, I don't want Intel to vendor-lock and I'm grateful they're helping other platforms, I just think it's really weird. It's no big deal to open-source something but it's very strange to go out of your way to help your competitors.

              Comment


              • #8
                I think that CUDA entrenchment is so extensive that at this point it makes sense to make people use anything but CUDA. They can later release a second version that is locked to Intel products and performs better but first they need to get people onboard.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  That's pretty cool, but, why would they do that? Seems like a lot of effort for basically aiding a rivaling architecture. That would be like Nvidia making CUDA drivers for AMD.
                  I assume it's about making it easier to sell their GPUs into IBM systems. We did the same with the ROCm stack.

                  When you make both CPUs and GPUs it stops being as simple as "everyone is a competitor". POWER may be a competing CPU architecture but it also represents a potential GPU market, and IBM is still bigger than Intel although not by as much as in the past.

                  NVidia uses our CPUs in their GPU supercomputer and both companies are happy with that.
                  Last edited by bridgman; 30 October 2020, 03:42 AM.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    I assume it's about making it easier to sell their GPUs into IBM systems. We did the same with the ROCm stack.

                    When you make both CPUs and GPUs it stops being as simple as "everyone is a competitor". POWER may be a competing CPU architecture but it also represents a potential GPU market, and IBM is still bigger than Intel although not by as much as in the past.

                    NVidia uses our CPUs in their GPU supercomputer and both companies are happy with that.
                    I suppose that makes sense.
                    I thought Intel was bigger than IBM a few year ago? I guess that depends how you define "big" too.

                    Comment

                    Working...
                    X