9 ms·
OneAPI – A cross-industry, open, standards-based unified programming model
- dljsjr 6y agoSomething similar that has been around for ages and isn't controlled by Intel is MAGMA: https://bitbucket.org/icl/magma/src/master/ https://bitbucket.org/icl/magma/src/master/
- jdc 6y agoMAGMA Users' Guide Univ. of Tennessee, Knoxville Univ. of California, Berkeley Univ. of Colorado, Denver Date October 2020 The goal of the MAGMA project is to create a new generation of linear algebra libraries that achieves the fastest possible time to an accurate solution on heterogeneous architectures, starting with current multicore + multi-GPU systems. To address the complex challenges stemming from these systems' heterogeneity, massive parallelism, and the gap between compute speed and CPU-GPU communication speed, MAGMA's research is based on the idea that optimal software solutions will themselves have to hybridize, combining the strengths of different algorithms within a single framework. Building on this idea, the goal is to design linear algebra algorithms and frameworks for hybrid multicore and multi-GPU systems that can enable applications to fully exploit the power that each of the hybrid components offers. Designed to be similar to LAPACK in functionality, data storage, and interface, the MAGMA library allows scientists to easily port their existing software components from LAPACK to MAGMA, to take advantage of the new hybrid architectures. MAGMA users do not have to know CUDA in order to use the library. There are two types of LAPACK-style interfaces. The first one, referred to as the CPU interface, takes the input and produces the result in the CPU's memory. The second, referred to as the GPU interface, takes the input and produces the result in the GPU's memory. In both cases, a hybrid CPU/GPU algorithm is used. Also included is MAGMA BLAS, a complementary to CUBLAS routines. http://icl.utk.edu/projectsfiles/magma/doxygen/index.html http://icl.utk.edu/projectsfiles/magma/doxygen/index.html
- oivey 6y agoIsn’t MAGMA more like a canned set of linear algebra routines rather than a general interface for executing arbitrary code on GPUs? That’s pretty different.
- dljsjr 6y agoWell at the end of the day they're both libraries for doing heterogeneous parallel compute (CPU + GPU w/ one API). oneAPI might be more general but at the end of the day heterogeneous HPC converges on linear algebra. So it might have different ergonomics but it's very similar.
- RcouF1uZ4gsC 6y agoSeems like yet another CUDA alternative. Thing is, even if you were wanting to move away from CUDA, the churn of the alternative models would be scary. Do you want to develop for CUDA which has been stable and developed for quite some time, or do you want to try a new standard that you don’t known if it will be obsolete in a couple of years?
- BadInformatics 6y ago> do you want to try a new standard that you don’t known if it will be obsolete in a couple of years Some incarnation of oneAPI is bound to exist as long as Intel has a foothold in the HPC market. For example, MKL and MKL-DNN have been rebranded with a oneAPI prefix. So no, the long term stability argument doesn't hold water. I'd also note that they appear to have added support for cuBLAS and cuDNN as backends in their respective oneAPI libraries. It would be hilarious if that lead to more people running oneAPI on non-Intel hardware than first party stuff.
- jcelerier 6y agootoh Intel has over the years developed a few parallel libraries / extensions that have then been deprecated, for instance Cilk Plus...
- brianberns 6y agoClassic relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/
- harles 6y agoExactly what I was thinking of. I’m having a lot of trouble understanding the value proposition to vendors here.
- someguydave 6y agoThe value is that Intel wants to compete with nvidia
- BadInformatics 6y agoIt's better to think of this as a more friendly (i.e. open source development model) first party compute stack than some kind of pan-vendor standard. For example, anyone using MKL is now nominally using oneAPI libraries. They also went to the trouble of implementing/pushing existing standards instead of baking their own thing: SPIR-V for the IR format, SYCL for the high level programming interface, an OpenCL 3 implementation (AIUI they have the most complete implementation of 2.x and 3), etc.
- dyingkneepad 6y agoSo "Open Source development model" (developing in the open) is not the same thing as "Open Source Code" (developing in closed doors, then throwing code to the other side of the wall once in a while). Intel has a history of doing both depending on the project and internal groups involved, where only really the Open Development projects are actually successful and long-term. OneAPI uses a lot of components and I am not entirely sure they all follow the Open Development model. There's a lot of Open Source stuff out there that you basically can't contribute to: your contributions are ignored because source code is open but development isn't. Does anybody here know about how this is done for the OneAPI-related projects?
- 6y ago
- hctaw 6y agoThe problem of a heterogeneity in GPGPUs is that AMD and Intel can't make products that are competitive with NVidia. The "programming model" for "cross industries" (whatever those mean, the whole naming of this project is weird) aren't particularly deep moats if there were competitive solutions at lower prices.
- shmerl 6y agoAMD GPUs are better than Nvidia for that - they had async compute way longer. I thought the problem was CUDA lock-in and lack of a nice programming model using something modern like Rust may be.
- volta83 6y ago> AMD GPUs are better than Nvidia for that Better in what sense? > they had async compute way longer What is that?
- nynx 6y agorust-gpu (https://shader.rs https://shader.rs) is a spirv backend for Rust. It's early days, but already really promising. In my opinion, applying a good package manager (cargo) and a good language (rust) to gpgpu and rendering could result in great things.
- shmerl 6y ago
- DethNinja 6y agoWhy would someone use this instead of plain old OpenCL(or CUDA) with C++? What is the value proposal here?
- jpsamaroo 6y agoOpenCL and various other solutions basically require that one writes kernels in C/C++. This is an unfortunate limitation, and can make it hard for less experienced users (researchers especially) to write correct and performant GPU code, since neither language lends itself to writing many mathematical and scientific models in a clean, maintainable manner (in my opinion). What oneAPI (the runtime), and also AMD's ROCm (specifically the ROCR runtime), do that is new is that they enable packages like oneAPI.jl [1] and AMDGPU.jl [2] to exist (both Julia packages), without having to go through OpenCL or C++ transpilation (which we've tried out before, and it's quite painful). This is a great thing, because now users of an entirely different language can still utilize their GPUs effectively and with near-optimal performance (optimal w.r.t what the device can reasonably attain). [1] https://github.com/JuliaGPU/oneAPI.jl https://github.com/JuliaGPU/oneAPI.jl [2] https://github.com/JuliaGPU/AMDGPU.jl https://github.com/JuliaGPU/AMDGPU.jl
- my123 6y agoWhich is something that CUDA provided since the very beginning. (with PTX)
- stonogo 6y agoI can't help but assume this idea seemed much more compelling when Intel was still selling Omnipath.
- deleted 6y ago[deleted]
- RocketSyntax 6y agoIs "oneAPI Deep Neural Network Library (oneDNN)" an alternative to ONNX?
- rizzir 6y agoBy reading the name alone I can't help but think of the xkcd related to standards.
- mhd 6y agoMy Rational Unified Process PTSD is triggered.
- hestefisk 6y agoWhat does RUP have to do with APIs?
- gbrown_ 6y agoBoth Intel's oneAPI and AMDs ROCm/HIP stacks success are obviously tied to (and part of) the success of each companies future products. And today I'd bet AMD will come off better. They have multiple contracts for HPC systems with their future GPU products as well as an existing presence in consumer gaming products. Intel's effort seem to be banking on the Aroura system at ANL. Beyond that I don't know who's lining up to by Xe GPUs? Though I guess oneAPI will fit into whatever they do further down the line.
- touisteur 6y agoI'm having a hard time trusting Intel with anything AI mid to long term. OpenVINO was great until they removed support for Intel FPGAs, and they've been closing and deprecating low-level APIs that were necessary for low-latency, low-watt work on ex-Movidius hardware (and KeemBay always seems to be 'next semester'...). We already have huge lock-in with Nvidia, but at least we get wide expertise and huge perf boost, what does oneAPI bringing expect 'portability' and 'runs as fast as tf/torch/TVM'... OpenCL? Rocm? Vulkan targets? Who's going to debug and support that? I'm struggling to see what's enticing in this for python people that already have largely optimised torch and tf cpu and gpu backends, especially for batch work. And for latency-sensitive inference, I thought the 'industry' was going for TVM or other 'target all the things at code level'. I'm thinking: gimme your network in onnx format, everyone gives a C inference/compilation API, and let everyone optimize /behind/ that... Xilinx, AMD, whoever-Google-bought-last-week...
- jdc 6y agoThere's also OCCA which does JIT compilation to C++, OpenMP, CUDA, HIP, OpenCL and Metal. Originally built at Virginia Tech and now maintained by the Center for Efficient Exascale Discretizations of the DOE. And it seems to have decent Python bindings. https://libocca.org https://libocca.org
- taylorlapeyre 6y agoSituation: there are now n+1 competing standards. https://xkcd.com/927/ https://xkcd.com/927/
- mwkaufma 6y agoProblem: too many standards. Solution: add another standard.
- hestefisk 6y ago<Insert obligatory xkcd strip here> :)
- incrudible 6y agoWe already have way more APIs than vendors, letting every vendor have their own one API would actually simplify things.
- xiphias2 6y agoThis should be called oneMoreAPI. The right way to go would be to first upstream, finish and optimize AMD and Apple M1 support to PyTorch and Tensorflow and XLA, while trying to abstract as much to common libraries as possible. Trying to create an API first just slows development down even more.