Announcement

Collapse
No announcement yet.

Intel Developing "oneAPI" For Optimized Code Across CPUs, GPUs, FPGAs & More

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

  • L_A_G
    replied
    Originally posted by coder View Post
    Are you aware that OpenCL already does support CPUs, GPUs, and FPGAs? Why should the oneAPI look more like OpenACC than OpenCL or be significantly more disjoint than OpenCL?
    Having actually used OpenCL I know from experience CPU mode is mostly there to make it so that you don't need to re-write the compute code in use cases where a compute-capable GPU isn't available. Code that takes proper advantage of a GPU is always going to be far from the best solution on a CPU and the fact that OpenCL uses a subset of C doesn't help that much either as the best results on CPUs are typically reached by writing the critical parts of the compute code using code in (x86) assembly.

    I personally haven't tried it out, but the fact that support has been there for years and years, but the fact that FPGA compute, let alone OpenCL-based FPGA compute, hasn't taken off would suggest that it's not all that great. The only time I remember FPGAs gaining some kind of real ground in HPC was a bit before the first crypto-"currency" bubble burst when miners moved to FPGA miners due to their higher energy efficiency before moving on to ASIC miners not long after.

    Leave a comment:


  • coder
    replied
    Originally posted by L_A_G View Post
    The problem is that when you're trying to support CPUs, GPUs and FPGAs it's inevitably going to end up either as something that's "More like OpenACC than OpenACC" or just multiple very different APIs crammed in under one.
    Are you aware that OpenCL already does support CPUs, GPUs, and FPGAs? Why should the oneAPI look more like OpenACC than OpenCL or be significantly more disjoint than OpenCL?

    Leave a comment:


  • L_A_G
    replied
    Originally posted by coder View Post
    IMO, the main win from CUDA and OpenCL is by exposing enough of the hardware's performance bottlenecks and strengths that you can architect your code around it. As such, if Intel's oneAPI is any good, I'd expect it to look structurally similar.
    The problem is that when you're trying to support CPUs, GPUs and FPGAs it's inevitably going to end up either as something that's "More like OpenACC than OpenACC" or just multiple very different APIs crammed in under one.

    Leave a comment:


  • coder
    replied
    Originally posted by L_A_G View Post
    Sure, there are APIs like OpenACC that aim to make it very easy to port code written for highly parallel CPUs and to write code for both, but in my experience the results produced by those tend to be less than impressive.
    I always felt OpenMP and OpenACC were just there to deliver easy wins for novice/intermediate programmers or those cases where it just isn't worth the time and effort to re-architect something to get better GPU performance.

    IMO, the main win from CUDA and OpenCL is by exposing enough of the hardware's performance bottlenecks and strengths that you can architect your code around it. As such, if Intel's oneAPI is any good, I'd expect it to look structurally similar.

    Leave a comment:


  • GunpowaderGuy
    replied
    btw does anyone know how is web vulkan doing ? last time i checked google was contributing to apple's gl and gave invalid reasons for doing so . Eg : it not being able to practically run all platforms , has long being proven wrong ; it being too complex , language specific abstractions such as vulkano can make it easier to use while maintaining speed , with easier metaprograming in upcoming c++ this will also be practical in that language as it already is many others
    Last edited by GunpowaderGuy; 13 December 2018, 11:22 AM.

    Leave a comment:


  • GunpowaderGuy
    replied
    i blame khronos backing down from their plan to make vulkan the one api needed ( it has been proven fit to run general purpose languages such as rust btw ) , for all this nonsense . It is getting pretty bad , but i think we can still end it , we have to demand them to make the necessary changes to vulkan ( eg : make rasterization optional ) so it can run everywhere and be used as their sole api

    Leave a comment:


  • ms178
    replied
    Originally posted by sandy8925 View Post
    Yeah, hopefully they use OpenCL or Vulkan Compute instead of creating yet another API. I read the article and I think "OpenCL already does this......and is cross-platform, cross-vendor etc.".

    ms178 - It doesn't matter what API is used, ultimately they all run on the same GPU hardware, and therefore can all achieve the same level of performance. The API design does influences performance to some extent, but that can always be improved. The only difference between OpenCL, CUDA is the API they expose for developers, how easy it is to use the API, and the tools provided to work with it.
    The discussion over here points out some differences in scope of these compute APIs and their own set of limitations: https://forums.khronos.org/showthrea...Vulkan-Compute

    And as Michael pointed out to me recently in another discussion, the convergence from OpenCL and Vulkan was put on hold. Also these APIs are on a higher level thus limiting the chance to extract the maximum performance out of each device (consider that the API must accomodate FPGAs and GPUs which are very different in nature). Programmers also complained about the OpenCL memory model and other design choices which contributed to its slow adoption. OpenCL 2.0+ is still not widely established. SYCL builds on all of this. I still don't see a real end user benefit of this path yet.

    I'd rather see Intel joining the HSA effort, extending and improving the ROCm/HSA stack. I am also keen to know if Intel tries to engage with other industry standard bodies like CCIX, OpenCAPI or GEN-Z or if they cook up their own proprietary solutions. The latter is most likely but maybe the former AMD staff can convince them that collaboration could be also beneficial for them.

    Leave a comment:


  • Guest
    Guest replied
    Yeah, hopefully they use OpenCL or Vulkan Compute instead of creating yet another API. I read the article and I think "OpenCL already does this......and is cross-platform, cross-vendor etc.".

    ms178 - It doesn't matter what API is used, ultimately they all run on the same GPU hardware, and therefore can all achieve the same level of performance. The API design does influences performance to some extent, but that can always be improved. The only difference between OpenCL, CUDA is the API they expose for developers, how easy it is to use the API, and the tools provided to work with it.

    Leave a comment:


  • microcode
    replied
    threeAPIs

    Leave a comment:


  • ms178
    replied
    Presentations from Nvidia and AMD at least suggest that their goal is to have better GPU integration in the C++ standard and in my limited understanding it seems their current vendor specific efforts are some sort of precursor to that. Nvidias C++ guru Olivier Giroux at least said in an interview that Turing would be also great at generic C++ code (with C++17), I guess future GPUs and C++ standards will only get better at that.

    The experimental engine from EA (SEED) uses Intel's ISPC on the CPU side which also employs a SPMD model to extract parallelism and vectorization better from modern CPUs.

    At least HSA also targets FPGAs and there was some recent work to get that more efficient: https://github.com/HSA-on-FPGA/HSA-on-FPGA (based on: https://link.springer.com/article/10...265-018-1382-7).

    Leave a comment:

Working...
X