OpenCL

[pangea]

On my system the (i think) most recent version of the AMD drivers (18.8.1, Windows 10 x64) no longer returns the CPU (FX-8350) as a valid OpenCL device.  Is this intended behavior or just a bug in my specific installation?

Output of my program which prompted this question (including platform description and version information):

AMD Accelerated Parallel Processing (OpenCL 2.1 AMD-APP (2671.3))
        Number of CPUs/GPUs/Devices:  0/1/1

Output of clinfo (only the first few lines):

Number of platforms:	1
Platform Profile:	FULL_PROFILE
Platform Version:	OpenCL 2.1 AMD-APP (2671.3)
Platform Name:	AMD Accelerated Parallel Processing
Platform Vendor:	Advanced Micro Devices, Inc.
Platform Extensions:	cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices

Platform Name:	AMD Accelerated Parallel Processing
Number of devices:	1
Device Type:	CL_DEVICE_TYPE_GPU
Vendor ID:	1002h
Board name:	Radeon (TM) RX 480 Graphics

[dipak]

The clinfo output is correct. At this moment, CPUs are no longer supported as OpenCL device.

[Meteorhead]

dipak​ I was just about to report that 18.6.1 had a malfunctioning CPU runtime, it argued about an internal compiler error, amdocl_as64 not being found, which is an .exe and must be related to codegen. Indeed, it was missing from my system even though driver install completed without a glitch.

As for this the statement:

dipak wrote:

The clinfo output is correct. At this moment, CPUs are no longer supported as OpenCL device.

I am shocked, still in not having a better response than the stock clinical case of nervous laughter. To elaborate a little...

I started learning GPU programming through AMDs CPU-only beta runtime for OpenCL 1.0, wrote my BSc thesis using it and inserted actual GPU runtimes somewhere halfway through writing up the actual document. It was a true testament to how awesome OpenCL is. (I still pat myself on the back how I managed to write few thousand lines of host code solely based on the spec.) We teach GPGPU through naked OpenCL and SYCL to physicists at university. This is the way we reach the most people without forcing them to buy HW or change OS. For a long time Intels CPU implementation has been far superior to AMDs. (I am aware of the awesome vectorizer they managed to implement, something AMD did not have the assets/capability to do, which I guess was the primary reason why the VLIW lanes had to be broken up when GCN was created.) Nonetheless it was very useful to have, not to mention it having interop capabilities with OpenGL (a topic that is also part of our curriculum for scientific visualization). On Linux the discontinuation of fglrx was a major pain, something very hard to forgive. Not the fact that it was discontinued, but that GCN 1.0 cards got stuck on Ubuntu 14.04. Then came 4 years of sysadmin hell, backported drivers and what not (thank you dokomix!). We invested in new HW for our cluster to get ROCm support. With ROCm one loses all interop (and generally all OpenGL) capabilities. AMDGPU-PRO 18.20 for the moment fulfills our needs, being the blend of legacy and modern components to keep things running. Knowing that the Windows driver lost the CPU runtime, I will definitely not upgrade to 18.30.

POCL is a mediocre substitute, but it's not a vendor solution. It doesn't have any interop capabilities, neither can it be paired with any GPUs context. Any app of mine that could make use of CPU and GPU at the same time (well made load balancing with CPU sub-device to break off a part of it to manage the GPUs) now has to be made multi-platform code, not just multi-device. THIS SUCKS!

So are you trying to tell me that we, who have been pushing the carriage of OpenCL for the benefit of AMD just silently removes CPU support, which has been there since the dawn of time/OpenCL??? I don't recall seeing the god****ed release notes! I recently bought an ASUS GL702ZC (Ryzen R7 1700 + RX 580) to be an OpenCL devbox beast, sysadmin dream and awesome gaming rig. I test PXE boot of Ubuntu VMs locally, rolling clean build repos while writing Vcpkg CMake port files, run simulations on the GPU and the CPU and play at night. I just ordered a second RAM stick to have dual-channel memory support and build and run on the CPU faster. As far as OpenCL is concerned, pretty much for nothing.

