Announcement

Collapse
No announcement yet.

Radeon Open Compute 3.3 Released But Still Without Official Navi Support

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

  • Radeon Open Compute 3.3 Released But Still Without Official Navi Support

    Phoronix: Radeon Open Compute 3.3 Released But Still Without Official Navi Support

    This week marked the release of ROCm 3.3 as the newest version of the Radeon Open Compute stack...

    http://www.phoronix.com/scan.php?pag...m-3.3-Released

  • #2
    AMD really doesn't care about its users on the software side.
    The install process and support for their hardware is garbage level.
    I just tried to install ROCm on the beta build of Ubuntu 20.04 and guess what, ROCm is not installable because at least one of its components still depends on Python 2.
    There is a bug report from last year on their Github repository warning them that Ubuntu will remove Python 2, and they still did nothing about it.
    It's unbelievable that even if you're not running Navi, you still can't install and use ROCm.
    When the fuck will they understand that because this, people like miners are losing money and cannot wait for years until AMD gets its shit together ?
    I cannot believe that I say this, but I advise everyone who needs compute performance to just buy Nvidia and screw AMD with this crap they are keep pulling.
    I'm tired to see thise imbecile version numbers increasing following the idiocy of Chrome browser without fixin any of the major bugs and problems.
    Just to look for uninformed people like they are doing something and they are implementing major upgrade, when reality is that they are doing absolutely nothing.

    I hope that smarty pants guys will refrain to tell me that it's my fault that I'm using a yet not released distro.
    I honestly don't believe that ROCm will be installable even after it's officialy released this month.
    I bet it will take at least a year until they add support for that.
    And even after that, when I will upgrade the very old kernel that Ubuntu 20.04 comes with to 5.5 or 5.6, ROCm will again refuse to install because of that, like it did in the past.

    Comment


    • #3
      When the fuck will they understand that because this, people like miners are losing money and cannot wait for years until AMD gets its shit together?
      FWIW I couldn't really care less about crypto miners. It's a hype that never should've existed. It's a waste of both silicon and power at mass scales.

      It's unbelievable that even if you're not running Navi, you still can't install and use ROCm.
      You likely will never be able to. It has been stated before that advanced compute features are too much to ask of consumer HW, hence the distinction between amdgpu/amdkfd. This admission is further strengthened by the recent announcement of clear distincion between compute and gaming at the HW level. RDNA and CDNA will be two distinct paths for HW design, and I'd bet a larger amount that ROCm will very soon be exclusive to CDNA cards. Navi and other RDNA cards will have to use compatibility layers like hipcl, clvk or OpenCLOn12. Nvidia announced something very similar following the CDNA announcement, that their HW portfolio will also diverge further.

      We'll just have to get used to it.

      As for the install process and packaging experience yes, AMD has a lot of room for improvement, but you really have to cut them some slack for having a top-to-bottom open stack. The only reason you are bashing them for the packaging and build experice is because they have one! The binary blobs of Nv are certainly easier to deploy, but is it worth it?

      As for being unable to install on Ubuntu 20.04 Beta... nobody really cares, at least from AMD. Having said that ROCm targets professional / server compute, clusters aren't going to upgrade to beta OS, but likely won't go to Ubuntu 20.04 without a compelling and strong reason. Clusters upgrade at a slower cadance, much like enterprises (a bit better actually, but still slower than consumers). Trying to make consumer use of ROCm is a frustrating experience for sure, primarily because it's not designed to be used like that. If it were, it wouldn't go without Navi support for 9 months now. You have to read between the lines: ROCm is not for consumers, it's not going to officially support Navi, likely ever.

      Comment


      • #4
        Originally posted by Danny3 View Post
        ... long mental break down ...
        Garbage level? Really? To me, it appears as if most people are really happy with their AMD hardware on Linux. If you actually earn money with your system, you will never upgrade to bleeding edge software anyway simply because professionals actually validate their productivity setups. You just learned why. So stop crying about having turned your mining rig into a large overpriced space heater and settle down. Also, I hope that AMD will never focus lots of engineering resources on cryptomining. The sole fact that this exists just means that power should be more expensive.

        Comment


        • #5
          Originally posted by GruenSein View Post

          Garbage level? Really? To me, it appears as if most people are really happy with their AMD hardware on Linux. If you actually earn money with your system, you will never upgrade to bleeding edge software anyway simply because professionals actually validate their productivity setups. You just learned why. So stop crying about having turned your mining rig into a large overpriced space heater and settle down. Also, I hope that AMD will never focus lots of engineering resources on cryptomining. The sole fact that this exists just means that power should be more expensive.
          Yeah really.
          Did you forgot the bullshit fiasco of AMD launch last year with the new Ryzen processors that made Linux distros and systems unbootable ?
          Why? Because they haven't tested with a curent up to date distro instead of the very old LTS distros that they said they used.
          If they would've tested their hardware with an up to date distro they woul've seen their hardware bug sooner.

          What about temperature sensors support, have you seen how long people needed to wait for that ?
          And even now, the support for that came from someone else, not from AMD.

          People are happy with their AMD hardware on Linux is definitely a joke.
          AMD, compared to Intel, is really bad at supporting on time or optimizing software for their hardware.

          Comment


          • #6
            Originally posted by GruenSein View Post

            Garbage level? Really? To me, it appears as if most people are really happy with their AMD hardware on Linux. If you actually earn money with your system, you will never upgrade to bleeding edge software anyway simply because professionals actually validate their productivity setups. You just learned why. So stop crying about having turned your mining rig into a large overpriced space heater and settle down. Also, I hope that AMD will never focus lots of engineering resources on cryptomining. The sole fact that this exists just means that power should be more expensive.
            Depends. I am happy with my Ryzen 3700X on my X570 mobo. I am NOT HAPPY with the support for my RX5700 - and no one will convince me otherwise.

            ROCm might never surface, OpenCL is a PITA to install. (Am I supposed to buy a "professional grade" hardware because I like to do some renderings in Blender or work on my photos in darktable?).
            As for the Mesa drivers and the kernel - that's a bumpy road at best. A plain Ubuntu 20.04 with kernel 5.4 and Mesa 20.0.3 just "doesn't work". SOTR gives me 30fps in it's benchmark, when switching to mainline 5.5 or 5.6 kernel (everything else the same) it jumps to the expected 130fps. Having two displays connected frequently gives me problems when booting (powerplay reports that it can't determine the display frequencies - after a lengthy boot process it seems to fall back to some "reasonable" default). All this works only when avoiding the most recent BIOS files which gave me hard crashes... There are setups that work. My 18.04.4 Ubuntu with kernel 5.3, Mesa 20.0.3 (the Kisak PPA, others won't cut it) and BIOS files back from November works reliable. And people frequently tell me that with Arch everything might be fine... I suppose I am just asking too much, when I expect working drivers and setup for a (or the most) popular Linux distribution after the hardware hit the shelves 8 or 9 months ago.

            Comment


            • #7
              A lot of non-sense up above. OpenCL support is going to be as necessary as having a CPU or RAM. Just because your software of choice hasn't incorporated it yet doesn't mean it isn't coming. All of the graphics software I use has support and about half of that software has a hard dependency on it. Spreadsheets and all kind of other apps are incorporating it. It's coming, you just aren't aware yet. AMD and the distros need to get this figured out so it installs as simpily as every thing else. Most of the needed components have been around for a while what is missing as far as I know is an easy way to get updates for the thunk to the distros. This stuff used to work, there is no reason it couldn't again.

              Comment


              • #8
                Basically, ROCm is the best justification of the need for Clover/GalliumCompute. It is a waste that it is still underdeveloped, while it could solve OpenCL for consumers out of the box in MESA for all the hardware vendors. I hope it sees some love in the future. Let the more advanced frameworks for more specialized needs and give the consumer at last in 2020+ some freaking OpenCL support in MESA already....

                Comment


                • #9
                  Originally posted by Danny3 View Post
                  Did you forgot the bullshit fiasco of AMD launch last year with the new Ryzen processors that made Linux distros and systems unbootable ?
                  Why? Because they haven't tested with a curent up to date distro instead of the very old LTS distros that they said they used.
                  Actually it was because of a mistake with the rdrand instruction, which affected more than just up-to-date Linux distros. That was a hardware issue. AMD should've checked their work, but to be fair, it is a seldom used instruction.
                  If they would've tested their hardware with an up to date distro they woul've seen their hardware bug sooner.
                  You say that as though Linux is their #1 priority. It isn't. The only Linux users they really care about are servers, and those don't use up to date distros.
                  What about temperature sensors support, have you seen how long people needed to wait for that ?
                  Considering all the other hardware-related issues, an accurate temperature reading from the OS is hardly worth complaining about. Most people never look at their CPU temperature outside of the BIOS screen, if ever. Granted, Linux users are more likely to care, but still, it's not a big deal.
                  People are happy with their AMD hardware on Linux is definitely a joke.
                  AMD, compared to Intel, is really bad at supporting on time or optimizing software for their hardware.
                  Seems to you when it rains, it pours. If you're really that uptight about the best user experience possible, why are you using AMD? Why are you using Linux? Nobody is forcing you to buy AMD, and you clearly have bought both a CPU and GPU from them with misunderstood expectations. That's not their fault, that's yours. rdrand and the temperature reading is their fault, everything else you're complaining about isn't.

                  As stated before, stop getting all butthurt because you decided to invest in a BS source of income like crypto mining. I understand you don't like to work for anything but maybe try lifting a finger for once.

                  For the record, I don't have a problem with crypto mining for side cash, but it's stupid if you are seriously invested in it.
                  Last edited by schmidtbag; 04-04-2020, 01:48 PM.

                  Comment


                  • #10
                    Originally posted by Meteorhead View Post

                    It has been stated before that advanced compute features are too much to ask of consumer HW, hence the distinction between amdgpu/amdkfd. This admission is further strengthened by the recent announcement of clear distincion between compute and gaming at the HW level. RDNA and CDNA will be two distinct paths for HW design, and I'd bet a larger amount that ROCm will very soon be exclusive to CDNA cards. Navi and other RDNA cards will have to use compatibility layers like [Nvidia announced something very similar following the CDNA announcement, that their HW portfolio will also diverge further.

                    We'll just have to get used to it.
                    I don't really know what to think of this separation as I wanted to see GPGPU taking off in the desktop space sooner and this could slow down this advancement (and right before the corner of cache coherency finally arriving on a desktop platform). Or are we supposed to buy a compute card separatly soon or will we see CDNA becoming their new architecture path in iGPUs? I can see that this would make sense - as a great iGPU + dGPU combination so that a consumer could get the best of both worlds if they go the all-AMD route to build their computers. On the other hand their Vega approach also seems to be the more appealing these days as a middle ground between both worlds. It would also be potentially less work for AMD to support just one architecture going forward. I fear that RDNA won't get the same level of support as CDNA in their compute stack and it already shows, if ROCm on RDNA were a priority it would not take AMD over half a year to build that support. And as Tuxee already mentioned, the current situation is less than desireable, even more so for RDNA users who want to use their cards for desktop compute tasks.

                    Comment

                    Working...
                    X