Announcement

Collapse
No announcement yet.

oneAPI-Focused UXL Foundation Now Collaborating With The Khronos Group

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

  • oneAPI-Focused UXL Foundation Now Collaborating With The Khronos Group

    Phoronix: oneAPI-Focused UXL Foundation Now Collaborating With The Khronos Group

    Last year it was announced that Intel's oneAPI software initiative evolved into the UXL Foundation for making compute accelerators more open as well as opening things up to more cross-vendor collaboration and adoption. Intel started the Unified Acceleration Foundation with the Linux Foundation, Google, Arm, Qualcomm, Samsung, and others. Announced today is that the UXL Foundation has begun collaborating with The Khronos Group...

    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
    Cool.

    Comment


    • #3
      Originally posted by Laughing1 View Post
      Cool.
      It will be if AMD's onboard.

      Comment


      • #4
        So…OpenCL part two….

        Comment


        • #5
          Intel's left hand handshakes Intel's right hand?

          So here is short recap:
          1) Khronos Group owns SYCL trademark and controls SYCL specification
          2) UXL Foundation implements SYCL-compatible DPC++ compiler
          3) NVidia/AMD are second-class citizen in DPC++ (not even shipped in the package), in forever beta state. For AMD only Radeon W6800 is supported, only on Linux, with drastically outdated ROCm 5.4.3 stack [1]
          4) Alternative SYCL compiler implementation exist, with AMD as first-class citizen. It was known as hipSYCL/OpenSYCL, now renamed to AdaptiveCpp due to legal reasons. That's what you need to know about "open standards": you can't even use word SYCL, if you want to control "citizenship".
          5) Even though SYCL standard is open, OneAPI relies on internal DPC++ headers and Intel-specific extensions. Therefore it won't be possible to build oneDNN with AdaptiveCpp compiler.

          Comment


          • #6
            Originally posted by NeoMorpheus View Post
            So…OpenCL part two….
            OpenCL part two… compute boogaloo

            …. except actually OpenCL is a valid backend for AdaptiveCPP (which I wish could be called AdaptiveSYCL or something)
            Last edited by Eirikr1848; 11 June 2024, 04:40 AM.

            Comment


            • #7
              Originally posted by Type44Q View Post
              It will be if AMD's onboard.
              But they’re not. AMD could have been ruling the roost on this matter back 13 years ago when in the course of their Fusion program they released Kaveri with full HSA (Heterogeneous System Architecture) support with Carrizo and Bristol Ridge to follow. There was an UXL like foundation also called HSA headed up by AMD like intel heads up UXL and it also contained Qualcomm and Samsung and ARM and Imagination and it was driving adoption of HSA and OpenCL to do the very thing UXL and Intel is doing now with oneAPI. AMD really only got one big market player to get on board and that was Oracle who began to wire up HSA support in Java through an initiative called Project Sumatra. Then Lisa Su came in and killed off Fusion and HSA and devoted AMD’s resources into Zen and eventually chiplets. The market once again saw that you can’t trust AMD to stick by a program for long enough for it to take root nor provided adequate or competent tooling. So now you have Intel who controls CXL which now combines Gen-Z and CCIX and OpenCAPI and Intel controls UXL with oneAPI with UXL being the replacement of AMD’s HSA. This is why I have called and will continue to call for Lisa Su and AMD to abandon ROCm and hipSYCL….errr…AdaptiveCpp….whatever….and wholeheartedly adopt UXL and oneAPI, even going so far as to outwardly show this support by joining the UXL foundation so they can have a seat at the table and be able to help steer UXL and oneAPI’s direction going forward. It’s not like AMD has dropped initiatives before. Remember 3DNow! as an alternative to Intel’s MMX ? The aforementioned HSA. CCIX heterogeneous interconnect which is what Xilinx FPGAs used before AMD bought Xilinx (BTW I think Xilinx was part of HSA before Lisa Su killed it). Well ARM gave over CCIX to Intel and the CXL consortium. If AMD REALLY wants to compete with Nvidia it’s going to take them dropping ROCm and putting those human resources and money into backing UXL and teaming with Intel. Only with a united x86 front with Intel backed CXL, UXL and oneAPI can there be any hope of competing with Nvidia in the HPC world much less the AI space. AMD will have to be satisfied that the only market acceptance for them, other than CPUs, is the new GPU to GPU interconnect standard that the Compute Industrial Complex has adopted called UAlink which is based on AMD’s Infinity Architecture. But the only reason UAlink was adopted was that Intel got on board with it and adopted it as well. They could have bitched and moaned about CXL being better but it was obvious that it wasn’t for this use case. AMD needs to adopt the same attitude with ROCm by dropping it and adopting oneAPI.

              Comment


              • #8
                Originally posted by Lockal View Post
                4) Alternative SYCL compiler implementation exist, with AMD as first-class citizen. It was known as hipSYCL/OpenSYCL, now renamed to AdaptiveCpp due to legal reasons. That's what you need to know about "open standards": you can't even use word SYCL, if you want to control "citizenship".
                5) Even though SYCL standard is open, OneAPI relies on internal DPC++ headers and Intel-specific extensions. Therefore it won't be possible to build oneDNN with AdaptiveCpp compiler.
                Open......but not too much!
                Last edited by boboviz; 11 June 2024, 11:36 AM.

                Comment


                • #9
                  Originally posted by Jumbotron View Post
                  Then Lisa Su came in and killed off Fusion and HSA and devoted AMD’s resources into Zen and eventually chiplets.
                  Great Lisa, HSA Foundation was a little joke without future.
                  And she brought back the money to AMD.

                  The market once again saw that you can’t trust AMD to stick by a program for long enough for it to take root nor provided adequate or competent tooling.
                  For the HSA Foundation? Are you kidding?

                  and wholeheartedly adopt UXL and oneAPI, even going so far as to outwardly show this support by joining the UXL foundation so they can have a seat at the table and be able to help steer UXL and oneAPI’s direction going forward.
                  Usually, these BIG foundations, with a lot of partecipants (with different needs) produce....much ado about nothing

                  AMD needs to adopt the same attitude with ROCm by dropping it and adopting oneAPI.
                  A few lines above you say that AMD is not reliable about sw developing and now you ask to AMD to abandon a 8 years project that is used on some of the biggest HPC systems in the world (El Capitan, Frontier, etc).
                  So, Amd had to say "ehi, guys, from tomorrow we do no support your systems and we pass to Intel development platform"
                  That's a great idea!
                  Last edited by boboviz; 11 June 2024, 11:36 AM.

                  Comment


                  • #10
                    Originally posted by boboviz View Post
                    Great Lisa, HSA Foundation was a little joke without future.
                    And she brought back the money to AMD.


                    For the HSA Foundation? Are you kidding?


                    Usually, these BIG foundations, with a lot of partecipants (with different needs) produce....much ado about nothing


                    A few lines above you say that AMD is not reliable about sw developing and now you ask to AMD to abandon a 8 years project that is used on some of the biggest HPC systems in the world (El Capitan, Frontier, etc).
                    So, Amd had to say "ehi, guys, from tomorrow we do no support your systems and we pass to Intel development platform"
                    That's a great idea!
                    First of all yes, AMD should immediately cancel and drop ROCm even though they have a well earned reputation of developing initiatives and frameworks that do not garner industry wide support even though initiatives and frameworks showed technical merit at first. Dropping ROCm will not do much further damage to their reputation for that reputation has been earned over the last 25 years. oneAPI now has the big development momentum in the marketplace and has industry wide support through foundations and groups like UXL and Kronos. They as well as Intel have a credible plan and are excuting on that plan in a way that AMD never could do nor can they now. Hardware is nothing without software. The industry knows and accepts AMD as the best x86 CPU manufacturer and Xilinx now owned by AMD is the industry leading FPGA solution over Intel’s Altera. Also the industry has accepted that AMD’s Infinity Architecture is the heterogenous fabric of choice of tying together GPUs particularly across pods. But that’s where the industry support stops for AMD. When it comes to GPUs and software stacks to run those GPU workloads it’s Nvidia and CUDA….full stop. Not so much AMD and certainly not Intel at least with GPU tech as of now. That’s changing. Not so much with Intel suddenly becoming a GPU powerhouse even with buying out half of AMD’s GPU team a few years back. But as they make their REAL GPU play this year and going forward in the HPC and AI segment Intel will have a leg up in penetrating that hardware market with great compilers and software frameworks like oneAPI. Not to mention that oneAPI was designed not just for GPUs but all accelerators. oneAPI is the only credible competitor to CUDA….full stop. So what that El Capitan and Frontier are using AMD software. Those systems were designed YEARS ago and the only halfway credible solution at the time was AMD because this was pre-Pat Gelsinger Intel which was rapidly going into the toilet and perpetually stuck at 14nm+++++++++. By the time Capitan and Frontier are decommissioned oneAPI will be only non Nvidia solution left and even then it can run on any and all AMD CPUs and GPUs and FPGAs.

                    As far as you poo-pooing foundations. Agreed…until there are only those left who have universal support by all industry players with the biggest of all being Intel. And Intel heads them all up. From interconnects to APIs to even endorsing AMD’s Infinity Architecture now called UALink which doesn’t care if ROCm is flowing through that fabric or oneAPI. Everybody in the industry that’s not named Nvidia are all in these groups…::

                    CXL
                    UXL
                    oneAPI
                    UAlink
                    Ultra Ethernet

                    And Intel heads three of the five with the exception of UAlink and Ultra Ethernet but Intel endorsed both so now the industry is comfortable supporting it and not just AMD and Cisco.

                    This is the stack that is going to compete against Nvidia, CUDA, NVLink and Infiniband. With the above in mind….tell me with a straight face ROCm stands a chance of ever seeing widespread adoption in the industry. ROCm is the 3DNow! of compute.
                    Last edited by Jumbotron; 11 June 2024, 02:40 PM.

                    Comment

                    Working...
                    X