Archives Discussions

[jason]

2.1 has been out for some time now and promised to work on any 2.0 hardware (e.g. compiler changes only).  The feature I was looking forward to the most, since 1.1 was the C++ kernel language (I've even used AMD's static kernel extension in the past for a time).

But I haven't been able to figure out how to run OpenCL C++ kernels anywhere, and particularly on AMD hardware, despite the 2.0 support they've had for many months now.

So what is the state of kernel C++ support?

Is there a path between SPIR-V and kernel C++ support?  What does it involve?  It seems to me that this approach would, practically speaking, prevent JITing sources... which impacts development and some types of libraries.  But that would still be better than nothing...

[gstoner]

Our current Microsoft Windows driver supports  OpenCL 2.0, which is OpenCL C Kernel Only.  We shipped with C++ Static Kernel Language with OpenCL 1.2 in past drivers.   Note Khronos Group OpenCL C++ Static Kernels you need OpenCL 2.2 with SPIR -V this still a provisional specification. https://www.khronos.org/news/press/khronos-releases-opencl-2.2-provisional-spec-opencl-c-kernel-lang...

If your interesting programming in C++ Static Kernel language we also have on ROCm HIP which uses the HCC compiler. You can find out more here ROCm, a New Era in Open GPU Computing

[jason]

Apparently it was provisional in 2.1 as well, just not in core.  As being first with C++ support with the old mechanism though, I did expect AMD to be on it... since they're leveraging llvm already at least.

I didn't give ROCm much thought before but I'm still a bit bewildered and confused by it.  For one, my distro of choice, OpenSUSE has no prebuilt packages available (not a deal breaker as long as I don't have too much trouble compiling from source - like errors).

Will X and other GUI/GL things work  along side ROCm?  Fglrx wasn't the best but it could drive the display and allow GPU code execution at the same time...

Also, I'd like to think I pay attention to OpenCL happenings but I think I completely missed ROCm - I only knew about Radeon-Pro, which it seems is mutually exclusive at the current time.  Was ROCm publicized anywhere?  Is it the going-forwards AMD official way to program AMD hardware? Finally, what about windows?

[gstoner]

ROCm is specific platform focused on the need for the HPC and Ultrascale market,  when you dive into these market they have different needs than standard Desktop class compute platform.  The driver is optimized for headless computing,  but it supports X11 for development.

Desktop typically is

- Core i7/i5/i3 & Xeon E3 with 1 to 2 GPU's  which only has Virtual Addressing support up to 39 bit > 1 TB  and only support up to 64 GB Physical memory today.  So most consumer hardware and driver are tuned for this market.   Right now in this market OpenCL largest consumer is video production software and video codecs.

HPC/Ultrascale Server

- Typically  a two-processor  Xeon E5 which support 46 PA (Physical Address) 48 bit VA (virtual address ranges) current we see the system with max physical memory 1 and 4 TB.      The System also have more than 1 GPU typically ( 2,4,8) need foundation for peer to peer communication,  These systems also use advanced networking technologies that leverage RDMA for Ethernet and Infiniband to allow two GPU's to talk across server nodes.  With these capabilities, we have to retune the driver to better meet the needs of the market.  This market is also looking to use a language beyond OpenCL,  like OpenMP with C, C++, Fortran,  Full Single Source C++ with GPU acceleration ( beyond static C++) , Python,  and CUDA/HIP.  

The ROCm driver leverages 4.x Linux Kernel,  which current only OpenSUSE supports. It possible to  bring ROCm to OpenSUSE,  just right now our customer have been requesting Ubuntu and RHEL/CENTOS support.  Fedora was stepping stone to REHL since it has more current Linux Kernel.

[jason]

@gstoner in the interest of all around support, is it possible to make a similarly packaged ROCm like the old AMD sdk or CUDAs?  That is, a sandboxed installation which you can distribute a compressed archive of?  I actually found this type of installation good for Ubuntu/RHEL/whatever and sometimes preferable.