So, one of the reasons why we could implement the #HIP backend easily in #GPUSPH is that #AMD provides #ROCm drop-in replacement for much of the #NVIDIA #CUDA‌ libraries, including #rocThrust, which (as I mentioned in the other thread) is a fork of #Thrust with a #HIP/‌#ROCm backend.
This is good as it reduces porting effort, *but* it also means you have to trust the quality of the provided implementation.

Anyway, as I mentioned recently, I have a new workstation that finally allows me to test our code using all three backends (#CUDA, #ROCm/‌#HIP and #CPU w/ #OpeMP) thanks to having an #AMD #Ryzen processor with an integrated #GPU in addition to a discrete #NVIDIA‌ GPU.
Of course the iGPU is massively underpowered compared to the high-end dGPU workhorse, but I would expect to outperform the CPU on most workloads.
And this is where things get interesting.

So obviously I took the opportunity to install both #CUDA and #HIP‌/‌#ROCm and make sure our software still built and ran correctly.
And honestly, it's unpleasant that in 2023 you still have to do some hoop jumping for either platform.
With CUDA, the issue is always making sure that you have a supported gcc version.
With ROCm, it's easy to trip on unsupported/untested hardware to find the right combination of env vars and define to make it go.

Corporate #FLOSS at its worst: #NVIDIA controls the #Thrust library and its #CUDA, #OpenMP and #TBB backend. #AMD provides rocThrust, that is just Thrust with the CUDA part stripped an a new backend for #ROCm / #HIP. Nobody* is working on a backend for #SYCL
#Intel provides its own #oneAPI alternative as #oneDPL, which is NOT a drop-in replacement.

This is why we can't have nice things.

*there's a dead project here
https://github.com/wdmapp/syclthrust

Making progress with #AMD #ROCm on the #SteamDeck for #GPUSPH. One does need to install the @archlinux community repo, to get the packages, but that's relatively painless. However:

Auto-detected GCN arch gfx1033 with flag 0x97ff (AMD Custom GPU 0405)
error: Illegal instruction detected: Invalid dpp_ctrl value: broadcasts are not supported on GFX10+
renamable $vgpr39 = V_MOV_B32_dpp undef $vgpr39(tied-def 0), killed $vgpr52, 322, 15, 15, 0, implicit $exec

I'll have to look into this.

Does anybody know if the #AMD #ROCm stack works on he #Valve #SteamDeck?

Asking for a friend
#askFedi

Oh, #Debian #sid seems to be finally transitioning more aggressively to #python3, which on the one hand, nice, on the other, it's breaking all my oldish python2-based #rocm versions. No more testing on those, it seems.

Oh, #Debian #side seems to be finally transitioning more aggressively to #python3, which on the one hand, nice, on the other, it's breaking all my oldish python2-based #rocm versions. No more testing on those, it seems.

@ashwinvis The #ROCm stack might or might not work. #HIP is more likely to work than #OpenCL in my experience, unless you build the stack yourself, because the #AMD-shipped packages tend to disable OpenCL for older archs (even if it runs, it's not supported).
I found the only way to check if it works or not is to install the packages and try.

@anteru may have more information or may be able to direct you to it.

Do you know if it is possible to do #GPU computing with AMD integrated graphics? Say on:

AMD Radeon™ RX Vega 6 Graphics (AMD Ryzen 5 4600H)

I read through here, but it is not very clear to me.

https://github.com/RadeonOpenCompute/ROCm#hardware-and-software-support

#OpenCL #ROCm #HIP #GPGPU
#help #fedihelp