Linux 4.14 + ROCm Might End Up Working Out For Kaveri & Carrizo APUs

[phoronix]

Phoronix: Linux 4.14 + ROCm Might End Up Working Out For Kaveri & Carrizo APUs

It looks like the upstream Linux 4.14 kernel may end up playing nicely with the ROCm OpenCL compute stack, if you are on a Kaveri or Carrizo system...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.14-ROCm-KV-CZ

[duby229]

Yes. Get it upstream. I think that is -the- solution to this problem described here. Or at minimum it will help alleviate it.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/978664-nouveau-developers-remain-blocked-by-nvidia-from-advancing-open-source-driver?p=978746#post978746

[blacknova]

What about ROCm on non PCI-E 3 capable systems? Current closed source stack seem to be working fine, but ROCm seem to support only PCI-E 3 systemes, at least accordinly to their wiki.

[schwarzman]

What about ROCm on non PCI-E 3 capable systems? Current closed source stack seem to be working fine, but ROCm seem to support only PCI-E 3 systemes, at least accordinly to their wiki.

In think this is about PCIe atomics (provided by PCIe 3.0) but you should be able to run ROCm unless you use features which rely on PCIe atomics. So many simpler compute tasks should work fine AFAIK.

[Berniyh]

Ok, this is a good step forward, but it's still a bit vague.

From the title I'd have expected to read in the text that with 4.14, you just compile&install rocm and are good to go.
Well, I guess not …
Hopefully they can sort it out quickly that at least the kernel can be crossed off the TODO list meaning that it's basically working without a special tree, because right now if you want to try rocm, you're stuck at some random version on which they base their stuff upon.
And don't even think about merging unless you really know what you're doing because there will be a lot of conflicts even if you try to merge minor version updates for the respective stable version of the kernel.

[Marc Driftmeyer]

Both PCI-E 2 and 3 have Atomic Ops.

https://pcisig.com/sites/default/fil...Ops_080417.pdf (2.x)

https://www.mindshare.com/files/reso...PCIe%203-0.pdf (3.x)

From what I can tell the difference is 3.x introduces

AtomicOp Completion

– new completion to give the results of an atomic request and indicate that the atomicity of the transaction has been maintained.

Since AtomicOps are not locked they don’t have the performance downsides of the PCI locked protocol. Compared to locked cycles, they provide “lower latency, higher scalability, advanced synchronization algorithms, and dramatically lower impact on other PCIe traffic.” The lock mechanism can still be used across a bridge to PCI or PCI-X to achieve the desired operation.

AtomicOps can go from device to device, device to host, or host to device. Each completer indicates whether it supports this capability and guarantees atomic access if it does. The ability to route AtomicOps is also indicated in the registers for a given port.

Sure seems like a very limited use case for what we are seeing OpenCL being used for and definitely not in the likes of Rendering, CAD/CAM, Compositing, etc., software. The lack of specificity by AMD on the support is really myopic in their clarification of what the hell the differences are and why even bother citing PCI-E 3 as the baseline since neither APU is PCEI 3.x based motherboards other than the switchover case on the AM3+/AM4 bridge of Bristol Ridge/Stoney Ridge APUs before Raven Ridge Zen APUs.

Virtually no one is clamoring for those before the Zen APUs arrive, but there certainly are large quantities of GCN boards ala GCN 1.1+ [Volcanic Island/Artic Island] on PCI-E 2.x boards for AM3+ sockets that are OpenCL 2.x ready twiddling their thumbs for actual OpenCL support to be leveraged [raises hand over here with the RX 480].

The sheer lack of clarity from a professional standpoint is shotty, at best.

[Jumbotron]

Woo Hoo !! And I would imagine that this would work on Bristol Ridge APUs seeing as how they are a process enhanced Carrizo. Faster clocks and better power management and all.

[pal666]

The sheer lack of clarity from a professional standpoint is shotty, at best.

https://github.com/RadeonOpenCompute...tion-Guide.rst
https://github.com/RadeonOpenCompute...Ie-Atomics.rst

[duby229]

I really don't know anything about this, but these are just my thoughts rattling around. It seems to me that OpenCL existed -long- before PCIe3 did, so that at minimum suggests they are using atomic ops in places where it isn't required. It may well be that it makes coding this implementation easier for them, that might be fair enough if true. But it basically means that most current AMD customers are not gonna be able to use it. And that is just like shooting yourself in your own damn foot!

[jrch2k8]

I really don't know anything about this, but these are just my thoughts rattling around. It seems to me that OpenCL existed -long- before PCIe3 did, so that at minimum suggests they are using atomic ops in places where it isn't required. It may well be that it makes coding this implementation easier for them, that might be fair enough if true. But it basically means that most current AMD customers are not gonna be able to use it. And that is just like shooting yourself in your own damn foot!

Well PCIe 3.0 is pretty damn common for 99% of their user base and those with hardware old enough to be running PCIe 2.0 or less probably won't have much use for modern OpenCL either way since the speed up won't be too dramatic on that much older APU.

Also notice this for HSA aka APUs, as far as I know this won't affect GCN discreet cards OpenCL stack