Here is a recent training from AMD for Frontier: Link: https://www.exascaleproject.org/event/amd-gpuprogramming-hip... Video: https://youtu.be/3ZXbRJVvgJs Slides: https://www.exascaleproject.org/wp-content/uploads/2017/05/O... It will be very interesting to see what AMD came up with to convince ORNL to switch from 7 years (or more?) of NVIDIA to something else. I don't think it's just a lower price. Perhaps AMD is do…
Word on the street is that Nvidia insisted that they pay the full price for the GPUs this time and were giving them at a discounted rate prior.
Anything that is bad for NVIDIA is good for the FOSS. This company is the enemy of opensource, with its stance against nouveau, monopoly for GPU calculations with CUDA, etc.
I don't work for ORNL and don't know what their take in this is, but a lot of codes that the DoE uses are being ported to the Kokkos framework out of the Sandia National Lab. The application developer at that point basically doesn't have to care if the code runs on KNL, on Nvidia cards using Cuda or on AMD cards using ROCm. The work of tuning Kokkos well on AMD cards is cheap compared to getting stuck on a single ven…
Is it open source? It’d be huge to have something compete with cuda so that the best hardware may win
Most everything we develop (I work for the DOE) has to be open source.
If I recall correctly the AMD hardware is competitive or better in raw compute than their nVidia counterparts but Cuda makes developing software so easy so I’m curious what ORNL’s take on that is.
A shocking fact I heard recently is that on these large GPGPU supercomputers, only about 10% of the applications actually use the GPU at all. The labs are not likely to be a big fan of CUDA, since the reality is that most scientists do not have the bandwidth to rewrite their software (even to use GPGPUs in the first place, see above), and Nvidia tries very hard to make sure that CUDA is impossible to use for other GP…
For those discussing it, ORNL explicitly calls out the need to rewrite and retune in the CUDA => HIP transition on Page 3 of the spec sheet [1].
Edit: I assume getting folks to test on Summit is a big part of the de-risking plan.
> The OLCF plans to make HIP available on Summit so that users can begin using it prior to its availability on Frontier. HIP is a C++ runtime API that allows developers to write portable code to run on AMD and NVIDIA GPUs. It is essentially a wrapper that uses the underlying CUDA or ROCm platform that is installed on a system. The API is very similar to CUDA so transitioning existing codes from CUDA to HIP should be fairly straightforward in most cases. In addition, HIP provides porting tools which can be used to help port CUDA codes to the HIP layer, with no loss of performance as compared to the original CUDA application. HIP is not intended to be a drop-in replacement for CUDA, and developers should expect to do some manual coding and performance tuning work to complete the port.
Anything that is bad for NVIDIA is good for the FOSS. This company is the enemy of opensource, with its stance against nouveau, monopoly for GPU calculations with CUDA, etc.
This, and the egg shells NVIDIA's competitors are walking on to prevent accusations of reverse engineering the CUDA api.
Anything that is bad for NVIDIA is good for the FOSS. This company is the enemy of opensource, with its stance against nouveau, monopoly for GPU calculations with CUDA, etc.
Indeed. For instance, you can't even package applications with GGPU support for anything other than opencl for free software distributions like Fedora because the libraries are proprietary. At least unless someone knows of dummy libraries that you could against and substitute at run time -- I assume more than what GCC does? That seems the most important issue for free software HPC.
I don't work for ORNL and don't know what their take in this is, but a lot of codes that the DoE uses are being ported to the Kokkos framework out of the Sandia National Lab. The application developer at that point basically doesn't have to care if the code runs on KNL, on Nvidia cards using Cuda or on AMD cards using ROCm. The work of tuning Kokkos well on AMD cards is cheap compared to getting stuck on a single ven…
At LLNL the story is similar, but the framework is RAJA: https://github.com/llnl/raja . RAJA is a bit simpler than Kokkos in that it does not require you to adopt its data structures. The Kokkos and RAJA teams are also working together on some common utility libraries now.
Is the implication, that applications must use C++, rather than a language people like me can understand?
A while ago, I heard the LLNL CTO talk about performance portability for Sierra with the message, I thought, that it was focussed on OpenMP 5, with features driven by CORAL requirements. (He was around for an OpenMP standards meeting, though...) Is it not actually working that way -- if you can talk about such things?