AMD's RadeonSI Driver Sped Up A Lot This Summer

[bridgman]

Can you give a ballpark estimate on when the OSS support or GPU based OpenCL/HSA will be ready? Looking at http://dri.freedesktop.org/wiki/GalliumCompute/ it looks like theres still a ton of work to be done to reach OpenCL 1.0 even after all this time, let alone 1.1, 1.2 and 2.0.

For HSA on Kaveri we're aiming to have everything finished and open in 2014, although opening the Finalizer may drag on past that. For OpenCL not sure yet -- we're trying to get more people working on it and open up more code from our proprietary implementation, so rate of progress should improve but I don't know how much yet.

[Bucic]

For HSA on Kaveri we're aiming to have everything finished and open in 2014, although opening the Finalizer may drag on past that. For OpenCL not sure yet -- we're trying to get more people working on it and open up more code from our proprietary implementation, so rate of progress should improve but I don't know how much yet.

Is linux HSA support for APU Kaveri and later architectures?

[bridgman]

Is linux HSA support for APU Kaveri and later architectures?

Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

http://www.hsafoundation.com/standards/

Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.

[Kivada]

Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

http://www.hsafoundation.com/standards/

Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.

Any hope for Kabini to get partial support?

[Bucic]

Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

http://www.hsafoundation.com/standards/

Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.

Thank you!
Any idea whether your average office/internet browser mole is going to benefit from KAveri HSA on Linux?

[Guest]

Some users reported great stability with current agd5f's drm-fixes-3.17 kernel so i installed it and will try hard to broke it in the next few days

Of course that by reading bugzilla and trying to avoid known bugs .

Ah; I'll have to look into getting that set up.

Was using today's 3.17 daily, and had 4 GPU crashes in a row with browsing Plex's website in Chrome... I fell back to kernel 3.14.18 a bit ago, and so far browsing is peaceful