Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • nuetzel
    replied
    Originally posted by Marc Driftmeyer View Post
    Both PCI-E 2 and 3 have Atomic Ops.

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

    here comes a copy from Marek's post on mesa-devel about:

    Re: [Mesa-dev] What is the difference between ROCm and Clover?
    [-]
    > For what it's worth, if you have an "older" system without PCIe 3.0 atomics,
    > you could still try and see how far you get with ROCm. As long as you don't
    > *actually* need atomics between the CPU and GPU in your own code, you're
    > probably fine. I've never tried it, though.

    I can confirm with 100% certainty that PCIe 3.0 atomics aren't
    required if you don't need them. In the majority cases, you don't need
    them.

    Marek
    https://lists.freedesktop.org/archiv...er/168482.html

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by duby229 View Post

    According to what I just read the -only- CPU's AMD has that can work are the new Zen based products.
    Well probably this will go down the stack later on, is not like it works now either way(is no easy at all to set up) and if I got this right you still need branched code from Clang/LLVM and other parts of RoCM that are not upstream yet.

    Probably you should start to worry(or celebrate) about April next year, I don't see OpenCL being in any upstream usable form before beside I'm not sure yet if they will use HMM for OpenCL 2.1+ either.

    Note: this article refers only to the current upstreamed code in 4.14, so is not like a declaration that it won't work with older hardware, is just what so far has landed is for the newer hardware.

    Leave a comment:


  • duby229
    replied
    Originally posted by jrch2k8 View Post

    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
    According to what I just read the -only- CPU's AMD has that can work are the new Zen based products.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by duby229 View Post
    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

    Leave a comment:


  • duby229
    replied
    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!

    Leave a comment:


  • pal666
    replied
    Originally posted by Marc Driftmeyer View Post
    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

    Leave a comment:


  • Jumbotron
    replied
    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.

    Leave a comment:


  • Marc Driftmeyer
    replied
    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.

    Leave a comment:


  • Berniyh
    replied
    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.

    Leave a comment:


  • schwarzman
    replied
    Originally posted by blacknova View Post
    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.

    Leave a comment:

Working...
X