|author||Thomas Debesse <email@example.com>||2021-11-24 15:30:29 +0100|
|committer||Lyude Paul <firstname.lastname@example.org>||2021-11-29 18:42:00 -0500|
This reverts commit 1067bdb471f5958cfb92d1e34218b5dbb43bf2f2. None of AMD GPUs families can be marked as DONE (ROCm) for Compute (OpenCL). For “S.Islands”, the Sea Islands/GFX7/GCN2 GPUs aren't supported by ROCm anymore: https://github.com/RadeonOpenCompute/ROCm/issues/691#issuecomment-755892700 https://github.com/RadeonOpenCompute/ROCm/issues/640#issuecomment-755270261 And it only worked for few days in 2018, it is broken for years, now considered unsupported by ROCm and if someone attempts to run it with such GPU plugged in, it would wreck the kernel and the user will be asked to reboot: https://github.com/RadeonOpenCompute/ROCm/issues/1624 Only one chip was attempted to be supported (Hawaii) so even if it was actually working (it is not), it would not be possible to mark the whole family as ”DONE” For “C.Islands”, the Volcanic Islands/GFX8/GCN3,GCN4 aren't supported by ROCm anymore: https://github.com/RadeonOpenCompute/ROCm/issues/1373#issuecomment-775667363 https://github.com/RadeonOpenCompute/ROCm/issues/1356#issuecomment-755070302 I'm not sure ROCm ever worked for them one day, to begin with. Also, ROCm only enabled two GFX8 chips (Polaris 11 and Polaris 12), so even if it was actually working (it is not), it would not be possible to mark the whole family as “DONE”. Also, it was explicitly said the implementation was only targetting platforms with PCIe Atomics, which prevents to mark the family as “DONE” as well. For “A.Islands” (the meaning is not docummented), it's not possible to mark the whole family as “DONE” since, if we consider all GPUs after C.Islands and GCN4, ROCm only documents two GFX9 chips (Vega 10 and Vega 7nm) and one CDNA chip (MI100): https://github.com/RadeonOpenCompute/ROCm/blob/9b82c422d063847fce73d4b5d58f4a68fcebdb69/README.md?plain=1#L565 If the list is probably incomplete (and not updated for new architectures like RDNA, RDNA2, etc.) unless otherwise stated it should be considered only a handful of chips are actually targeted, or attempted to be targetted, because that's how ROCm development and communication always behaved: focusing on a handful of Radeon Pro devices and sometime some top-of-the line consumer devices being close to them. Also, the ROCm readme document also explicitly state that integrated GPUs of Ryzen are not officially supported: https://github.com/RadeonOpenCompute/ROCm/blob/9b82c422d063847fce73d4b5d58f4a68fcebdb69/README.md?plain=1#L565 The ROCm readme explicitly states some of the hardware from the families wrongly marked as DONE prior to this change are not supported, like “Tonga”, “Iceland”, “Vega M”, “Vega 12”, “Carrizo”, “Kaveri”. Some others like “Fiji” and “Polaris” are also explicitly listed as unsupported on hosts without PCIe Atomics: https://github.com/RadeonOpenCompute/ROCm/blob/9b82c422d063847fce73d4b5d58f4a68fcebdb69/README.md?plain=1#L654-L657 This prevents to mark as “DONE” the OpenCL support for the related families of AMD hardware. In a general manner, the ROCm readme document also explicitly states that ROCm is a compute stack for headless system deployment and that GUI based software applications are currently not supported: https://github.com/RadeonOpenCompute/ROCm/blob/9b82c422d063847fce73d4b5d58f4a68fcebdb69/README.md?plain=1#L560 This prevents to mark as “DONE” the OpenCL support for every family of AMD hardware. Outside of ROCm, the Mesa/Clover & LLVM/libclc effort has not yet reached a state making possible to mark any family of AMD hardware to be marked as DONE for OpenCL. - Image Support is not implemented yet: https://gitlab.freedesktop.org/mesa/mesa/-/issues/130 - Non-image workflows are not working (regression): https://gitlab.freedesktop.org/mesa/mesa/-/issues/5671 Those issues not being fixed prevents to mark related families of AMD hardare as DONE for OpenCL. For now, no one AMD GPU family can be marked as DONE for OpenCL.
Diffstat (limited to 'BoardOfDirectors/IrcLogs')
0 files changed, 0 insertions, 0 deletions