12-Way Graphics Card OpenCL Comparison With AMDGPU-PRO 17.40 ROCm, NVIDIA 384.98

[phoronix]

Phoronix: 12-Way Graphics Card OpenCL Comparison With AMDGPU-PRO 17.40 ROCm, NVIDIA 384.98

With the recent testing of the GeForce GTX 1070 Ti being our new graphics card up for Linux benchmarking as well as having a new NVIDIA Linux graphics driver release, hare are OpenCL benchmarks of 12 graphics cards using the latest AMDGPU-PRO 17.40 and NVIDIA 384.98 Linux drivers on Ubuntu x86_64.

http://www.phoronix.com/vr.php?view=25508

[Linuxhippy]

I wonder ... for AMD GPUs the OpenCL implementation "OpenCL 2.0 AMD-APP (2482.3)" is mentioned - however the articles title clearly mentions ROCm.
Isn't this the proprietary OpenCL driver which has nothing in common with ROCm?

[Marc Driftmeyer]

LuxMark 3.1 is outdated. I discovered [and this is definitely a bug on their part] that the if I have the AMDGPU-PRO icd installed with Mesa that Luxmark segfaults with absolutely the usual no coherent information to the cause. Remove mesa-opencl-icd and it loads.

Compared to Blender trunk it also doesn't recognize the FX-8350 which is now recognized in Blender: CPU+GPU are now options in 2.79 master and 2.80 master.

[Marc Driftmeyer]

I wonder ... for AMD GPUs the OpenCL implementation "OpenCL 2.0 AMD-APP (2482.3)" is mentioned - however the articles title clearly mentions ROCm.
Isn't this the proprietary OpenCL driver which has nothing in common with ROCm?

It is the ROCm driver with bits that are still proprietary. Eventually, it'll be flushed out and the AMDGPU Pro won't be tested as we'll have a working opencl stack w/o any need for amdgpu pro packages.

[Marc Driftmeyer]

My scores for the RX-480 8GB card OpenCL GPU only on LuxMark 3.1.

Microphone: 9606
Luxball: 14671
Hotel Lobby: 2888

[orome]

LuxMark 3.1 is outdated. I discovered [and this is definitely a bug on their part] that the if I have the AMDGPU-PRO icd installed with Mesa that Luxmark segfaults with absolutely the usual no coherent information to the cause. Remove mesa-opencl-icd and it loads.

luxmark-3.1 asserts on current mesa/clover on MAX_GLOBAL_BUFFERS. bumping the limit makes the benchmark work, but with 30-40% wrong pixels (and tons of GPU faults in dmesg).

Compared to Blender trunk it also doesn't recognize the FX-8350 which is now recognized in Blender: CPU+GPU are now options in 2.79 master and 2.80 master.

CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 should be enough to get blender to recognize clover devices, whether it'd actually render anything is another story.

[vito]

What would be really interesting is comparison of deep learning frameworks between CUDA & OpenCL.

For example, I read that PTS supports Caffe w/ CPU and CUDA backend here: https://www.phoronix.com/scan.php?pa...n-Phoronix-PTS

Caffe now also supports OpenCL - there is an 'opencl' branch: https://github.com/BVLC/caffe/tree/opencl

I wonder how difficult would it be to add this to PTS?

[Marc Driftmeyer]

luxmark-3.1 asserts on current mesa/clover on MAX_GLOBAL_BUFFERS. bumping the limit makes the benchmark work, but with 30-40% wrong pixels (and tons of GPU faults in dmesg).



CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 should be enough to get blender to recognize clover devices, whether it'd actually render anything is another story.

Uh no. They have long since moved passed th at little bypass. OpenCL 1.2 or nothing. Mesa's OpenCL ICD rightly gets ignored by Blender w/o causing Blender to crash. Luxmark crashes as it's code has no ability to manage multiple ICDs [which is counter to the point of them] and upon moving Mesa's OpenCL ICD Ellesemore registers and runs LuxMark 3.1 quite smoothly.

[difron]

I wander if hip/hcc can be executed on top of this stack? If so, we can run CUDA on AMD hardware, right?

[bridgman]

The ROCm code path is only used by OpenCL on Vega HW at the moment, so while there is a good chance of HIP/HCC working well on Vega+17.40 we are not actively testing that combination yet. HCC and OpenCL both run over the common ROC runtime layer, ie HCC does not run on top of OpenCL.