5 ms·

I think it's sad that AMD doesn't support ROCm (AMD's equivalent to CUDA) for those graphics cards. On the other hand NVIDIA supports cuda on basically every g

I think it's sad that AMD doesn't support ROCm (AMD's equivalent to CUDA) for those graphics cards. On the other hand NVIDIA supports cuda on basically every gpu... If you want to expiriment with gpu programming there is (sadly) no way around nvidia

Pet_Ant 6y ago
Isn't OpenCL still available?
- SXX 6y ago
  Most of software on market doesn't support OpenCL. ROCm worked quite well, but again AMD decide not to invest into software.
  - BadInformatics 6y ago
    People were (rightfully) complaining about OpenCL the most because of applications like Blender, so it's not surprising they highlighted it. Since the OpenCL implementation on question is built on ROCm, it may be that other ROCm-related stuff works as well. My impression from the various comments left by devs on Phoronix and elsewhere is that they've just managed to right the boat on the GPU side of things and are getting enough from their enterprise/HPC offerings (which they were solely focused on, to the detriment of all us consumers) to have some bandwidth to start tackling consumer compute support. I really hope they do so, because all the ROCm ecosystem could use some major TLC. Who knows, maybe this time next year you'll be able to install PyTorch with AMD GPU support OOTB.
    - SXX 6y ago
      One big reason why I buy AMD hardware is John Bridgman who actively participate in discussions about their hardware and drivers as well as long-term vision toward open source. So I believed in AMD and supported them for years (and actually made nice profit on their shares growth). To be honest I don't really need compute all that much other than for my own hobby projects. And for gaming I only play few games what suite my taste as well as tons of older or indie games that would work on any GPU. So why not, AMD open source drivers are decent anyway. Unfortunately it's hard to really recommend AMD GPUs when it's come to the real world experience. Modern gamers actually want all these lock-in features even if Nvidia gonna abandon them in couple of years. Then people who need compute for their work just want their software to work and it's simply too much of mess on non-Nvidia hardware.
dwardu 6y ago
I was going to wait for an AMD card for that, however im feeling somewhat happier that i ended up getting the 3080 rtx
zucker42 6y ago
This is incorrect according to this Phoronix article. Rocm opencl supposedly works on the 6800. https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-linux&num=1 https://www.phoronix.com/scan.php?page=article&item=amd-rx68... It might take a while for it to be available through standard distro distribution channels.
- irishsultan 6y ago
  Counterpoint: https://github.com/RadeonOpenCompute/ROCm/issues/1271#issuecomment-720307646 https://github.com/RadeonOpenCompute/ROCm/issues/1271#issuec... Of course that's just for this year (which is ending soon), but there is also no commitment at all to ever supporting NAVI.
- randomNumber7 6y ago
  According to this issue in the ROCm repo there is no ROCm for those gpus https://github.com/RadeonOpenCompute/ROCm/issues/1180 https://github.com/RadeonOpenCompute/ROCm/issues/1180 I think the article you mention only says tha openCL works on those cards.
  - zucker42 6y ago
    The article pretty clearly says ROCm OpenCL. As I understand, support is not all or nothing, so it's possible it works without being officially supported. However, I think you're correct we'll have to see what Phoronix and others report about the level of support and see what works.
  - BadInformatics 6y ago
    In addition to what the sibling comment said, OpenCL runs on the ROCm stack for RDNA1/2. That means all the low-level plumbing, drivers and software should be in place.
  - rfvrgvegbegn 6y ago
    https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-opencl&num=1 https://www.phoronix.com/scan.php?page=article&item=amd-rx68... > " While Radeon Open eCosystem (ROCm) support wasn't a focus for the initial Radeon RX 5000 "Navi" graphics cards by AMD engineers, that is fortunately changing for both the RX 5000/6000 series moving forward. " Rocm seems to be supported, works with PlaidML, I wonder if PyTorch works ? That's the main framework I really need ..
n0nc3 6y ago
You are right for now, but Julia already has an experimental ROCm stack. Rolling out full featured ROCm support could be a huge win for Julia user growth (and AMD). https://juliagpu.org/ https://juliagpu.org/
Const-me 6y ago
On Windows, DirectCompute is supported by both, and even Intel.
- sharpneli 6y ago
  That's just compute shaders in DirectX. They also support compute shaders in Vulkan and OpenGL. It's not exactly the same as Cuda and OpenCL. Especially the numerical precision requirements are way off on graphics apis. And by way off I mean they're not always even specified what they should be.
  - Const-me 6y ago
    Have a link? In my experience, the precision in DirectCompute is the same as on CPUs, specifically it's traditional 32-bit IEEE floats. Same for FP64.
    - sharpneli 6y ago
      Basic fp ops like +-*/ are fine generally. It's more about the ability to prevent reodering of instructions (so that Kahan summation etc is not screwed up), and having well defined spec for the precision of things like transcendental functions. HLSL is bit better at controlling this than GLSL is. It has also improved greatly. Using workgroup shared memory is now a thing. And also one can use subgroup ops that have been in Cuda for years. Some of the other things like commandqueues are in Vulkan and DirectX12. But oh boy those are pain to program in compared to OpenCL or Cuda. Usability matters too.
      - Const-me 6y ago
        > to prevent reodering of instructions GPUs don’t reorder, their EUs are way too simple for that. Are you certain GPU drivers reorder instructions while recompiling DXBC into their microcode? > HLSL is bit better at controlling this than GLSL is. BTW, if you compile acos() in HLSL and disassemble the output DXBC, you’ll see a really strange sequence of 10 instructions (mad, mad, mad, add, lt, sqrt, mul, mad, and, mad) . The precision is indeed lost that way. Still, if you really need that, you can implement full-precision stuff on top of what’s available. > Using workgroup shared memory is now a thing Was always there. CUDA 1.0 was released in 2007, D3D 11 in 2008. > But oh boy those are pain to program in compared to OpenCL or Cuda. D3D 12 is a pain to program in general, too low level. But for GPGPU, I personally never needed command queues, I’m quite happy with old-school D3D 11. Despite the API is mostly single threaded, with some care you can do stuff in parallel. Things like ID3D11DeviceContext::CopyResource are asynchronous, you can go quite far with deeply pipelined commands without doing it manually like you have to in D3D12.
ArtWomb 6y ago
NVidia toolchain and profilers are mature. But CUDA will experience lots of viable competition. DPC++ / SYCL could emerge: https://github.com/Apress/data-parallel-CPP https://github.com/Apress/data-parallel-CPP https://github.com/codeplaysoftware https://github.com/codeplaysoftware

Pet_Ant 6y ago

Isn't OpenCL still available?

SXX 6y ago
Most of software on market doesn't support OpenCL. ROCm worked quite well, but again AMD decide not to invest into software.
- BadInformatics 6y ago
  People were (rightfully) complaining about OpenCL the most because of applications like Blender, so it's not surprising they highlighted it. Since the OpenCL implementation on question is built on ROCm, it may be that other ROCm-related stuff works as well. My impression from the various comments left by devs on Phoronix and elsewhere is that they've just managed to right the boat on the GPU side of things and are getting enough from their enterprise/HPC offerings (which they were solely focused on, to the detriment of all us consumers) to have some bandwidth to start tackling consumer compute support. I really hope they do so, because all the ROCm ecosystem could use some major TLC. Who knows, maybe this time next year you'll be able to install PyTorch with AMD GPU support OOTB.
  - SXX 6y ago
    One big reason why I buy AMD hardware is John Bridgman who actively participate in discussions about their hardware and drivers as well as long-term vision toward open source. So I believed in AMD and supported them for years (and actually made nice profit on their shares growth). To be honest I don't really need compute all that much other than for my own hobby projects. And for gaming I only play few games what suite my taste as well as tons of older or indie games that would work on any GPU. So why not, AMD open source drivers are decent anyway. Unfortunately it's hard to really recommend AMD GPUs when it's come to the real world experience. Modern gamers actually want all these lock-in features even if Nvidia gonna abandon them in couple of years. Then people who need compute for their work just want their software to work and it's simply too much of mess on non-Nvidia hardware.

dwardu 6y ago

I was going to wait for an AMD card for that, however im feeling somewhat happier that i ended up getting the 3080 rtx

zucker42 6y ago

This is incorrect according to this Phoronix article. Rocm opencl supposedly works on the 6800. https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-linux&num=1 https://www.phoronix.com/scan.php?page=article&item=amd-rx68... It might take a while for it to be available through standard distro distribution channels.

irishsultan 6y ago
Counterpoint: https://github.com/RadeonOpenCompute/ROCm/issues/1271#issuecomment-720307646 https://github.com/RadeonOpenCompute/ROCm/issues/1271#issuec... Of course that's just for this year (which is ending soon), but there is also no commitment at all to ever supporting NAVI.
randomNumber7 6y ago
According to this issue in the ROCm repo there is no ROCm for those gpus https://github.com/RadeonOpenCompute/ROCm/issues/1180 https://github.com/RadeonOpenCompute/ROCm/issues/1180 I think the article you mention only says tha openCL works on those cards.
- zucker42 6y ago
  The article pretty clearly says ROCm OpenCL. As I understand, support is not all or nothing, so it's possible it works without being officially supported. However, I think you're correct we'll have to see what Phoronix and others report about the level of support and see what works.
- BadInformatics 6y ago
  In addition to what the sibling comment said, OpenCL runs on the ROCm stack for RDNA1/2. That means all the low-level plumbing, drivers and software should be in place.
- rfvrgvegbegn 6y ago
  https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-opencl&num=1 https://www.phoronix.com/scan.php?page=article&item=amd-rx68... > " While Radeon Open eCosystem (ROCm) support wasn't a focus for the initial Radeon RX 5000 "Navi" graphics cards by AMD engineers, that is fortunately changing for both the RX 5000/6000 series moving forward. " Rocm seems to be supported, works with PlaidML, I wonder if PyTorch works ? That's the main framework I really need ..

n0nc3 6y ago

You are right for now, but Julia already has an experimental ROCm stack. Rolling out full featured ROCm support could be a huge win for Julia user growth (and AMD). https://juliagpu.org/ https://juliagpu.org/

Const-me 6y ago

On Windows, DirectCompute is supported by both, and even Intel.

sharpneli 6y ago
That's just compute shaders in DirectX. They also support compute shaders in Vulkan and OpenGL. It's not exactly the same as Cuda and OpenCL. Especially the numerical precision requirements are way off on graphics apis. And by way off I mean they're not always even specified what they should be.
- Const-me 6y ago
  Have a link? In my experience, the precision in DirectCompute is the same as on CPUs, specifically it's traditional 32-bit IEEE floats. Same for FP64.
  - sharpneli 6y ago
    Basic fp ops like +-*/ are fine generally. It's more about the ability to prevent reodering of instructions (so that Kahan summation etc is not screwed up), and having well defined spec for the precision of things like transcendental functions. HLSL is bit better at controlling this than GLSL is. It has also improved greatly. Using workgroup shared memory is now a thing. And also one can use subgroup ops that have been in Cuda for years. Some of the other things like commandqueues are in Vulkan and DirectX12. But oh boy those are pain to program in compared to OpenCL or Cuda. Usability matters too.
    - Const-me 6y ago
      > to prevent reodering of instructions GPUs don’t reorder, their EUs are way too simple for that. Are you certain GPU drivers reorder instructions while recompiling DXBC into their microcode? > HLSL is bit better at controlling this than GLSL is. BTW, if you compile acos() in HLSL and disassemble the output DXBC, you’ll see a really strange sequence of 10 instructions (mad, mad, mad, add, lt, sqrt, mul, mad, and, mad) . The precision is indeed lost that way. Still, if you really need that, you can implement full-precision stuff on top of what’s available. > Using workgroup shared memory is now a thing Was always there. CUDA 1.0 was released in 2007, D3D 11 in 2008. > But oh boy those are pain to program in compared to OpenCL or Cuda. D3D 12 is a pain to program in general, too low level. But for GPGPU, I personally never needed command queues, I’m quite happy with old-school D3D 11. Despite the API is mostly single threaded, with some care you can do stuff in parallel. Things like ID3D11DeviceContext::CopyResource are asynchronous, you can go quite far with deeply pipelined commands without doing it manually like you have to in D3D12.

ArtWomb 6y ago

NVidia toolchain and profilers are mature. But CUDA will experience lots of viable competition. DPC++ / SYCL could emerge: https://github.com/Apress/data-parallel-CPP https://github.com/Apress/data-parallel-CPP https://github.com/codeplaysoftware https://github.com/codeplaysoftware