Radeon + AMDGPU Performance On Linux 4.6

[bridgman]

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.

Yes, sorry, this is correct. I misread your earlier post as saying that users wouldn't be able to use OpenCL and Vulkan until they were open sourced.

[boltronics]

You might have the windows version because linux version seems to be availabe game byers only.

Actually, it's on GNU/Linux now too if you use the beta code. There's an article about that here.

You can try if the game runs with oss radeon or vanilla amdgpu and wine-staging (max version 1.9.5, csmt enabled) or wine-dev 1.9.6. Winehq has good results. Dx9 api might be more stable than linux api for games.

I would (and have resorted to such tactics in the past with games such as Killing Floor 1 where the Windows builds are better), but everyone else in the Lifeless Planet Steam community forums seem to be getting great performance with the free software drivers. Looking that this article with the R9 285 benchmarks, it seems clear to me why that is.

[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.

[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.

[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.

[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).

[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?

[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?

[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

[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?