Announcement

Collapse
No announcement yet.

Intel oneAPI 1.0 Officially Released

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

  • Michael
    replied
    Originally posted by jayN View Post
    I see a news story that oneAPI support for Radeon is being added.
    Was already covered yesterday - https://www.phoronix.com/scan.php?pa...MD-Radeon-GPUs

    Leave a comment:


  • jayN
    replied
    I see a news story that oneAPI support for Radeon is being added.

    https://arstechnica.com/gadgets/2020...support-to-ai/

    Leave a comment:


  • jayN
    replied
    Originally posted by grok View Post

    also for using the AVX512 feature soup. Tiger Lake laptops, new *-lake Xeons have stuff that would go unused. It's rather out of hand for users.
    Yes, and soon TGL NUC boxes, I see, and Rocket Lake desktop chips with avx512. Also the Sept 2 TGL benchmarks show they that there is simd advantage in use of the TGL embedded Xe-LP gpu.

    But also, from this article, perhaps amd avx2 simd could also benefit, which would be news to me.

    Leave a comment:


  • grok
    replied
    Originally posted by jayN View Post
    I believe one of their aims is to make your code debuggable on CPU, for example even if you write your C++ code in a form intended for FPGA.
    I believe another of their aims is to encourage you to move much of your code to their library calls which will eventually have optimizations for their different accelerator targets.
    also for using the AVX512 feature soup. Tiger Lake laptops, new *-lake Xeons have stuff that would go unused. It's rather out of hand for users.

    Leave a comment:


  • Paradigm Shifter
    replied
    Now if Intel continue to support it fully for >5 years, this might become a reasonable competitor to CUDA. Oh, and if they don't do any naughty tricks like deliberately disabling features when an AMD CPU is detected...

    Leave a comment:


  • jayN
    replied
    I believe one of their aims is to make your code debuggable on CPU, for example even if you write your C++ code in a form intended for FPGA.
    I believe another of their aims is to encourage you to move much of your code to their library calls which will eventually have optimizations for their different accelerator targets.

    Leave a comment:


  • illuhad
    replied
    Originally posted by dxin View Post
    Throughout the OpenCL years it's pretty clear that portable API is easy but portable performance isn't. Some devices prefer small kernel while other prefer big loops. Some has MMU and some doesn't. Some use devices memory and some shares the host memory. I really doubt that the machinery has advanced so far that programmers doesn't need to care about these any more.
    I don't think anyone is claiming perfect performance-portability of hand-written kernels with SYCL and/or oneAPI. As you point out, hardware is generally too different to expect that an algorithmic pattern that has been designed with GPUs in mind will run at peak performance on CPUs or some other hardware.
    But:
    • It is usually possible to have maybe not perfect, but decent performance portability across most devices. That works with OpenCL and also with SYCL. And even if your performance portability is not perfect, it is tremendously useful to have code that already works on all hardware because it means you can then focus on optimizing and creating optimized code paths for the hardware that you care about the most. I don't think that, if you want 100% peak performance, there's a way around optimized code paths for the target hardware in the foreseeable future. Technologies like SYCL however simplify development massively, because you only need to develop against a single API and can then decide later on for which hardware you wish to optimize.
    • If we move from the language to a higher level, excellent performance portability is usually possible via libraries (and oneAPI also comes with a lot of libraries for various use cases). For example, if you use the oneAPI linear algebra libraries for e.g. a matrix multiplication, it is (assuming the library is mature enough already) realistic to expect good performance on all hardware since the library developers would already have put in all the work creating optimized code paths for all supported devices.

    Leave a comment:


  • dxin
    replied
    Throughout the OpenCL years it's pretty clear that portable API is easy but portable performance isn't. Some devices prefer small kernel while other prefer big loops. Some has MMU and some doesn't. Some use devices memory and some shares the host memory. I really doubt that the machinery has advanced so far that programmers doesn't need to care about these any more.

    Leave a comment:


  • Jumbotron
    replied
    AMD had better shit or get off the pot and buy Xilinx to acquire an in-house FPGA manufacturer to counter Intel buying Altera. AMD also needs to make a BIG investment into RISC-V and start designing and incorporating RISC-V cores as DPUs into AMD designs.

    Between Intel adopting a "Tile Based" design for SoCs and SiPs with all the various Silicon assets they have acquired along with IP such as oneAPI AND Nvidia buying ARM and gathering all of THAT Silicon and software IP, AMD is getting squeezed mightily in the marketplace.

    The Zen architecture could very well become, by the middle to late part of this decade, as another "flash in the pan" moment for AMD as was their Opteron / Athlon era.

    The one main drag that Intel has and that will help AMD is that intel doesn't know how to manufacture a chip smaller than 10nm. By the time they pull their heads out of their asses the whole Silicon world will be at 5nm and already transitioning to 3nm. But make no mistake....AMD is in trouble silicon wise and IP wise.

    Leave a comment:


  • Michael
    replied
    Originally posted by MadeUpName View Post
    Are they trying to make this an open standard or is this Intel channelling their inner NVidia?
    It's an open standard and community/other-vendor contributions are welcome they say. As mentioned in the post, so far Codeplay has been working on NVIDIA GPU support for L0.

    Leave a comment:

Working...
X