https://github.com/RadeonOpenCompute/ROCm/issues/1180
I think the article you mention only says tha openCL works on those cards.
> " 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 ..
https://github.com/RadeonOpenCompute/ROCm#hardware-and-softw...
The best way to get Pytorch working is to use the rocm provided docker images: https://hub.docker.com/r/rocm/pytorch. Unfortunately it doesn't seem like the latest GPUs are supported (yet?)
Of course that's just for this year (which is ending soon), but there is also no commitment at all to ever supporting NAVI.
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.
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.
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.
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.
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.
Nowadays MS has actually published the spec for DX that was closed previously. See https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_... for differences of strict IEEE behaviour. In Cuda and OpenCL one can get way closer. As an example for performance reasons one might want to flush denorms to zero. But DX mandates that. So no denormals for you. In CL and Cuda they’re usable by default.
As for the command queues. I’ve often used them in Cuda. Just to get overlap between kernel executions. In DX12 one can do that by omitting barriers. DX11 allows no such feat.
It does, but you can always disassemble the DXBC and see what happened to your HLSL code.
> DX11 allows no such feat.
ID3D11DeviceContext::Dispatch is asynchronous just like CopyResource. Dispatch multiple shaders, and unless they have data dependencies (i.e. same buffer written by one as UAV and read by the next one as SRV) they'll happily run in parallel. No need for manual shenanigans with command queues.
And you can always disasm X86 code and see what -ffast-math did. Doesn't mean that everyone would be fine with just mandating it everywhere with no option to disable it.
Even then the DX functional spec gives some leeway. As an example if you write x*y+z it will compile it into mad instruction. And that's just specified as that the precision must not be worse as the worst possible ordering of separate instructions. So which it is? Depends on the vendor. This is completely fine for graphics, but not fine for all workloads.
> No need for manual shenanigans with command queues
Unless you do access same buffer from multiple places in a way that's still spec conformant, just in a way that the DX11 implementation cannot detect.
Practically speaking, often I enable it everywhere even on CPU (or similar options in visual C++). When more precision is needed, FP64 is the way to go. Apart from rare edge cases, you won't be getting many useful mantissa bits in these denormals, or with better rounding order.
> So which it is? Depends on the vendor.
Yeah, but on the same nVidia GPU, I'm pretty sure mad in DXBC does precisely the same thing as fma in CUDA PTX.
> just in a way that the DX11 implementation cannot detect
It doesn't detect much. If you want to allow shaders to arbitrarily read and write the same buffer, bind that buffer as UAV and you'll be able to run many of these shaders in parallel, despite a single queue.
P.S. AFAIK the main use case for these queues is high-end graphics, to send relatively cheap GPU tasks at huge rate (like 1MHz of them), from many CPU cores in parallel. In GPU compute, at least in my experience, the tasks tend to be much larger.
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