Intel oneAPI 1.0 Officially Released

[phoronix]

Phoronix: Intel oneAPI 1.0 Officially Released

After announcing oneAPI at the end of 2018 and then going into beta last year, oneAPI 1.0 is now official for this open-source, standards-based unified programming model designed to support Intel's range of hardware from CPUs to GPUs to other accelerators like FPGAs. Intel's oneAPI initiative has been one of several exciting software efforts led by the company in recent years while continuing to serve as one of the world's largest contributors to open-source software.

http://www.phoronix.com/vr.php?view=29537

[skeevy420]

As neat as this is, I can't help it that the name "oneAPI" makes me feel like it was created by the "14?! Ridiculous!" guy.

[rmfx]

I hope the apis are more modern and good than their logo.

[MadeUpName]

Are they trying to make this an open standard or is this Intel channelling their inner NVidia?

[Michael]

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.

[Jumbotron]

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.

[dxin]

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.

[illuhad]

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.

[jayN]

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.

[Paradigm Shifter]

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