Apart from me (and most likely many others) being infuriated by this move, are there plans to ever restore CPU runtime support?

[Meteorhead]

Also, perhaps another line worth adding to the release notes is that SPIR support was updated (removed?) from 18.8.1. My ComputeCpp install on Windows did just fine, but after the update it fails to compile the spir64 binaries give to clCreateProgramWithBinary command. Both ComputeCpp 0.9.1 and the brand new 1.0.0.

I understand that the release notes are for hardcore gamers who are very much interested in +5% FPS in some given title… but can't pros be taken a little more seriously? Could you actually document when something changes in the OpenCL runtime? FFS, people living on Windows are not idiots (completely) and perhaps would deserve to know what happens on the compute side of things.

It's really a shame how AMD gave up on OpenCL just before SYCL could really become a thing. It's similar enough to CUDA that relevant projects picked up support for it, but with AMDs drivers sucking so badly, there's really no point, only Intel will benefit from decent SYCL support. The fact Codeplay had to create PTX and AMDGCN backends for ComputeCpp, because AMD and Nvidia cannot ship a decent SPIR compiler is a testament to how little these two companies care about OpenCL anymore. (Don't get me wrong, I understand how bad it is to maintain SPIR compat when everybody has moved to using Clang/LLVM 6 as their front/back-end for OpenCL support. If it's less of a burden, AMD could've put in the effort and enhance their HCC compiler to also support SYCL as a front-end. C++AMP, HCC, SYCL... they're all the same, but one is actually Khronos standard. As it stands currently, OpenCL cannot even be used as an underlying infrastructure for higher level tools.

Rolling back drivers to 18.5.1 when things were still working, or hell, I'll just change to teaching CUDA. At least that works. Should I have to target anything else than NV HW, I'll deal with the headaches of Clangs CUDA front-end support, courtesy of Google, and use the AMDGPU back-end of LLVM. I am infuriated… sell this crap laptop and buy a decent Intel or Nvidia machine, there's plenty to choose from.

[dipak]

SPIR support was updated (removed?) from 18.8.1

I was able to load and run a SPIR binary using 18.8.1. Actually, I tested it with our earlier APP SDK sample "SimpleSPIR". 

Please note, "-x spir" flag seems no longer supported and hence generates a compilation error. The sample works as expected without this flag.

[polarnick]

+1, this is the problem for our software, our users started to report that fresh AMD driver on windows is throwing

Error: HSAIL doesn't support OpenCL extension spir.

An invalid option was specified.

Error: BRIG code generation failed.

And it seems that cl_khr_spir extension still reported as supported via clGetDeviceInfo(CL_DEVICE_EXTENSIONS). Is it a temporary bug in driver? If yes - when it will be fixed? If no - how commercial applications are supposed to secure their intellectual property?

P.S. if cl_khr_spir is supported - it should be supported with passed "-x spir" w.r.t. documentation​

P.P.S. absence of OpenCL support for CPU is stopping me from migrating to threadripper on my workstation

[dipak]

Hi polarnick,

I also observed a similar behavior with SPIR binary. Currently I'm checking with the concerned team to understand the issue. Once I get more information, I will share with you.

Thanks.

[dipak]

The compiler team has confirmed that SPIR is no longer supported on HSAIL path (for CI+ devices), hence above error message is expected one.

Regarding the cl_khr_spir extension which is still reported by the runtime, I've already reported it to the concerned team.

Thanks.

[polarnick]

Thanks

What is the proper way to use AMD devices for GPGPU computations in proprietary software?

[dipak]

I understand your point. To be honest, I also asked the same question but haven't heard about a workaround till now.

It seems SPIR support is not in the priority list at this moment. However, as the team said,  SPIR support may be added in future if they get an approval from the upper management based on the customer feedback.

Thanks.

[ivan]

