Announcement

Collapse
No announcement yet.

Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads

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

  • #31
    When crypto prices crash AMD will start caring about the people that held in there keeping them afloat when every one else moved to NVidia and Intel. But then they will claim to be to poor to fix any thing.

    Comment


    • #32
      Originally posted by Qaridarium View Post

      why not put a RDNA and a CDNA chip on consumer graphic card?
      this way people can use graphics and compute at the same time.
      to do a chiplet design for RDNA is very hard but if you do hybrid RDNA+CDNA the chiplet design would be very easy.
      many people here would not have these problems with using compute and graphics at the same time with a card like this.
      so they can use MESA on RDNA and ROCm on the CDNA part.
      That would be called VEGA10/20.... (GCNX.X)

      Comment


      • #33
        Originally posted by bridgman View Post

        It's the other way round - it means that the ROCm components shipped with AMDGPU-PRO are part of a solution that does officially support both OpenCL and GUI apps.

        The messaging about not supporting GUI apps only applies to the ROCm *stack* (see previous post for more specifics), not the individual ROCm *components*.
        Is it possible, that at least then just now this time you guys could check up on Resolve/Blender and tell the devs what are they doing wrong, or how they should approach the components so the applications are working as they are supposed to? So at least both side could win in this situation?

        Comment


        • #34
          There was a reddit thread too, in the end they said they are reverting the commit and it was "internal misunderstanding".

          https://www.reddit.com/r/linux/comme...eb2x&context=3

          Comment


          • #35
            Originally posted by bridgman View Post

            In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work,
            In reality it doesn't. Radeon R9 380, Radeon RX 5600, RX 5700 XT and an AMD Ryzen 5 4500U on Kernel 5.9, 5.10, 5.11 (on Arch Linux) suffer from the same thing. shortly after the OpenCL app is started to do compute work ([email protected], Blender(cycles and radeon pro-render), sometimes even clinfo), the graphicscard seems to reset itself and the screen freezes. That's it. OpenSource ROCm stack that you build from the sources available is not usable at all for a desktop-users POV.

            Comment


            • #36
              I am a bit confused with this news. In a recent article here it was mentioned that RDNA2 cards have support for Rocm 4.0 with the included linux driver:
              https://www.phoronix.com/scan.php?pa...0-opencl&num=1

              I have an old Radeon RX570 polaris and it was as simple as installing the rocm-dev package (on Ubuntu 20.04) to start developing Julia language on GPU applications with Rocm and the AMDGPU.jl Julia package that is the equivalent to CUDA.jl on Julia.

              I was pleasantly surprised to find that ROCArrays work great and have almost identical functionality with the CUDA CUArrays on Julia and I was planning to buy a RDNA2 6800 card to do more testing on Julia GPU enabled applications.

              But now I am confused, is the Rocm supported on RDNA2 cards or not??

              On the official Rocm website says:
              "You can install ROCm user-level software without installing AMD’s custom ROCk kernel driver" simply by: "sudo apt install rocm-dev" which is what I did and it worked on my RX570 card. I know these packages are available on a selected number of distributions (Ubuntu LTS, CentOS, SLES etc) but I am not into distro hoping and that is fine with me.

              Comment


              • #37
                Originally posted by bridgman View Post

                There are two parallel activities going on:

                #1 - as you might have seen with the inclusion of ROCR-based OpenCL in the 20.45 AMDGPU-PRO packaged drivers, we are working on unifying the stacks so that users do not have to pick and choose between stacks depending on the work they want to do.

                The ROCm stack was developed independently at first so we could move more quickly but we are reaching the point where having multiple stacks is no longer a necessity. There is still quite a bit of work to do in order to get everything unified, however.

                #2 - in the short term we are trying to beef up the messaging to avoid confusion - the ROCm stack does not include all of the required graphics userspace components at the moment (eg Mesa) and does not go through graphics testing so we want to make that more clear.

                The one thing that the messaging does not make clear is that the limitations are mostly related to (a) kernel driver testing and (b) absence of userspace graphics components. In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work, and we want to ramp up testing and documentation in that area over time. We already organize the ROCm packages so that you can install userspace compute components separately from the kernel driver.
                The problem is not that ROCm can't be made to work if you try hard enough, nor that some people at AMD still care and are trying hard still for the Linux community. The real problem is the message this sends out to the entire software development community "AMD doesn't care about consumer compute".

                The people at BlackMagic, Blender, all the video editor people, all the machine learning lib guys, the GPU-accelerated visualization people (open source and other), they're going to see this and say "ah screw that. AMD doesn't care so there'll be no market. We don't need to spend the dough to support AMD". I'd argue that even some people at Apple will be looking at this and raising an eyebrow, even if they have their own compute stack (which, ironically, is the best way to get compute out of an AMD chip outside of a data centre).

                That's the real problem. The messaging is catastrophic. It's almost insane to put this up "currently" wording notwithstanding. The messaging should be "AMD is committed to compute across all market segments", (even if consumer compute is not a priority for now), at least this might keep some devs on board.



                Last edited by vegabook; 02 March 2021, 08:18 AM.

                Comment


                • #38
                  If the ROCr driver included in amdgpu-pro package is released under an open-source license, AMD should really make it as clear and as easy as possible for package maintainers of distributions to ship it as a regular package. Arch even ships Nvidia's blob kernel driver + their closed OpenCL driver, and of course also Intel's open NEO driver. Just AMD is not included (as Clover is not that usable yet and doesn't work at with Navi+ at all so far).

                  Comment


                  • #39
                    I think they made their messaging perfectly clear. It was clearly an intentional step and pivot. All they will do now is change the verbiage to try to gaslight us but I'm dead sure that internally nothing will change and there'll be business as usual. Meaning ignoring issues, bug reports, responding to people with prepared one line responses etc, more false promises.
                    It's time to cut our losses and jump ship before it sinks and takes us with it. I'm selling my hw.

                    I wonder if we all didn't put so much faith in AMD if we could have lobbied Nvidia to release an open source driver by now.
                    Instead we've put all our eggs in one basket. The basket fell and we ended up with all our eggs broken.

                    Comment


                    • #40
                      Originally posted by AresMinos View Post
                      I think they made their messaging perfectly clear. It was clearly an intentional step and pivot. All they will do now is change the verbiage to try to gaslight us but I'm dead sure that internally nothing will change and there'll be business as usual. Meaning ignoring issues, bug reports, responding to people with prepared one line responses etc, more false promises.
                      It's time to cut our losses and jump ship before it sinks and takes us with it. I'm selling my hw.

                      I wonder if we all didn't put so much faith in AMD if we could have lobbied Nvidia to release an open source driver by now.
                      Instead we've put all our eggs in one basket. The basket fell and we ended up with all our eggs broken.
                      I had already written a message which sounded just like yours. I have to say. Mine was angrier still, so I erased it, but I feel exactly like you do. I have this Radeon VII, i'm tired of watching it glow red while its 14 teraflops go unused. I get more Gflops out of my Jetson Nano! I'm thinking of selling the RVII, living on a crappy old 1030 card I have lying around until Intel brings their stuff to the party.

                      I'm very disappointed and my long, long support of AMD has taken a very serious beating.

                      Comment

                      Working...
                      X