Announcement

Collapse
No announcement yet.

AMD's ROCm 1.4 Now Available With OpenCL Support

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

  • #21
    Originally posted by smitty3268 View Post
    I get that, but that's why it really surprises me that Ubuntu is your target. Shouldn't it be RHEL and SLES? I mean, I get having Ubuntu as an option, but it seems like the period of having it be the only option has gone a bit long. Adding Fedora support once upon a time just makes it seem more like you were interested in modern updated kernels rather than enterprisey support.
    Good questions. First we needed to target developer systems (that's where Ubuntu & Fedora came in) for application coding and porting, and only then do we need support for deployment systems (working on that now). Ubuntu was convenient because the LTS versions end up being used for both development and deployment.

    Originally posted by smitty3268 View Post
    Perhaps i phrased that poorly, but all i meant was the switch to using mostly OSS amdgpu code rather than the fully closed fglrx codebase. I think you'd agree it was a big switch and has caused you issues properly supporting different distros.
    Definitely... it wasn't quite "starting over" but pretty close. The plan was to finish the transition by the end of 2016 - we'll probably run a bit past that but not much.
    Last edited by bridgman; 19 December 2016, 11:12 PM.
    Test signature

    Comment


    • #22
      Originally posted by bridgman View Post

      SUSE is next on the list, probably OpenSUSE first then SLE*



      AFAIK the only binary package that doesn't come with source code is the preview OpenCL runtime - is there something else I missed ?
      based on a few proprietary drivers out there, probably going to be nearly the same if not the same packages for 42.2 and 12sp2, but ill take whatever order and work from there

      and for closed bits, yes i meant opencl and potentially the assembler if they're still shipping hsail (didn't confirm on my part). this is a transient state with closed bits yes, but its where we're at and has implications on packaging...

      Comment


      • #23
        After visiting github repo I guess it is pretty much safe to rename the whole thing to SUXm.

        Not Supported or Very Limited Support Under ROCm

        We do not support ROCm with PCIe Gen 2 enabled CPUs such as the AMD Opteron, Phenom, Phenom II, Athlon, Athlon X2, Athlon II and Older Intel Xeon and Intel Core Architecture and Pentium CPUs.
        We also do not support AMD Carrizo and Kaveri APU as host for compliant dGPU attachments.
        Thunderbolt 1 and 2 enabled GPU’s are not supported by ROCm. Thunderbolt 1 & 2 are PCIe Gen2 based.
        AMD Carrizo based APUs have limited support due to OEM & ODM’s choices when it comes to some key configuration parameters. On point, we have observed that Carrizo Laptops, AIOs and Desktop systems showed inconsistencies in exposing and enabling the System BIOS parameters required by the ROCm stack. Before purchasing a Carrizo system for ROCm, please verify that the BIOS provides an option for enabling IOMMUv2. If this is the case, the final requirement is associated with correct CRAT table support - please inquire with the OEM about the latter.
        AMD Merlin/Falcon Embedded System is also not currently supported by the public Repo.
        Oh sweet, so everyone who bought crap listed above are bunch of losers, and would not get appropriate HW support, aren't they? At very most some of them could try to bug OEMs. Imagine how it would work with proprietary BIOS vendors, known for their ability to fix bugs and add features, ha-ha. So AMD customers have a good choice. Who's middle finger do they prefer? Not to mention you losers bought really wrong boards and wrongest decision was the fact it is AMD. Because there are no "right" AMD solutions matching AMD's demands, no? Double facepalm.

        In our experience many issues stem from trying to use consumer motherboards which provide Physical x16 Connectors that are electrically connected as e.g. PCIe Gen2 x4.
        And it has been so flipping smart to set sail for fail from the very beginning, making this utter crap so picky on configurations and assuming world is going to be in perfect shape AMD has imagined... so it turns out one can't even buy compliant configuratoin from AMD, so AMD ends up advertising ... newest Intel CPUs! Seriously?! Hey, AMD, I'm sorry to inform you but your management is FUBAR if it comes to bizarre crap like this. Of course everyone would rush to buy newer AMD things (which AMD just does not sells). And when they would do, it would take like a half year to declare this crap obsolete, without delivering working drivers&SW stack, as usually, eh? Not to mention AMD market share in server market is FAIL so have fun trying to find AMD server board. Then AMD would have fun trying to find devs who are aware WTF is this ROCm thing because .. because it's not like if I see devs interested in GPGPU running non-existing AMD cpus on server-grade boards with perfect bug-free BIOS every day. And somehow it seems AMD lacks backup plans if it turns out this world isn't THAT perfect so it does not works THAT good.

        TL;DR: seems release notes basically say EACH AND EVERY amd cpu users to the date are, uhm, losers. Most GPU owners are in the same boat, too.
        Last edited by SystemCrasher; 19 January 2017, 09:31 AM.

        Comment

        Working...
        X