It's a pure shame on AMD as someone said above. And getting worse and worse. We have exactly the same issue and a lot of clients complaining they faced a problem using the "-x spir" option.

However, thanks dipak for all you're trying to do personally. Please, be so kind as to notify us here once they approve it or not. We're even thinking of stopping support for AMD at all for we're tired of AMD tricks.

[ipse]

ivan написал(а):

We're even thinking of stopping support for AMD at all for we're tired of AMD tricks.

Same here .

[Meteorhead]

Yeah. I specifically bought my 2000$+ dev box to have solely AMD HW (no cross-vendor hassle) for OpenCL development. On a personal level, it was a huge investment. For my production stuff I would primarily like to use SYCL with ComputeCpp or any other open-source technology that get's the job done, but I also have to deal with naked OpenCL (legacy projects and teaching material). ComputeCpp has a SPIR-SPIRV-PTX back-end and lately an experimental AMDGCN one as well. In terms of conformance, AMD has succumbed to depths pioneered by Nvidia. (Apologies, Apple is even less conformant when it comes to OpenCL (or any other standard, come to think of it).)

And yes, don't take it personal. It's just an untolerable management decision. OpenCL is good teaching and infrastructure material. It's just there… or at least it used to be. Ditching the contentious SPIR infrastructure before reaching OpenCL 2.1 and being able to declare an alternative via SPIR-V was a mistake. If AMD were to say something along the lines of:

• Look, we drop SPIR support, because we would like to focus our efforts on more modern technologies where progress is faster. We understand that your investment in SPIR is crucial to your success and therefor would like to invite you to pre-compile your kernels to SPIR-V and use those if the runtime is detected to support OpenCL 2.1. Keep SPIR binaries around if you wish to target legacy AMD systems or vendors that might not support 2.1.

That would be totally cool. I could, and most likely others could get behind that. A minor pain in exchange for implementing new features faster and better performance all around AMDs product line.

The fact that there is no release notes for compute changes in the drivers are annoying enough. I honestly couldn't care less if game title X runs Y% faster. It's nice, of course, but I am much more enthralled by picking up new OpenCL/Vulkan extensions, versions. Dropping features silently is just unprofessional. As much as I don't like the competition, CUDA is becoming more and more appealing.

[ipse]

The only way for now - offline compilation. But it is very inconvenient. And without app sdk (it seems they dropped it also) it is possible only on driver.

[polarnick]

Yes, I don't like offline compilation. But I see two more possible ways:

1. Using something like compute shaders in Vulkan: API calls translation is a fixed amount of work (because we already have abstraction layer over GPGPU with support for CUDA and OpenCL, so adding one another API is not so painful), but I am not sure about kernels. Did somebody tested possibility to compile OpenCL kernels to SPIR-V and use them via Vulkan? Does it work? (on amdgpu-pro? on Windows? on Mac via MoltenVK?)

2. Compromise solution: running script that will parse kernels syntax and at least obfuscate variables names.

[Meteorhead]

1. Vulkan is already an option via clspv, however that only compiles a subset of OpenCL C to Vulkan compute shaders. Be advised that there are two flavors of SPIR-V, one for graphics and one for compute. Vulkan compute shaders are of the graphics subset. (No pointer aliasing, and slightly less freedom) Also, the tooling becomes much more complicated. One must use clspv to compile the kernels and you should also pick up SPIRV-CROSS as a dependency and use the C++ API for instance to do reflection on the compiled shaders. (Find out the number of globals and their type, which substitutes for the fact you cannot give kernel arguments to Vulkan compute shaders.) Or you can blindly upload data for consumption by the device, but the errors will not be nice. Host code requires massive changes either way.
2. I don't see that to be a viable alternative.

[Meteorhead]

What are "CI+ devices"?

[dipak]

"CI" refers Sea Islands family devices (2nd generation GCN). Hence, by "CI+ devices", I meant to refer the devices belong to Sea Islands family or newer.

(Graphics Core Next - Wikipedia )