Radeon ROCm 2.2 Released With Vega 20 Optimization, Caffe2 Multi-GPU Training

[Meteorhead]

vegabook I understand your point, and a breaking point is coming closer and closer, but I have matters outside me using some tech. I also teach physicists at university how to do GPGPU and HPC, and currently the curriculum is OpenCL and SYCL. If I told every student to buy a laptop with Nvidia dGPU for CUDA, or install Linux (some years 100% of students use Windows as a desktop, sometimes it's only 60%)... I would not be successful. OpenCL promises portability, but doesn't really deliver. OpenGL does, OpenCL (and related tech) not so much. I use Windows because dual booting isn't too much fun (and I do play too), Visual Studio and it's CMake support is prime time and beats everything else (even Visual Studio Code and CMake Tools, although it's usable). Even if I installed Linux and ROCm, I'd still lose OpenCL-OpenGL interop, which again is still part of our curriculum: compute on device and visualize with no copy. There is no "one driver fits all" which was true in the Catalyst era and is true for the Nvidia binary drivers.

bridgman Thank you for elaborating. I can only imagine the difficulties of managing so many driver stacks on wildly different OSes, but it doesn't change the perception that it's falling apart. I'm not convinced that our SYCL-OpenCL-OpenGL interop code will ever work on AMD HW again. The escape hatch to SPIR, cl_amd_assembly_program (solely in relation to Computecpp, but not Intels upstream Clang work) is only in ROCm, but ROCm has zero graphics interop, because graphics is in a totally different driver. I believe blowing up the Catalyst stack was not a good decision. HSA, which was supposed to unite in reality divided, which might be an inside out paraphrase of your argument on HSA in relation to Win & Linux.

[bridgman]

bridgman Thank you for elaborating. I can only imagine the difficulties of managing so many driver stacks on wildly different OSes, but it doesn't change the perception that it's falling apart. I'm not convinced that our SYCL-OpenCL-OpenGL interop code will ever work on AMD HW again.

It will... just needs to get through the transition from SPIR (which most people seem to agree is a dead-end) to SPIR-V.

The escape hatch to SPIR, cl_amd_assembly_program (solely in relation to Computecpp, but not Intels upstream Clang work) is only in ROCm, but ROCm has zero graphics interop, because graphics is in a totally different driver.

Disagree... even back in the HSA days we had graphics/compute interop functions, and those are still available today. We also used them for OpenCL/graphics interop, although I don't remember off hand if that is part of the current stack. What are you trying to do that makes you think interop is not available ?

Remember that the HSA/ROCm/KFD stack and graphics stack both use the same underlying memory manager... mapping a graphics buffer to make it available for manipulation by a ROCm compute app is mostly just a matter of mapping the underlying physical memory from graphics address space (where GPU address space overlaps CPU address space) into ROCm address space (where CPU address always equals GPU address).

[Meteorhead]

Disagree... even back in the HSA days we had graphics/compute interop functions, and those are still available today. We also used them for OpenCL/graphics interop, although I don't remember off hand if that is part of the current stack. What are you trying to do that makes you think interop is not available ?

Apologies, you are right. I was looking for cl_khr_gl_event extension, but that's a tighter coupling of compute and graphics. It is a very nice feature and would very much like to see it atop ROCm.

Most importantly though we're still looking to develop SYCL applications on Windows. I'm still stuck on 18.2.3 which was the last driver to support SPIR. On Linux we're still struggling with our 8 GPU node to boot up with all the cards, but I already saw you engage in the topic. All help is much appreciated.

ComputeCpp 1.1.1 has experimental SPIR-V back-end. It would rock if the Windows driver would land the matching extension. Not to mention the Intel SYCL compiler also uses SPIR-V. I'm not sure how much OpenCL 2.1 it uses.

[bridgman]

People are using mint, mesa 18.4 and the 4.18.5-rt3-1-rt-bfq kernel with Vega gpus. Please AMD, document what to use.

I'm guessing a bit at context (in the sense of "use for what ?") but if you are trying to run the ROCm stack the easiest thing would be to update to a newer kernel (4.20 or higher) and then only install the ROCm userspace (rocm-dev, rather than rocm-dkms which installs both kernel and user components).

I don't know if the latest release has actually been tested on Mint but we have been relaxing the checking so that Ubuntu packages should now install on Mint as well.