AMD Representative Says Their Vulkan Linux Driver Will Be Here Soon

[Kano]

@debianxfce

You can add patches to the source in /usr/src and trigger dkms later too, but Debian has patches added too, i only use kernel 4.4 right now, no idea if 4.5 changed anything. I can not test amdgpu anyway - but you should be warned: mesa and any binary drivers are differently packaged between Ubuntu and Debian, you can not exchange those. If you don't know how to install fglrx in Debian look at !amddeb in irc://irc.freenode.net/#kanotix . Using the run installers with a distro that updates that often as Debian testing/unstable is very stupid. The files will be replaced with every mesa update anyway and if you uninstall the binary driver you get old mesa copies back, impressive

[Berniyh]

Nope, depencies are made by human who made package. Very often there are depencies that will destory whole dekstop when you want to remove one package. For example If I want uninstall xserver-xorg-video-noveau or xserver-xorg-video-intel, synaptic wants to remove task-desktop, task-xfce and xserve-xorg-video-all that will make dekstop unusable. I do no anything with these, same happens if I want remove wayland stuff.

Ok, I'm not a Debian or Ubuntu user, so I don't really know about their package management. But that is not what it is like in general for package management.
If they do things like that, then their package management sucks and should be fixed.

If done properly, uninstalling a package is not a problem with package management, it won't break anything. You can check during the installation if files from packages clash (thus preventing the installation before modifying root, requiring to fix one of the packages).
At least that's what it is like for my package manager and my distro. From my experience on Fedora (have that on the laptop) at least, it is the same or at least I didn't have any issues.

Anyway, this doesn't really belong here. My point was just, that an install script which you have to run as root (or using sudo) sucks. If it does install to a dedicated root directory, then it's acceptable, because I can then merge that root directory into my system's root using the package manager (and uninstall it that way as well).
That's also the way I handle this driver currently. Unpack all of the .deb files. Copy the files in usr/ to such a dedicated root directory, adjust paths, configs etc. and then merge the driver.

[Berniyh]

I suspect that ubuntu 32 bit libraries will broke my wine gaming, how wine or 32-bit linux games work in fedora when using amdgpu-pro driver?

No idea, sorry. I didn't install amdgpu-pro on Fedora (the laptop has an RS880, wouldn't work anyway), but Exherbo Linux.

However, I don't have wine installed, so (for me) there is no point in installing the 32 bit libraries, which is why I left those out completely.

[Berniyh]

I can't get the driver working. It just complains about

(EE) AMDGPU(0): Failed to open amdgpu hybrid version

with no further information. However, the kernel setup worked fine when using the xf86-video-amdgpu driver (which I removed prior to the installation).

Anyway, I found out, that you can use the opencl icd implementation with the open source driver as well, even when running the radeon driver (kernel + ddx).
It does seem to run, but at least on my Kaveri, it's pretty slow, running a lot slower than just the CPU when using darktable.
I don't know if that's due to the chip I'm using (Kaveri) or due to the driver or both, as I can't get amdgpu-pro to work.

clinfo will also tell you, that while the driver claims to support OpenCL 1.2, it seems to support up to OpenCL 2.1

[bridgman]

Anyway, I found out, that you can use the opencl icd implementation with the open source driver as well, even when running the radeon driver (kernel + ddx). It does seem to run, but at least on my Kaveri, it's pretty slow, running a lot slower than just the CPU when using darktable. I don't know if that's due to the chip I'm using (Kaveri) or due to the driver or both, as I can't get amdgpu-pro to work.

clinfo will also tell you, that while the driver claims to support OpenCL 1.2, it seems to support up to OpenCL 2.1

The OpenCL driver can run over CPU or GPU - at first glance it sounds as if you're getting OpenCL over CPU.

[Berniyh]

With my Kaveri that means you have a working amdgpu driver (that is in the kernel), but amdgpu-pro dkms compilation has failed. You can fix the compilation errors and make a succesfull dkms build and install, after that I have non working amdgpu and booting to X fails, I have blinking cursor in vt7 and ctrl+alt+F1 works. No traces in log files what happened.

