Radeon + AMDGPU Performance On Linux 4.6

[bridgman]

As someone with an R9 285, this makes me sad. I tried playing the new beta for Lifeless Planet using the Mesa stack, and I was very disappointed with how slow it was (~10 FPS, which I eventually gave up after finding one particular jump was seemingly impossible to make at that frame-rate). The AMDGPU driver on the hybrid stack on 14.04.4 crashes for me (as bridgman is aware from a GoL discussion). That means I'm still stuck on Catalyst which isn't getting any support updates.

I really hope the R9 285 issues can be addressed soon.

Where are you getting your all-open stack from ? Michael's recent benchmarks suggest that the stack in 16.04 seems to be running a lot faster than the stack you get via (oibaf ?) repositories; just noticed today so not sure where the problem is yet.

[boltronics]

Where are you getting your all-open stack from?

Debian testing. I build my kernel from Torvald's stable git tree, but I've also tried the Debian testing kernel.

In benchmarks not to far back, Debian testing was shown to be one of the quickest distros.

Edit: So I have a triple boot setup. Debian testing running the all-open stack (my main OS), as well as Ubuntu 14.04.4 running Catalyst and another Ubuntu 14.04.4 running hybrid/pro for driver testing purposes.

[Vyrlokar]

Nothing is proprietary in the amdgpu-pro kernel driver, the source is available. It's just stuff that can't go upstream until we have an open source user (e.g., some misc bits for Vulkan and OCL) and a bunch of ifdefs for building against older kernels for enterprise distros.

So, the OpenCL bits and the Vuklan bits will need to wait until you opensource your OCL and Vulkan stacks, right? Once that gets released the only difference will be the IFDEFs for building against older kernels, and that can be picked up by the enterprise distros when building AMDGPU, meaning that they don't need a new kernel driver to install the hybrid stack right?

[Kano]

It is really weird that the Ubuntu 4.4 kernel was faster, Kanotix usually uses this kernel source as base too. But the source itself is not Ubuntu specific - all changes are in git, why don't you compile it yourself to try? Latest code:

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=master-next

[vkrastev]

Correct. If we want to be very precise, the "pro" in the amdgpu hybrid/pro driver comes from FirePRO, and AFAIK the "pro" in FirePRO comes from what is generally referred to as the professional or workstation graphics market.

BTW the reason for calling one of the driver stacks "Pro" was probably more obvious when we were looking at having three stacks. Alex outlined the three-stack plan at XDC in 2014 -- the all-open stack plus two hybrid stacks, one for workstation/FirePro GPUs ("Pro") and one for consumer GPUs ("Non-Pro").

I'm sorry for posting here, but...any news about the roadmap towards SI support with the hybrid driver?

[Ronshere]

Yes you were looking fo that. X failed to start after kernel version 4.5-rc6 because of the small bug in the code above. With dvi-hdmi cable i had slow boot to the desktop from the grub menu, setting amdgpu.audio=0 in the kernel command line reduced booting time to 6 seconds, with vga and dvi-dvi cable it is 1 seconds. Hdmi-hdmi cable is on the way from china for testing. Missing DAL might cause slow dvi-hdmi boot.

I have used my custom fixed kernel 4.5.0 for one week with Kaveri and I did inspect the source of 4.6-rc1 and noticed that the bug fix is still on the way to official kernels that you find from kernel.org. So maybe I know. This forum is like the tv-quiz "do you want be a millionare?", where the competitor is not sure about the answer and asks help from the audience.

Errrm, is it E, Ubuntu?

[faldzip]

Finally I've installed Ubuntu 15.10, downloaded kernel 4.5, applied a patch debianxfce talk about (plus gcc patch to get -march=native), turned on the CIK and PowerPlay support and built kernel. Then installed AMD GPU-PRO driver without the dkms package and now it's working like a charm on ma R7 260X - 30fps in Unigine Valley: http://openbenchmarking.org/result/1...KH-AMDGPUPRO36

while I had 22fps when checked yesterday on Ubuntu 14.04.4 with radeonsi (out of the box - nothing changed).

[bridgman]

So, the OpenCL bits and the Vuklan bits will need to wait until you opensource your OCL and Vulkan stacks, right? Once that gets released the only difference will be the IFDEFs for building against older kernels, and that can be picked up by the enterprise distros when building AMDGPU, meaning that they don't need a new kernel driver to install the hybrid stack right?

No, the OpenCL and Vulkan bits will be available as part of the hybrid driver from the start. The logic for building against older kernels will be in the kernel driver (already open source) not userspace. For enterprise distros a new kernel driver will be installed as part of the hybrid stack.

I'm sorry for posting here, but...any news about the roadmap towards SI support with the hybrid driver?

No, not yet. We will tell you when we have non-trivial new information, honest.

[vkrastev]

No, not yet. We will tell you when we have non-trivial new information, honest.

Understood, I won't ask again. Thanks very much for the time spent in keeping us up to date.

[Vyrlokar]

No, the OpenCL and Vulkan bits will be available as part of the hybrid driver from the start. The logic for building against older kernels will be in the kernel driver (already open source) not userspace. For enterprise distros a new kernel driver will be installed as part of the hybrid stack.

Bridgman, sorry if I didn't explain myself clearly, English is my 4th language, and sometimes it shows, sorry about that.

I mean that once the OpenCL and Vulkan userspace bits are open source, you will be able to get the kernel parts into the mainline kernel (as they don't allow things that don't have open source consumers), and so it should be possible to install the hybrid stack on the kernel driver from the standard kernel (meaning that while you might ship the driver with the hybrid stack, to make sure you have the latest version, but it should not be necessary unless there was an interface change or a critical bug).

The part on enterprise distros is that they might include the driver in their own kernels too, for the OS stack, and again letting you install just the userspace proprietary parts for the hybrid stack.

In the end, this leads to quicker, leaner installs and cleaner uninstalls, and that's a big plus in my book.