Announcement

Collapse
No announcement yet.

CuPy 9.0 Brings AMD GPU Support To This Numpy-Compatible Library

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

  • CuPy 9.0 Brings AMD GPU Support To This Numpy-Compatible Library

    Phoronix: CuPy 9.0 Brings AMD GPU Support To This Numpy-Compatible Library

    In recent months there has finally been more open-source projects traditionally focused on NVIDIA GPU compute beginning to offer mainline Radeon support using the open-source ROCm stack. Following the recent PyTorch 1.8 with ROCm support, CuPy 9.0 was released last week with that traditionally CUDA focused library now supporting AMD's ROCm stack...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Amazing. My Radeon card is able to go back to work now.

    Comment


    • #3
      If the only way to use it is with a binary blob why wouldn't you just stick with NVidia and Cuda for this use case?

      Comment


      • #4
        Originally posted by MadeUpName View Post
        If the only way to use it is with a binary blob why wouldn't you just stick with NVidia and Cuda for this use case?
        I didn't see anything saying that you were limited to binary blobs, just that officially built binaries with ROCm support were now available in addition to building from source which was the only option before.
        Test signature

        Comment


        • #5
          Originally posted by MadeUpName View Post
          If the only way to use it is with a binary blob why wouldn't you just stick with NVidia and Cuda for this use case?
          Why do you assume people owns an Nvidia to begin with?

          Also, even if there was one blob required (probably even not If I read previous comment correctly), why suffering closed blob for everything else like game rendering, video compression, etc. because of one single other app you may use?

          For example with my Radeon R9 390X I can have opensource Mesa radeonsi for OpenGL, opensource radv and amdvlk for Vulkan, opensource VAAPI implementation for accelerated video encoding, but I use closed source PAL for running OpenCL (I use Darktable), it would be a shame to go fully proprietary on everything because of one app or one API… Same for such kind of software that may require ROCm or some obscure libraries while everything else would be vanilla and open source…

          I remember when, at a time proprietary nvidia and proprietary ati fglrx were only viable option for gaming on Linux, some people were saying “if you put such proprietary blob your Linux, why don't just stick to Windows?”. Meh, please no. Better make a specific and limited compromise for one exception than to give up on everything.

          Comment

          Working...
          X