Announcement

Collapse
No announcement yet.

Intel's oneAPI Is Coming To AMD Radeon GPUs

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

  • #11
    Originally posted by ms178 View Post

    Thanks a lot for the provided details. As AMD is not officially vocal about backing SYCL (at least in public, maybe they do engage actively inside Khronos), it is quite interesting that Intel sponsors your ongoing work. I would have assumed that AMD would have an interest in your project and provided that sponsorship. That makes me wonder what the current state of play for AMD looks like concerning their compute software stack. As I understand it they are heavily invested into LLVM/ROCm ecosystem and derive also their OpenCL, SPIR, SPIR-V work and HIP from there. Albeit starting some research with SYCL themselves, that work (and the developer) moved on to Xilinx.

    They did build their HCC compiler though instead of investing into SYCL and I don't even know if they deprecated it (as they announced some releases ago) or not. Their intentions on supporting OpenCL beyond 2.2 are also not clear to me - ROCm hardware support is also still limited to GFX8 and GFX9 to this date. It would be great to get an updated presentation from them how they plan to move forward in the data center. But since Greg Stoner left I haven't read anything new in this regard and it is still somewhat confusing how they want to tackle this task.
    My impression is that Intel is genuinely interested in growing the SYCL ecosystem and establishing oneAPI as a true cross-industry initiative that is portable and more widespread than just Intel. Of course, it also helps that 2 out of 3 announced exascale supercomputers will run on AMD GPUs and therefore require hipSYCL to run SYCL software
    hcc is indeed deprecated. I suspect that AMD and SYCL might be a true case of crappy timing: When AMD originally made the decision to go for HIP (ROCm was released something like 2015,2016-ish, AFAIR), SYCL was still very niche, so it might have made sense at that time to invest in something that people already know more (e.g. something CUDA-like such as HIP). And now they have a large investment in HIP and HIP libraries.

    Since they promised ROCm/HIP for their exascale supercomputers I expect that they will continue with ROCm and HIP. Currently it seems as only chips targeted for data centers are supported by ROCm. So, no Navi, but likely the future Radeon Instinct GPUs that will go into those supercomputers.

    Originally posted by oleid View Post
    A little off topic, but I was wondering:

    It is well known that (at least for radv) the AOC shader complier is in general superior to the one based on the Radeon llvm backend.

    What would it take to wire AOC up as kind of a way to generate code for sycl?
    Maybe illuhad knows more?
    I'm not really an expert on Vulkan. My understanding is that there are some differences between Vulkan's shader model and the kernel model that is for example used by OpenCL. While there has been some convergence, it's not yet fully possible to ingest compiled Vulkan shaders into OpenCL (and likely other compute APIs such as SYCL). If this is solved, in principle a Vulkan backend could be built for a SYCL implementation which might then be able to use AOC in a straight-forward way.
    Additionally, all current SYCL implementations are built either on top of or (in the case of Intel's DPC++) directly within LLVM. I'm not sure how well a different compiler would integrate.

    Given that AMD's LLVM-based compiler stack for ROCm is intended to power their supercomputers I can't imagine that LLVM performance at least for compute will be that bad.

    Comment


    • #12
      Originally posted by Vistaus View Post
      Great news, but not for the people on this site who still think Intel doesn't give a crap about supporting AMD hardware.
      lol, some people on this site love intel to the point of crediting intel for work done by urz

      Comment


      • #13
        Originally posted by oleid View Post
        It is well known that (at least for radv) the AOC shader complier is in general superior to the one based on the Radeon llvm backend.

        What would it take to wire AOC up as kind of a way to generate code for sycl?
        it's aco. and it's for graphics shaders, not for gpgpu(they run on different hardware stages). llvm is for gpgpu

        Comment


        • #14
          How nice, considering that AMD has fully and utterly screwed up adoption of OpenCL. It's amazing how they managed to take something that is public and F/OSS-licensed and completely nullify that advantage by deliberately avoiding mainstream integration in favour of perpetually alpha-state LLVM-fork monstrosity that no sane distribution could even package. And with it has gone any potential for adoption of non-CUDA game/simulation physics, ray-traced ambiophonic audio and neural-network training.

          How long AMD and Intel are going to let Nvidia's vendor-locking blobs reign ?

          Comment

          Working...
          X