I have to correct myself here. It did work, when I tried a couple of weeks ago (to investigate a driver bug that affected both radeon and amdgpu). Now it doesn't work anymore, but I have yet to find out why. The xorg log isn't really more helpful than with the amdgpu-pro driver.
The only thing I can imagine would be the some patches in the kernel (from 4.4.1 (worked back then) to 4.4.6 (doesn't work), also tried 4.5.0) or an update to xorg-server, because other updates (that could affect this) were not carried out iirc.
I'll try a few things this evening, maybe I can find out what's wrong.

The OpenCL driver can run over CPU or GPU - at first glance it sounds as if you're getting OpenCL over CPU.

Possible, but how could I change that or even check?
Using OCL_ICD_DEBUG?

Could it be, that it's running on the CPU, because the wrong driver (radeon) was loaded? Does it only work with amdgpu-pro?
Would it work with amdgpu-oss?

As I don't need vulkan (now), I would be really happy if I could use the open source driver (either radeon or amdgpu) with this OpenCL implementation.
I don't need high performance OpenGL or any of the other features of amdgpu-pro. But having a useful OpenCL would be really nice.
Unless of course you are planning to open source that one soon or release a useful open source implementation of OpenCL.
Because what is currently available is no use to me (nor anyone else as far as I could find out) and there doesn't seem to be much going on in llvm/libclc that would point to a positive change soon.

[haagch]

Possible, but how could I change that or even check?
Using OCL_ICD_DEBUG?

Uhm, easiest way would probably be: Run clpeak. Check gpu usage with radeontop and cpu usage with (h)top.

[bridgman]

Possible, but how could I change that or even check?
Using OCL_ICD_DEBUG?

Could it be, that it's running on the CPU, because the wrong driver (radeon) was loaded? Does it only work with amdgpu-pro?
Would it work with amdgpu-oss?

My vague recollection was that clinfo provided enough info to tell. If you're seeing two devices that would be CPU/GPU, if only one then CPU... but it's been a long time since I've looked at it more than "yep clinfo runs".

OpenCL definitely won't work with radeon, not sure about latest upstream amdgpu. Either Vulkan or OpenCL or both need IOCTLs not yet upstream but I don't remember offhand which.

[bridgman]

Moderated again...

This forum requires that you wait 30 seconds between posts. Please try again in 1 seconds.

[Berniyh]

With A8-7600 and ssd, I have same fps with amdgpu,radeon and crimson in Unigine heaven, approx average 10 fps at 1920x1200 medium quality. I am trying to achieve the same desktop startup time that I had with abandoned Crimson, 1 second from the Grub menu when cold booting. With radeon, desktop is visible in 7 seconds and with amdgpu in 18 seconds. How is your X startup times when booting? Is this slower behaviour a feature of radeon oss 3d accelleration stack?

Ok, got that worked out, there is a bad commit in 4.4.5 and 4.5.0 that results in a hang. Reported a bug and reverted it, now amdgpu-oss is working again.
Can't be bothered to test amdgpu-pro right now, maybe tomorrow.

For me, amdgpu and radeon behave pretty much the same. Startup time of X is pretty much identical. Starting X takes approx. 2-3s. Never tried crimson or flgrx

Uhm, easiest way would probably be: Run clpeak. Check gpu usage with radeontop and cpu usage with (h)top.

Thanks, forgot about radeontop and yeah, it looks like the gpu is doing nothing.

My vague recollection was that clinfo provided enough info to tell. If you're seeing two devices that would be CPU/GPU, if only one then CPU... but it's been a long time since I've looked at it more than "yep clinfo runs".

OpenCL definitely won't work with radeon, not sure about latest upstream amdgpu. Either Vulkan or OpenCL or both need IOCTLs not yet upstream but I don't remember offhand which.

It looks like it was working because it wasn't working. uhm ...

Anyway, you're right and the sad news is: the OpenCL implementation won't work with amdgpu-oss.
The difference to radeon being that it looks like it is actually trying, because now it's not just running on the cpu, applications using it (even clinfo) are just segfaulting.

Well, it was worth a try ...