Any update on 5700 Xt support?

Just curious if you have any plans on supporting the 5700 Xt card in the near future. As of now I haven't seen it in the supported GPUs list. Would be nice to also have it included!

There are different levels of support in ROCm, since it's an entire stack, which makes this a difficult question to answer.
1-Kernel support. This usually comes pretty quickly from upstream, and is already there in its infancy. The basic code is there, and there is work going on to thoroughly test the kernel functionality
2-Thunk support. This is usually pretty quick too, since it's mostly just adding the chip information, and then adding any weird quirks that the HW has (shader engine distribution, SDMA queues, etc)
3-Runtime support. This usually takes longer as there is a lot of testing to go on
4-Official ROCm support - Once we have 1-3 supported, we need to run the full gambit of tests and applications against the stack. This requires a lot of time, and a lot of bug-fixes. Once this is done, that's when we add it to the Supported GPUs list.
So there may be some partial support for it right now, or it might work almost perfectly. It's all a bit of a crapshoot until we update the documentation, as we haven't tested everything to fulfill our exit criteria for supporting a GPU. You can always try it out, and post PRs to help to support them in the interim, though. We always like help from the community!

Hi, in my experience GPUs listed as "supported" have no guarantee to work properly. I have opend a few issues here and the speed at which theses issues are fixed is extremely disappointing. The most annoying thing is missing OpenCL 2.0 support for hardware that is still beeing sold (gfx803).
I have zero confidence that the latest hardware will have OpenCL 2.0 support in ROCm, therefore I am not buying new hardware. There would be more business for AMD if the drivers delivered better OpenCL support.

@kentrussell Could you create a new issue for us to track Navi integration? You could create a task list to mark the process:

[ ] 1-Kernel support
[ ] 2-Thunk support
[ ] 3-Runtime support
[ ] 4-Official ROCm support

- [ ] 1-Kernel support
- [ ] 2-Thunk support
- [ ] 3-Runtime support
- [ ] 4-Official ROCm support

I'm new here, and don't know anything about anything, so it's perfectly fine that I chip in. ;) I'm interested in ROCm since I'm currently buying the 5700 XT for myself and wanted, aside from gaming, to play around with PyTorch and Tensorflow.
Seems like kernel support has been merged in on Sep 23rd, Thunk has support for Navi 10 since July, so we're getting there. Once I have the GPU and familiarize myself with the whole ecosystem, I'll see if I can contribute in any way.

@aak-amd @zhang2amd @Rmalavally @kentrussell Any updates about Navi/RDNA support?

It is kind of sad that AMD has forgotten Navi users. I have found a temporary solution to use my RX 5700XT for deep learning with rather astonishing results. I thought I should share it here. Using Linux kernel 5.6rc and AMDGPU PRO driver I was able to set up OpenCL 2.1 on Manjaro Linux. Then I installed PlaidML which supports opencl devices. After that, I set Keras backend to PlaidML and just used Keras. I ran some benchmarks and the results are just amazing. It outperforms my 12C/24T Ryzen 3900 CPU by a massive margin. While it takes more than 12 minutes to train MobileNet on Ryzen 3900X, it takes less than a minute on Radeon 5700XT.  Here are the Inference latency and Time/FPS comparison in mobilenet benchmark:
RX 5700 XT GPU:
Network Name         Inference Latency         Time / FPS
mobilenet            22.00 ms                  19.68 ms / 50.80 fps
Ryzen 3900X CPU:
Network Name         Inference Latency         Time / FPS
mobilenet            695.84 ms                 695.56 ms / 1.44 fps

ROCm-OpenCL-Runtime 3.1 changes introduced ROC_GFX10, that's Navi!
It still isn't listed as supported on the official documentation, but neither is any non deprecated Linux kernel...
Has anyone already tried 3.1 with Navi?

@FiCacador There are no clear instructions on how to compile ROCm from scratch. I downloaded all their sources codes using Google Repo tool and there are at least 40 different projects to compile separately! I couldn't find anyway to automate the building process. There is a project that supposed to automate the build process but has not been updates in the past few years. If the guys at AMD can illuminate us on how to automate ROCm compilation, it would be greatly appreciated. Anyway, I just checked the ROCm patched kernel and it was still 5.4 version. Not willing to go back to 5.4 as I need at least 5.5 for my needs (right now rocking 5.6rc).

There is no or no complete Navi support in ROCM 3.1 .
Tested with Radeon 5700XT, ROCM 3.1 and Tensorflow 2.1
gpu-user@gpu-server:~/benchmarks/scripts/tf_cnn_benchmarks$ python3 tf_cnn_benchmarks.py --num_gpus=1 --batch_size=64 --model=resnet50
WARNING:tensorflow:From /home/gpu-user/.local/lib/python3.6/site-packages/tensorflow_core/python/compat/v2_compat.py:88: disable_resource_variables (from tensorflow.python.ops.variable_scope) is deprecated and will be removed in a future version.
Instructions for updating:
non-resource variables are not supported in the long term
2020-03-10 19:45:39.130116: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE3 SSE4.1 SSE4.2 AVX AVX2 FMA
2020-03-10 19:45:39.155823: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency:<PHONE_NUMBER> Hz
2020-03-10 19:45:39.156223: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x4ed3e10 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-03-10 19:45:39.156330: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
2020-03-10 19:45:39.159225: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libhip_hcc.so
2020-03-10 19:45:39.193370: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1573] Found device 0 with properties:
pciBusID: 0000:2b:00.0 name: Device 731f     ROCm AMD GPU ISA: gfx1010
coreClock: 0.1GHz coreCount: 40 deviceMemorySize: 7.98GiB deviceMemoryBandwidth: -1B/s
2020-03-10 19:45:39.235125: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocblas.so
2020-03-10 19:45:39.236629: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libMIOpen.so
2020-03-10 19:45:39.237930: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocfft.so
2020-03-10 19:45:39.238294: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocrand.so
2020-03-10 19:45:39.238463: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1697] Adding visible gpu devices: 0
2020-03-10 19:45:39.238596: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1096] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-03-10 19:45:39.238658: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1102]      0
2020-03-10 19:45:39.238695: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] 0:   N
2020-03-10 19:45:39.238890: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1241] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7524 MB memory) -> physical GPU (device: 0, name: Device 731f, pci bus id: 0000:2b:00.0)
TensorFlow:  2.1
Model:       resnet50
Dataset:     imagenet (synthetic)
Mode:        training
SingleSess:  False
Batch size:  64 global
64 per device
Num batches: 100
Num epochs:  0.00
Devices:     ['/gpu:0']
NUMA bind:   False
Data format: NCHW
Optimizer:   sgd
Variables:   parameter_server
Generating training model
WARNING:tensorflow:From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/convnet_builder.py:134: conv2d (from tensorflow.python.layers.convolutional) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.keras.layers.Conv2D instead.
W0310 19:45:39.282001<PHONE_NUMBER>93152 deprecation.py:323] From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/convnet_builder.py:134: conv2d (from tensorflow.python.layers.convolutional) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.keras.layers.Conv2D instead.
WARNING:tensorflow:From /home/gpu-user/.local/lib/python3.6/site-packages/tensorflow_core/python/layers/convolutional.py:424: Layer.apply (from tensorflow.python.keras.engine.base_layer) is deprecated and will be removed in a future version.
Instructions for updating:
Please use layer.__call__ method instead.
W0310 19:45:39.284210<PHONE_NUMBER>93152 deprecation.py:323] From /home/gpu-user/.local/lib/python3.6/site-packages/tensorflow_core/python/layers/convolutional.py:424: Layer.apply (from tensorflow.python.keras.engine.base_layer) is deprecated and will be removed in a future version.
Instructions for updating:
Please use layer.__call__ method instead.
WARNING:tensorflow:From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/convnet_builder.py:266: max_pooling2d (from tensorflow.python.layers.pooling) is deprecated and will be removed in a future version.
Instructions for updating:
Use keras.layers.MaxPooling2D instead.
W0310 19:45:39.321026<PHONE_NUMBER>93152 deprecation.py:323] From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/convnet_builder.py:266: max_pooling2d (from tensorflow.python.layers.pooling) is deprecated and will be removed in a future version.
Instructions for updating:
Use keras.layers.MaxPooling2D instead.
Initializing graph
WARNING:tensorflow:From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/benchmark_cnn.py:2267: Supervisor.init (from tensorflow.python.training.supervisor) is deprecated and will be removed in a future version.
Instructions for updating:
Please switch to tf.train.MonitoredTrainingSession
W0310 19:45:41.986801<PHONE_NUMBER>93152 deprecation.py:323] From /home/gpu-user/benchmarks/scripts/tf_cnn_benchmarks/benchmark_cnn.py:2267: Supervisor.init (from tensorflow.python.training.supervisor) is deprecated and will be removed in a future version.
Instructions for updating:
Please switch to tf.train.MonitoredTrainingSession
2020-03-10 19:45:42.372816: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1573] Found device 0 with properties:
pciBusID: 0000:2b:00.0 name: Device 731f     ROCm AMD GPU ISA: gfx1010
coreClock: 0.1GHz coreCount: 40 deviceMemorySize: 7.98GiB deviceMemoryBandwidth: -1B/s
2020-03-10 19:45:42.373062: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocblas.so
2020-03-10 19:45:42.373111: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libMIOpen.so
2020-03-10 19:45:42.373155: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocfft.so
2020-03-10 19:45:42.373201: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocrand.so
2020-03-10 19:45:42.373313: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1697] Adding visible gpu devices: 0
2020-03-10 19:45:42.373361: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1096] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-03-10 19:45:42.373398: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1102]      0
2020-03-10 19:45:42.373431: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] 0:   N
2020-03-10 19:45:42.373560: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1241] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7524 MB memory) -> physical GPU (device: 0, name: Device 731f, pci bus id: 0000:2b:00.0)
terminate called after throwing an instance of 'std::runtime_error'
what():  No device code available for function: ZN10tensorflow7functor28FillPhiloxRandomKernelLaunchINS_6random27TruncatedNormalDistributionINS2_19SingleSampleAdapterINS2_12PhiloxRandomEEEfEEEEvS5_PNT_17ResultElementTypeExS8, for agent: gfx1010
Fatal Python error: Aborted

Any update on the status of this issue?

I'm not a ROCm user, but I tried installing it just to get OpenCL working because as I found somewhere that's how ROCm works on AMD devices: through OpenCL so it supposed to set OpenCL up, but failed in my case. Eventually, I got OpenCL working on Ubuntu 18.04, but I think it should work on any distro (the question is just kernel version): https://askubuntu.com/questions/1209725/how-to-get-opencl-support-for-navi10-gpus-from-amd <-- that's how I managed to achieve it.
So I think if you guys set OpenCL up on your setup, ROCm should also work properly with RX5700 (navi10-12)
I hope it helps ^^

@SlavMFM
As mentioned, I was able to install ROCm 3.1 and thus OpenCL.
clinfo results look fine.
So there is Navi support, but it is not really functional.
Look at the error above:
" No device code available for function: "
This seems to point to some not fully implemented libraries or missing assembler snippets.
It bit like a car without engine.

Interesting. Was you able to run some raw OpenCL examples to verify it's working properly? I once had "fake" OpenCL setup where clinfo was printing even GPU name (Radeon RX5700xt), but actual opencl functions from within C++ wasn't working. I just can't imagine how ROCm could utilize AMD GPUs rather just through OpenCL, so it it's working, ROCm should work too, hmm...

@SlavMFM As far as I know, AMD provides two seperate OpenCL 2.0 implementations. One in ROCm and another in AMDGPU PRO driver. I have tested the OpenCL 2.0 in AMDGPU PRO and can confirm it works fine (see my post above). Although, getting OpenCL to work does not guarantee that ROCm would work too.

@jemzipx cool! I'm surprised amdgpu-pro drivers can be actually installed ^^ - you just get kernel 5.6 and install amdgpu-pro on top of it?
Btw, there is at least another offician support: mesa drivers where AMD devs directly implement their GPUs support, for example navi14 was implemented half-a-year before GPUs release: https://lists.freedesktop.org/archives/mesa-dev/2019-August/222273.html - that's how I got OpenCL working in my case: with mesa-19.3 driver (which can stack on > kernel 5.4, but not 5.6).

@SlavMFM that is right. I installed amdgpu-pro on top of kernel 5.6rc in Manjaro (should work in Arch too). I tried mesa before (actually that was the first thing I tried) but the OpenCL version was 1.2 which is quite old and kind of outdated. As far as I can tell, OpenCL 2.0 support for Navi can only be found in AMDGPU-PRO and ROCm.

@jemzipx you think it'll work only on Manjaro and Arch and won't work on other distros like Ubuntu? Would like to try it on Ubuntu later.
I'm currently having mesa-19.3 and it claims 2.1 platform and 2.0 device; not sure if it's practically 2.0 though.

@SlavMFM It should work on all distros. I have only tested Manjaro personally. I'm also curious to know how it plays on Ubuntu. BTW, have you tested Keras/PlaidML with your Mesa OpenCL on Ubuntu? Please give it a go and let us know the result.

[Update]
I was able to compile and install pytorch using the latest ROCm 3.1.1 using this guide.
But I don't know how to install custom modules like DCNv2 that are C++ extensions of pytorch.
There was some prompt I kept getting everytime I used pytorch, I can't remember, neither can I test it since I'm afk.
All in all, things are looking better for Navi gpus, still no idea on when the official support will come through.

AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.
Regards,
Roopa

I don't think anyone here is asking for validation or even official support. All that Navi owners and potential buyers would like is for it to somehow work, now several months after it's release, just like it would work for them from day zero if they have got, say, a RTX 2070 using CUDA.
People understand that the resources are limited, that it's open software, that it's a new architecture, that it's not focused on computing... but after so much time without support or even confirmation that it will ever come, it looks like individuals with interest in these kind of projects that don't require validation and also game on the side unfortunately have only one choice and it's not AMD. Which is understandable from a business perspective, only too bad for those customers to have less options on the market.

let's just call it AMD on the compute market is a joke at the moment and the only option for the consumer is to go nvidia.

@Rmalavally That is a very disappointing answer from an AMD's representative. The thing is that, Nvidia's success was due to the fact that every college gamer kid with their consumer-based GTX/RTX card could run deep learning algorithms as well. There are many of us that do not want to rely on Nvidia's propriety CUDA and would prefer to use open standards like OpenCL etc. This is a great business opportunity for AMD and is the one that matters more than designing graphic cards for next-gen xbox and playstation. We hope you reconsider your approach to consumer cards.

@Rmalavally That is a very disappointing answer from an AMD's representative. The thing is that, Nvidia's success was due to the fact that every college gamer kid with their consumer-based GTX/RTX card could run deep learning algorithms as well. There are many of us that do not want to rely on Nvidia's propriety CUDA and would prefer to use open standards like OpenCL etc. This is a great business opportunity for AMD and is the one that matters more than designing graphic cards for next-gen xbox and playstation. We hope AMD change its approach to consumer-grade cards.

This is not the first time we get disappointing answers from AMD, We ALL hope AMD change its approach to consumer-grade cards, and its approach to Radeon Instinct MI50 selling strategy for consumers too, not only for businesses.

Well let's face it:
Jen-Hsun Huang said: "Nvidia is a Software Company,"
If you look at their stock chart, that may have been a wise decision.
If AMD decides to put all their effort on fancy 7nm tech, but does not want to spend the money for software developers, we just have to swallow that pill and move on.

Well let's face it:
Jen-Hsun Huang said: "Nvidia is a Software Company,"
If you look at their stock chart, that may have been a wise decision.
If AMD decides to put all their effort on fancy 7nm tech, but does not want to spend the money for software developers, we just have to swallow that pill and move on.

it would be a bitter pill to swallow however...

They released ROCm 3.3.0 today but (as we all expected) there is no official support for Navi yet :( All it takes for them is to hire someone to work on this full-time for a few weeks but apparently AMD has more pressing issues at the moment. Thank you AMD for ignoring your loyal supporters.

PLEASE do complete navi10 support! I bought this card just because of opensource support (bought in release day). Not having it feels like I paid for the full price of the card, but I can only use half of it.

Yes, I agree. Please support navi10. It's absurd and disappointing that the latest and current flagship hardware still doesn't support rocm 6+ months after release and doesn't even have a timeline for it. At this rate might just have to begrudgingly go with Nvidia next generation.

Hello, I think the only reasonable way we could expect widespread adoption of ROCm if it is supported by all cards just like Nvidia's CUDA. The era of GPGPU compute is shifting more and more applications and developers are realizing when not gaming these cards can significantly improve the performance of many applications. ROCm can only be relied upon by developers if it is supported by all cards otherwise they would be better of writing OpenCL or something that generates to SPIR-V and than compiling to vulkan or similar.
By not supporting all cards you are effectively wasting the entire developing effort of ROCm and all the time of the employees and contributors who worked on it. Please, I encourage AMD to heavily reconsider their stance.

@jemzipx
Hey, I'm trying to make  my rx5700xt work  the same as you did(but on Ubuntu 18.04). I installed 5.7rc2 kernel,  I have a question  how did you install AMDGPU PRO? I find a lot of problems with dependencies when i tried to do it(which may or may not be connected to Ubuntu).

@Anton-Kyrychek I installed AMDGPU PRO through AUR (which is more specific to Arch Linux and it's derivatives like Manjaro). The installation was quite easy and the dependencies were resolved by Makepkg and Pacman automatically (nothing special was done on my side). I tried it only on 5.6 though. Not sure how it plays on 5.7rc.

AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.
Regards,
Roopa

You may want to update the docs:
https://github.com/RadeonOpenCompute/ROCm

"Vega 10" chips, such as on the AMD Radeon RX Vega 64 and Radeon Instinct MI25

Or maybe update your knowledge.

AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.
Regards,
Roopa

You may want to update the docs:
https://github.com/RadeonOpenCompute/ROCm

"Vega 10" chips, such as on the AMD Radeon RX Vega 64 and Radeon Instinct MI25

It does not suggest Navi support, but Vega is fine.

@Anton-Kyrychek could you let us know if you are successful in using the RX 5700 XT card on ubuntu, and if so what steps you followed? Looking to use it with pytorch on ubuntu 19.

@Ge0rges I was not, I'm not that smart with drivers.

@Ge0rges
try this method, this is what I have used with little success
https://github.com/ROCmSoftwarePlatform/pytorch/issues/581

@mritunjaymusale that worked for you on the 5700XT?

@Ge0rges  yes it worked for me.

I've been following ROCm for a long time, I don't know a lot about the team behind, but it seems like AMD doesn't really care about us yet, GPU computing will be a huge part of the software stack, I see no reason to buy AMD GPUs at the moment, maybe they'll support Big Navi, unfortunately, AMD is years behind the competition in this area, imagine how many developers and consumers would benefit from AMD's adoption of GPU computing, anyway I'll continue to follow this thread and see if AMD change its ways in the near future.

I really do not think this is the right strategy to market rocm by only focusing on Radeon Instinct.
The most common choices in my lab (and nearby labs) are GTX 1080Ti and 2080 RTX. Our AI lab has a cluster with Titan V GPUs but nobody of my University, as far as I know, every purchased the Tesla product line from NVIDIA.
It's not difficult to realize the fact that deep learning researchers/developers always start with customer grade cards, and they may never consider the professional grade cards due to high costs.
A professional-market-only approach will not bring any professional developers/researchers, ironically.

@mritunjaymusale I've been able to compile pytorch with ROCm as per your link. However tests fail because HIP gives an hipErrorNoDevice error. Were you able to solve that?

@Ge0rges I got the rocBlas error that's hinting to the device driver i believe this has to do with rocm not fully supporting the navi cards.
I think we might have to compile rocm from scratch itself and see if it even accepts navi cards

Ah so it never worked for you I guess?

I wonder if anyone has gotten Pytorch to work with RX 5700XT through OpenCL similarly to @jemzipx

@Ge0rges AFAIK, PyTorch does no support OpenCL. In fact, PyTorch developers have been quite hostile towards OpenCL so far:
pytorch/issues/488

I am certainly struggling to really understand where this stands. I am looking to build an AMD machine for ROCm development purposes and am considering the RX 5700XT vs a Radeon VII. Really sounds like the VII is the way to go as there still is not Navi support. Do I have that right?

@ThemysciraData I don't think there ever will be, Big Navi is getting all the love and care because they have datacentre gpus coming soon, whereas Regular Navi has been whatever we can scrabble together with little to no help from AMD's side.
If you're gaming on linux then sure go for 5700xt, if you have anything else to do besides gaming  then check their supported gpu stack and use that instead or straight away buy nvidia gpu if you're doing Deep Learning.

@mritunjaymusale Got the NVidia already. Wanting to do the AMD more for exploration, and understanding what is possible if that makes sense. Shoot, in a perfect world, I would do the ROCm in macOS, but truth is that's too much trouble to be worthwhile. But, thanks for more or less confirming that the VII is what I should go with for the AMD machine. ;)

now supported card here:
https://github.com/RadeonOpenCompute/ROCm#supported-gpus
for low GPU RX580 ... for highend card Radeon VII  (or Instinct card...)
(RX 5700XT  when supported will be slower than Radeon VII )
Note: new GCC10 (https://gcc.gnu.org/gcc-10/changes.html) support offoading with old Fiji or the never VEGA 10/VEGA 20 (no support for polaris now...)

@Djip007 I appreciate the link, but what makes you think I had not already looked at it?

@Djip007 I appreciate the link, but what makes you think I had not already looked at it?

Because I was sleeping when I read your last post... read a question... with isn't ;)
Sorry

I never expected it to get this bad. It's just sad. Can't wait for Ampere at this point.

@EwoutH Exactly. AMD is making a huge mistake and they don't even know it. They have already lost a lot of customers because of this. What kind of company treats the customers of their flagship desktop GPU product like this? What is even more sad is that I have to use PlaidML (which is written by AMD's arch rival: Intel) to do some basic deep learning on 5700XT. There is absolutely NO solution by AMD to do deep learning on 5700XT and this is just devastating.

Just saw the articles about how the new Radeon VII Pro gpu is based on vega, which may mean the next pro architecture will be based on navi. If AMD really only plans on supporting pro gpus we might actually never get support for our flagship cards.
Granted this is based on too much assumptions but I really don't like that we have to guess. I just wish AMD would talk to us about these things, the amount of unanswered questions about this card is phenomenal

It's pretty sad that this has been ignored. The 5700xt is such a great bit of hardware let down by such poor software. At this point it seems that if that if you ever want to use your gpu for more than gaming then nvidia is the only real option.

Same here. Great card for flight sims. Was planning to use it for compute also. Guess I will ebay it.

I have a 5500XT which is also Navi. I am new to this, would this be an alternative : https://math.dartmouth.edu/~sarunas/amdgpu.html

@sh1va73 It should work yes, I know people on ubuntu/arch use a somewhat similar solution (using amdgpu-pro for opencl and amdgpu for the rest) although I'm not sure if it's against AMD's TOS or not

@sh1va73 yes that would work, I have done it on an Ubuntu based distro and I have a similar situation now on an Arch based distro where only the necessary components (opencl-amdgpu-pro-pal from AUR and it's dependencies) of the amdgpu-pro proprietary package are installed.
Unfortunately AMD doesn't provide the display driver and the opencl driver in separate packages, which prevents Linux distros from packaging and redistributing only the opencl part (AUR provides just a script that builds the packages on the user's computer, so no infringement).
And sadly AMD hasn't open sourced (yet?) it's opencl driver. If they were to do that and contribute it to the mesa library, anyone would be able to easily install it on any Linux distro and lots of ROCm complaints from people who only want a working open source opencl driver would have been avoided.

Today we got a lot of news in HPC segment, will AMD have any event related to HPC and ML soon?

Today we got a lot of news in HPC segment, will AMD have any event related to HPC and ML soon?

Maybe when they launch RDNA 2 cards which should be within 1 to 2 months.

Today we got a lot of news in HPC segment, will AMD have any event related to HPC and ML soon?

AMD have a virtual event relating to GPUOpen's relaunch tomorrow, so maybe there we'll get more info on what's coming up. They do have a new library for machine learning inference for instance.

@Rmalavally
AMD Spent millions developing and advertising navi, and customers are buying it!  Why would you then not support it?!?  I'm sorry, but that is a poor answer at best and really feels like a stab in the back!

@BloodBlight They could also support Windows, there is no date release for a version that works on Windows, today we got news about the competition bringing their accelarator to Windows through WSL, I think Rocm could to something similar, they just need to work with Microsoft on this one too.

As soon as I test this I'll be posting updates.
https://twitter.com/AMDRyzen/status/1265681670918688768

I think you read that wrong, it explicitly states vega graphics which are GCN micro-architecture and already supported by ROCm. The 5700xt is of the newer RDNA micro-architecture.

@Dantali0n In the demo the guy was using a Vega 9 Graphics, I don't think neither Vega 9 or 11 runs on Rocm, with regarding the RX 5700 XT if I not mistaken the idea is to run on top of DirectX 12, they stated multiple GPU vendors support, again they're still a lot of unknown details. But this seems promising to the ML community.

@limapedro if that means that AMD will release drivers to Open Source it would be great, but i feel it's going to be the case where i have AMD r3 2200G (a CPU for 50$) which will be able to do ML coz it has integrated Vega, and RX 5700 XT will not be able to do it coz it's navi

@Anton-Kyrychek In their announcement video Microsoft stated that there will be "Hardware accelerated training supported on any DirectX 12 GPU".

@Crash129 Exactly, I  almost certain that it'll support ONNX, so models could be deployed in a wide range of platforms, I think AMD is working with Microsofton this there were some discussions, DirectX seems robust enough to ad ML ops on it, the cool thing about this is almost every device will be able to be hardware accelerated for ML. Hopefully AMD will now be a viable option for ML on Windows as well.
https://groups.google.com/a/tensorflow.org/forum/#!topic/developers/UzOZ5BAnOa4

I couldn't believe what I read. I bought a Radeon 5600 xt without knowing them. Doesn't AMD offer anything other than gaming right now? I hope that the update will come for Navi 10 as soon as possible.

Frankly, I was within 30 days and just returned my 5700 XT... It didn't do the one thing I really bought it for, so... So just to be clear, @Rmalavally, you have lost a long term customer (one who also builds data centers and used AMD for over a decade at home), and you will be hard pressed to win be back... I was truly excited about the prospect of moving away from Big Green at work! But frankly, I am underwhelmed by your new Vega offering, and your point of entry into the market (what Navi should have been) sucks!

AMD released 3.5.0 today with no Navi support. This is getting ridiculous but above all it looks intentional. It is almost one year since first Navi release. Roughly 70% of Navi support is already in the code base so they need to just work out the remaining 30%. The question is why are they unwilling to complete Navi support? Could it be because they are ashamed of the poor compute performance of their current 5700XT flagship desktop GPU against nvidia's GPUs?  Whatever the reason is, it sounds more like a marketing/management decision and not due to lack of resources or developers. By the look of it, they are holding back supporting RDNA on ROCm until at least Big Navi release.

@jemzipx Well, the good news in that Directml seems to be a better option over Rocm, AMD is years late with their GPU support for Deep Learning, Big Navi will probably be out by november depending on how good it performs and the fact that by then tensorflow-directml should be out, I will consider buying AMD cards, either way let's watch things to play out in the next months I guess.

@limapedro sadly directml is not an option for Linux users. The only reason I went AMD this time was the opensource drivers.
This morning I realized that another player is coming with (hopefully) opensource drivers - Intel. And those guys seem to have a better track record on releasing Linux support in a timely matter. Sad for my navi card, but looking forward to see what the competition will bring to this space.

@marcelocf Yeah this solution wouldn't work on linux. Hopefuly this will open AMD's eyes.

@limapedro DirectML looks exciting but I don't see myself switching to windows anytime soon.
@marcelocf Intel has been doing some really cool stuff in deep learning recently. Their oneDNN is already in great shape (works like a charm on AMD cpus as well) and they have been developing PlaidML for some years now. PlaidML is the only OpenCL deep learning framework that is actively developed and also works great with Navi cards. The irony is that Intel's libraries provide best deep learning solution for AMD hardware! I am not an Intel fan but you got to give them props for supporting open source.

AMD ROCm is validated for GPU compute hardware such as AMD Radeon Instinct GPUs. Other AMD cards may work, however, they are not officially supported at this time. We appreciate your feedback and we will consider it for future versions of ROCm.

@Rmalavally This makes it really hard, if not impossible, for me to justify 5700 XT purchase now.

The only reason I went AMD this time was the opensource drivers.

@marcelocf That was the main selling point for me too. I thought ROCm would include Navi and that's why OpenCL was not added to open-source AMDGPU Linux driver. Tough luck.

@Djip007 The PyTorch team claims that OpenCL performance is far inferior to CUDA (a claim I highly doubt). They also believe that OpenCL is abandoned by most hardware manufactures. With AMD focusing on HIP, Nvidia on CUDA, only Intel is fully dedicated to supporting OpenCL. With the underwhelming release of OpenCL 3.0 it seems like even Khronos Group is not taking its own standard seriously.

Machine Learning is not the only application for OpenCL, though. I want to use it primarily in blender with cycles.

@marcelocf That a very interesting take, there's a bunch of programs that use OpenCL, so much so that I don't OpenCL would lose support anytime soon, in this case maybe if Khronos added some ML ops onto OpenCL, it could become a ML runtime standard, even more so than Rocm, Directml and Cuda.

OpenCL is not dead...
rocm2.0 have update to OpenCL2.0...
new rocm3.5 have juste been update to OpenCL2.2
so not update for RDNA... but big update for OpenCL (C++ support...)

@Djip007 Which GPU is needed to use OpenCL 2.2?

with rocm official liste:
https://github.com/RadeonOpenCompute/ROCm#supported-gpus

Why everyone, just an update on tensorflow-directml, yesterday a pypi went public, although it still doesn't work, I will an eye on it, anyone interested as well? I would like to test this one AMD GPUs and see how good it performs.
https://pypi.org/project/tensorflow-directml/0.0.1.dev0/

Hello,
My friend has an RX 5700 XT. Just wanted to share that I tested his PC with DirectML and it worked! The only problem is that it doesn't support TensorFlow 2 yet, so you're stuck on 1.15 (or whatever the last version of TensorFlow 1 is).
I know this isn't the solution everyone wanted, as it requires Windows 10 even though it does work on Linux, just WSL2 specifically. I didn't test it in WSL2 though, I just ran it natively in Windows, following Microsoft's official instructions.
Hopefully it works on other Navi cards, take care.

I am anxiously awaiting support for the 5700xt. I've been unable to use Davinci Resolve since upgrading to an Ubuntu 20.04 base since the propriety OpenCL drivers don't support 20.04.
I've been relegated to using alternative video editing software in the meantime which has proven to be less functional, buggier, and slower and it's beginning cost me. I've been avoiding purchasing an Nvidia GPU and have gone out of my way to support AMD for their support of open source drivers. But I know for a fact that I can return my workflow too normal by doing switching too Nvidia.

upgrading to an Ubuntu 20.04 base since the propriety OpenCL drivers don't support 20.04.

I know nothing about Davinci Resolve but the AMD drivers are made for 20.04, it's even in the file name. https://drivers.amd.com/drivers/linux/amdgpu-pro-20.20-1089974-ubuntu-20.04.tar.xz

@PeterNjeim Nice, I still wasn't able to run tensorflow-benchmark on directml, but since every directX 12 device will be capable of running tensorflow-directml, the number of devices that can is huge. I still don't know about multi-gpu training, I think that multi_gpu from keras in TF 1.15 should work.

@PeterNjeim Nice, I still wasn't able to run tensorflow-benchmark on directml

That is because TensorFlow doesn't recognize DirectML devices as GPU's, but rather "DML"s. Basically, you have to manually edit the Python and replace most instances of "GPU" to "DML". You can't do this automatically, because some functions directly have the word "gpu" in them, and so you can't replace them, and some functions have the word "cuda" in them, and so you'll have to comment those out as they can't possibly run.
It's a very hacky solution by Microsoft, and make sure to comment out all of the GPU checks (some benchmarks check to see if a GPU is connected, you'll have to skip that check as you know yourself that your GPU is connected, but it's just via DML. Also, remember that you can't run anything that requires TF2.
Hopefully you'll be able to run whatever you need using these steps.

I recommend using DirectML's own samples as they're known to work: https://github.com/microsoft/DirectML/tree/master/TensorFlow
However I tried running the squeezenet one and the tracing part failed, and judging by the errors I recieved, I'm pretty sure it's due to the fact I wasn't using WSL, as it was trying to execute Linux command line arguments. So if you want to try those, you may want to be using WSL2 instead of native Windows 10.

@PeterNjeim Thanks, I'll try these changes.

@sofiageo Thanks. They weren't yet released when I checked about a week ago.
Ironically, the amd-pro drivers, while successfully installing, were incompatible with Davinci Resolve. I attempted to use the ROCm drivers instead despite them not officially being supported by the 5700xt, ended up working for me.

Any updates for 5700 XT Support?

Not gonna happen. Not officially anyway.
AMD is diverging gaming and compute workloads to two different product lines. Arcturus is the next compute card
It would be nice to have a specific compute card given gaming and compute workloads are diverging.. but the lack of a second hand market after considering product cadence and TCO, specifically $/watt makes me question the business decision. e.g. Last gen, mining only, GPU cards are worthless. Not only does it cripple resale value, its a big ewaste problem.
nVIDIA is doing similar but keeping CUDA available on the Geforce lineup. This is fantastic for students, individual researchers and anyone else without a budget to spend $$$$ on enterprise hardware. The Geforce line continues to retain value which also allows those same researchers an upgrade path towards those enterprise cards once their research bears fruit (and revenue).
This is also possible due to nVIDIA's software. AMD software needs some finessing so that maybe another reason to separate gaming and compute.

Just to chime in with my own anecdote: I'm a physicist with an nvidia card that I bought for gaming. It's incredibly useful to be able to prototype CUDA workflows on my personal card and just learn the ins and outs of GPU programming with it before running something more serious on a cluster. I would never be able to justify buying myself a CDNA card just for compute, but I could justify buying myself an RDNA card for gaming and occasional compute. Crippling it's compute performance is fine, so long as it actually runs. Just not supporting ROCm it means I probably can't switch to AMD's RDNA cards even though I would really like to.

As the maintainer of the Julia language's AMDGPU compute stack, I'm saddened to see how AMD is dragging their feet on support for this card, as well as hearing whispers of the possibility for loss of support for "consumer" cards in ROCm going forward. I personally only have access to consumer Polaris and Vega AMD GPUs, and if those cards did not work in ROCm, I don't think I would have ever started working on the above-linked stack, and would have sold my GPUs for NVidia GPUs instead.
It's important that AMD realizes how open source really works: random people from all over the world come together to build something that helps everyone. When the tools that such open source software utilizes are cheap and accessible to "regular" consumers, and the software is supported on and designed for these devices, then users have an incentive to buy those devices, install the software, report issues, and eventually send improvements upstream. Without those users, you end up with a software stack that only works on big clusters (and just barely, at that), is performant only on the problems that grants or budgets have paid for, and lack of uptake in both the enterprise and in smaller businesses and communities.
I hope that AMD will reconsider its strategy and put human resources onto getting the Navi line supported ASAP, and more importantly, ensure that all future consumer cards are properly supported by ROCm.

There are signs that AMD has shifted to more of a source release model than open source development. That is surely disappointing, but not inextricably tied to the lack of Navi support. The observation that widespread availability of ROCm support (i.e. consumer hardware) has value is important even if AMD does not want to use an OSS development model.

Wow, this guy did what we could not... and wrote a blog post about it

Just to chime in, 2020 iMacs now also have 5700XT and given they are probably going to be the last intel gen, these are likely to stay for a long time. Expect an inflow of mac users to this thread soon :)

I found https://github.com/smartbitcoin/MyROCm uploaded a custom binary supporting 5700xt base on rocm-3.3.0.
related issues : https://github.com/RadeonOpenCompute/ROCm/issues/938 https://github.com/RadeonOpenCompute/ROCm/issues/938

I decided to take a look. I'm running on Fedora 32.
I was able to download ROCm source using repo. There are no build instructions except the READMEs in each separate module and they are often wrong. I had to refer to the CMakeLists.txt directly to figure out how to build ROCm. The CMake setup is a bit weird and inconsistent and I had to manually copy some files. Not a good start. In the end I successfully built and installed: ROCT-Thunk-Interface, ROCR-Runtime and rocminfo.
With the stock Linux 5.7 driver rocminfo can detect my 5700XT GPU:
*******
Agent 2
*******
  Name:                    gfx1010
  Uuid:                    GPU-XX
  Marketing Name:          Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
  Vendor Name:             AMD
...

We can conclude that the kernel driver, thunk interface and base runtime supports 5700XT. Next I will try to build HIP-clang and HIP. Navi is supported by LLVM (https://www.phoronix.com/scan.php?page=news_item&px=GFX1011-GFX1012-AMDGPU-LLVM) so hopefully very little work is needed to get HIP working with 5700XT.

I was able to build HIP-clang and ROCm-Device-Libs, but I'm not able to build the rest of the HIP stuff. AMDs provided build instructions are incorrect and some of the code on both rocm-3.5.x and rocm-3.6.x branches doesn't even compile due to ODR violation. Build is not following standard CMake practices. Building ROCm is extremly complicated.

Ok after following the ridiculously complicated build (https://gist.github.com/rigtorp/d9483af100fb77cee57e4c9fa3c74245) and making some modifications to the HIP runtime headers I can almost build a HIP sample:
/opt/rocm/bin/hipcc  square.cpp -o square.out
LoadLib(libhsa-ext-image64.so.1) failed: libhsa-ext-image64.so.1: cannot open shared object file: No such file or directory
hipcc-cmd: /opt/rocm/llvm/bin/clang++  -std=c++11 -isystem /opt/rocm/llvm/lib/clang/12.0.0/include/.. -isystem /opt/rocm/hsa/include -isystem /opt/rocm/include -D__HIP_ARCH_GFX1010__=1  --cuda-gpu-arch=gfx1010 -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false  --hip-device-lib-path=/opt/rocm/amdgcn/bitcode  -L/opt/rocm/lib -O3 -lgcc_s -lgcc -lpthread -lm  -x hip square.cpp -o square.out -Wl,--enable-new-dtags -Wl,--rpath=/opt/rocm/lib:/opt/rocm/lib -lhip_hcc  -L/opt/rocm/llvm/bin/../lib/clang/12.0.0/lib/linux -lclang_rt.builtins-x86_64
/usr/bin/ld: cannot find -lclang_rt.builtins-x86_64
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:21: square.out] Error 1

Note that it detects my 5700xt gpu and compiles against the Navi architecture: --cuda-gpu-arch=gfx1010

Just a quick question - can we use this ticket as a way to show AMD we want official support for navi10 cards?
Troubleshooting and howtos remove visibility from comments like jpsamaroo's comment from 2 days ago. Specially because those howtos are all focused on ML, while there are other applications that benefit from official opencl support.
Note that an alternative option could be having another ticket where this is clearly specified.
Thanks

Just a quick question - can we use this ticket as a way to show AMD we want official support for navi10 cards?

I don't think AMD cares. They don't seem to monitor GH issues.

After some more tinkering the latest amd-stg-open branch can build a simple HIP kernel for Navi (GFX1010) (updated the build instructions):
LD_LIBRARY_PATH=/opt/rocm/lib64 make
/opt/rocm/bin/hipify-perl square.cu > square.cpp
/opt/rocm/bin/hipcc  square.cpp -o square.out
LoadLib(libhsa-ext-image64.so.1) failed: libhsa-ext-image64.so.1: cannot open shared object file: No such file or directory
hipcc-cmd: /opt/rocm/llvm/bin/clang++  -std=c++11 -isystem /opt/rocm/llvm/lib/clang/12.0.0/include/.. -isystem /opt/rocm/hsa/include -isystem /opt/rocm/include -D__HIP_ARCH_GFX1010__=1  --cuda-gpu-arch=gfx1010 -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false  --hip-device-lib-path=/opt/rocm/amdgcn/bitcode  -L/opt/rocm/lib -O3 -lgcc_s -lgcc -lpthread -lm  -x hip square.cpp -o square.out -Wl,--enable-new-dtags -Wl,--rpath=/opt/rocm/lib:/opt/rocm/lib -lhip_hcc  -L/opt/rocm/llvm/bin/../lib/clang/12.0.0/lib/linux -lclang_rt.builtins-x86_64
/opt/rocm/bin/hipcc -use-staticlib  square.cpp -o square.out.static
LoadLib(libhsa-ext-image64.so.1) failed: libhsa-ext-image64.so.1: cannot open shared object file: No such file or directory
hipcc-cmd: /opt/rocm/llvm/bin/clang++  -std=c++11 -isystem /opt/rocm/llvm/lib/clang/12.0.0/include/.. -isystem /opt/rocm/hsa/include -isystem /opt/rocm/include -D__HIP_ARCH_GFX1010__=1  --cuda-gpu-arch=gfx1010 -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false  --hip-device-lib-path=/opt/rocm/amdgcn/bitcode  -L/opt/rocm/lib -O3 -lgcc_s -lgcc -lpthread -lm  -x hip square.cpp -o square.out.static -L/opt/rocm/lib -lamdhip64_static -L/opt/rocm/lib -lhsa-runtime64 -ldl  -L/opt/rocm/llvm/bin/../lib/clang/12.0.0/lib/linux -lclang_rt.builtins-x86_64

It doesn't run though:
HIP_TRACE_API=1 LD_LIBRARY_PATH=/opt/rocm/lib64:/opt/rocm/hsa/lib/ ./square.out
LoadLib(libhsa-ext-image64.so.1) failed: libhsa-ext-image64.so.1: cannot open shared object file: No such file or directory
error: 'hipErrorInvalidDevice'(101) at square.cpp:61

It seems that ihipInit() in HIP/src/hip_hcc.cpp doesn't enumerate the Navi device. If we can make it enumerate and upload the bitcode to the device it should work.
It looks almost all the pieces are there now, it's so close!

Wow, this guy did what we could not... and wrote a blog post about it

I gave this a shot with a fresh install of Ubuntu 20.04. I made the following changes:

Rather than compile the kernel I just updated to the generic 5.8.
I had to change where the key was saved from /etc/apt/trusted.d/rocm.asc to instead be /etc/apt/trusted.gpg.d/rocm.asc
I had to install rccl as well as the rocm packages listed in the post
I used rocm 3.5.0 packages instead of the 3.3.0 as these were the default when installing and worked fine
I did not install vulkan and cannot comment on this part.

I was able to run tensorflow-rocm version 2.2 sucessfully and it did recognize my gpu as being Navi 10.
So it looks like there is a successful method to get tensorflow running. and it was not terribly difficult given the blog post.
I will test some timings eventually and post the results to ensure that the performance is more or less what is expected.

So it looks like there is a successful method to get tensorflow running. and it was not terribly difficult given the blog post.

Did you run an actual kernel on the GPU or only enumerated it using the TF API? Try build and run a HIP kernel. I managed to build the latest development version from source and the HIP API doesn't enumerate my 5700XT, but I can compile it into GFX1010 bitcode.

I only enumerated it with the TF API, and upon more testing, it throws a segmentation fault under nearly every use case except scalar/vector integer operations. Definitely not in a working state yet

No support in version 3.7 either

I can confirm that ROCm 3.7 supports Navi 10:
$ ./square.out
info: running on device Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
info: allocate host mem (  7.63 MB)
info: allocate device mem (  7.63 MB)
info: copy Host2Device
info: launch 'vector_square' kernel
info: copy Device2Host
info: check result
PASSED!

Detailed install guide for Fedora 32: https://rigtorp.se/notes/rocm/
Additional work might be required in upstream PyTorch to get the compute kernels built for Navi.

@rigtorp Can you please confirm this by running a floating point example in tensorflow? We have seen many successful attempts at installation and navi hardware recognition in the OS but when it comes to actually running a sample code in tensor flow it fails.

@jemzipx I ran a floating point sample HIP kernel: https://github.com/ROCm-Developer-Tools/HIP/tree/master/samples/0_Intro/square
More complex kernels like those in tensorflow and PyTorch might not yet build for Navi.

The remaining issues for PyTorch support on Navi are:

https://github.com/ROCmSoftwarePlatform/rocPRIM/issues/180
https://github.com/ROCmSoftwarePlatform/rocRAND/issues/140

Tracking overall progress here: https://github.com/ROCmSoftwarePlatform/pytorch/issues/718
AMD finally confirmed they are working on this (https://github.com/ROCmSoftwarePlatform/pytorch/issues/718#issuecomment-680283792):

Thank you for reporting the issue. There is a fix planned for an upcoming release of rocPRIM

What is the current status?

Is OpenCL working correctly? Can I run most of opencl code without problems, for example Clblast?
Does MiOpen work based on  Hip / OpenCL?both?
From what I understand currently neither TF nor Pytorch are working on Navi? Are there time estimation when is it ready?

Today only APUs and Navi are in production and neither one of them support deep learning today

@artyom-beilis Based on my own testing, OpenCL seems to work correctly as of the latest version of ROCm. Specifically, I compiled and ran some simple Futhark programs to OpenCL, and those ran without issue, giving expected results.

Regarding opencl: i tested darktable and it is working fine

i tried blender, freeze at begin of rendering, but at least better than before (crash at compiling)

Wow.. How fast the support.

Wow.. How fast the support.

At least they managed to get a completely new architecture partially working in 1 year, which is acceptable considering rx 5700 xt was never marketed as a compute card.
Now, hopefully we will get day 0 support for Navi 2 / Big Navi.

I can confirm OpenCL works with blender (2.97b) on my RX 5700 XT (ubuntu 18.08, kernel 5.3, rocm 3.7)

These are good news about OpenCL. But when hip support + pytorch & tensorflow & miopen will be ready?
It is more than a year since the release. How long I need to wait more if I buy today Navi based card?
Should I buy rx 580 now that is 4 generations back - Polaris, Vega, Navi and Now Navi 2,  that I know works 100% and has around 6TFLOPS performance or 5500XT for the same price that only two generations old (Navi 1 vs Navi2) that will probably work (or may not) someday in future and has around 5TFLOPs. Would Navi have better DL performance or not? How long should I wait?
I understand that this is not the forum to discuss it but overall it looks like there is no real option to do deep learning on AMD unless I go 4 generations back since there is still a stock of 580's available for reasonable price.

@artyom-beilis
I have RX480, but even with it, it isn't so stable. I was able to to do some training (mostly examples), but nothing serious. Currently, I can't allocate more then 4GB tnsorflow model on my 8GB RX480. But even in <4GB, training fails after few hours, and there is even official issue acknowledged.
I tried tensorflow yesterday on my 5700xt, but there is some error when trying simple calculation (reduce sum).
RDNA1/navi was never promised to be work for deep learning. What is shame, that on windows, you can use DX12 with tensorflow and it's supposed to work on navi.
Deep learning is not financially profitable - IIRC nvidia does not have positive profit on DL market. Profit from gaming market goes to DL research. With AMD, the market is much smaller and even less money can go to DL research/development (rocm). AMD would like to sell high-margin "MI"-like (MI50) cards that you can't even buy (price not known but probably few $ 1000). Their idea is to buy server from e.x. HP with few of such cards in it. https://www.amd.com/en/graphics/servers-radeon-instinct-mi-powered-servers
I just "happen" to have rx480 and rx5700xt that I can "play" with it, but my work/research is on nvidias where i can reliably train for weeks. It's nice that AMD has ROCm and it shows some potential, but I try to have low expectations. I wouldn't consider buying radeons for serious
BTW, here is one whitepaper on ROCm - https://drops.dagstuhl.de/opus/volltexte/2020/12373/pdf/LIPIcs-ECRTS-2020-10.pdf

@gsedej
It is mostly to have free open source DL stack. I understand that for real training/work NVidia is way better.
Does RDNA1/Navi require PCI-E atomics like Polaris does or it can run via chipet's PCI-E slots similarly to Vega?

Does RDNA1/Navi require PCI-E atomics like Polaris does or it can run via chipet's PCI-E slots similarly to Vega?

The entire ROCm stack requires PCI-E atomics this includes the OpenCL implementation.
"As described above, GFX8 GPUs require PCIe 3.0 with PCIe atomics in order to run ROCm"
https://github.com/RadeonOpenCompute/ROCm#Hardware-and-Software-Support

Yes, nav1 wont require AtomicsOp for PCIe, just like vega.
Only FIJI, POLARIS10, POLARIS11, POLARIS12 need AtomicsOp for PCIe.
Please refer here: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/blob/master/drivers/gpu/drm/amd/amdkfd/kfd_device.c#L422

Can anyone tell if RX 5700 works with Rocm 3.8 or any other Navi card?

Basic installation still gives error:
>> import tensorflow as tf
>> tf.add(1, 2)

Console output:
"2020-09-22 17:45:39.046486: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libamdhip64.so
/src/external/hip-on-vdi/rocclr/hip_code_object.cpp:92: guarantee(false && "hipErrorNoBinaryForGpu: Coudn't find binary for current devices!")
Aborted (core dumped)"

I found a blog where one was able to use tensorflow on 5700 (non-xt)
https://www.preining.info/blog/2020/05/switching-from-nvidia-to-amd-including-tensorflow/
It was on rocm 3.3. Anyone knows if it's possible to downgrade rocm to 3.3?

I found a blog where one was able to use tensorflow on 5700 (non-xt)
https://www.preining.info/blog/2020/05/switching-from-nvidia-to-amd-including-tensorflow/
It was on rocm 3.3. Anyone knows if it's possible to downgrade rocm to 3.3?

Please read the comments on the page. It is mentioned that TensorFlow is not working even though the installation was successful.

I found a blog where one was able to use tensorflow on 5700 (non-xt)
https://www.preining.info/blog/2020/05/switching-from-nvidia-to-amd-including-tensorflow/
It was on rocm 3.3. Anyone knows if it's possible to downgrade rocm to 3.3?

I was able to follow the blog shared earlier, however, you are only able to perform the operation shown in the blog. Any attempt at using ops with floating point values immediately crashes. Also any multiplication or division fails. So you can use it to add and subtract integers.

Can anyone tell if RX 5700 works with Rocm 3.8 or any other Navi card?

Yes you can compile and run HIP kernels on Navi cards from ROCm 3.7 and newer. See my comment https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-678840646
I was able to coax AMD into fixing the issues preventing pytorch to be built: https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-680293254
There is still missing library support in things like rocBLAS etc. I haven't had time to look at it yet.

Any updates on the plan for Navi RDNA, and also any plans for RDNA 2 in coming months? I plan to update my GPU to RDNA 2, but without ROCm support, I will be stuck with my current GPUs.

I'm planning to just switch to NVIDIA. Regardless of their practices and pricing, at least they support CUDA on their consumer cards on both Windows and Linux from the start. Not dealing with this sort of mess again.

@himanshugoel2797 I have to agree with you, I'm using an AMD card now with directml, but the Nvidia GPUs are really appealling with support for fp16, even the RTX 3070 should be way faster than the RTX 2080 Ti for models that can fit in 8 GB of VRAM, you can check out the PugetSystems benchmark, a RTX 3080 being twice as fast as a RTX 2080 Ti is unbelievible for its price. But on ther hand we don't know anything about RDNA 2 yet, we'll possibly break the 20 TFlops mark, AMD should offer more VRAM and I hope that they add some hardware accelarated for MLops a.k.a Tensor cores, because they already we'll be adding Ray-Tracing, which would allow for fp16 training, but for me this is AMD's last chance if RDNA 2 doesn't play out to be good value for Deep Learning, I'll seek other options. Let's just hope that AMD has been playing 4D chess for the last 12 months.

But on the other hand we don't know anything about RDNA 2 yet, we'll possibly break the 20 TFlops mark, AMD should offer more VRAM and I hope that they add some hardware accelarated for MLops a.k.a Tensor cores, because they already we'll be adding Ray-Tracing, which would allow for fp16 training

Unfortunately, I do not see that happening with the (maybe unreliable) current leaks suggesting that the bus width will only be 256b for the 6900xt. A huge part of ML training is limited by the memory bandwidth and so it is unlikely that RDNA2 will be as good as the 3080, which has a 320b bus. Naturally quite a bit more goes into it, but with less cores as well, it seems like we will need the leaks to be completely wrong for any hope of competition in the ML space, not even counting the software optimizations.

Curious that the EOL'd (for over a year now) Radeon VII has comparable memory bandwidth to RTX 3090 at less than half the price.

That is due to the memory difference. The VII uses HBM2 while the 3090 uses GDDRX6. HBM2 is hard to get enough supply for mass markets and drives cost up so it's generally not used for gaming graphics cards. Unfortunately, AMD seems to be positioning itself purely for gaming, as we all are well aware in this thread.

Unfortunately, AMD seems to be positioning itself purely for gaming, as we all are well aware in this thread.

@Ryandry1st No at the last earnings call Lisa Su mentioned HPC and ML is a growth opportunity for AMD:

As it relates to machine learning and AI, we continue to invest in ROCm, we continue to work sort of our strategy around machine learning is partner deeply with a couple of large cloud vendors who can invest in the software with us and we see that as a multi-year opportunity, but it will, it's not a big revenue contributor here in 2020. But we see growth opportunity as we go into 2021 and beyond.
https://seekingalpha.com/article/4361612-advanced-micro-devices-inc-amd-ceo-lisa-su-on-q2-2020-results-earnings-call-transcript?part=single

I think they are just not very good at software and building a developer community. It's possible that Azure and AWS collaboration could change that. Nvidia doesn't allow OEMs to customize software ASICs. It's possible that Azure and/or AWS collaborates with AMD to produce hardware that's competitive with Google's TPUs.

Please don't dilute this issue with off-topics and personal stories or speculations.

I think Rigtorp had pushed AMD to fixed the inline asm bugs for gfx1010, and pytorch can build successfully with rocm-3.7.0 and gfx1010.
Please see the https://github.com/ROCmSoftwarePlatform/pytorch/issues/718.
The next step is rebuild rocBLAS without new tensile client and go on testing. Somebody who had rx 5700xt could try.
The price of gpu card is raising, I dont think it is a good time to buy a new card for testing card which is not supported offcially.  Waiting to next year maybe properly.

@baryluk Stop whining! Meanwhile I have been proactive and engaged with AMD's developers to get pytorch building. It looks like the only remaining thing to get pytorch and tensorflow running on Navi is to enable rocBLAS for Navi. If you can file a detailed bug report it'll probably get fixed. I've already talked to AMD devs about it, but it doesn't seem to be on any PMs priority list.
It's clear that AMD product management has dropped the ball on this since there are no responses in this thread. AMD's CEO sees ML as a growth opportunity and "is partner deeply with a couple of large cloud vendors" so that is at least a good sign.

Every time I use rocm OpenCL, either in blender, or davinci resolve, I get a callback queue crash:
* thread #113, name = 'blender', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff1dc19e5 libc.so.6`raise + 325
    frame #1: 0x00007ffff1daa895 libc.so.6`abort + 295
    frame #2: 0x00007fff603fc87b libamdocl64.so`roc::callbackQueue(hsa_status_t, hsa_queue_s*, void*) + 75
    frame #3: 0x00007fff59b4176f libhsa-runtime64.so.1`rocr::AMD::AqlQueue::DynamicScratchHandler(long, void*) + 159
    frame #4: 0x00007fff59b75fbb libhsa-runtime64.so.1`rocr::core::Runtime::AsyncEventsLoop(void*) + 171
    frame #5: 0x00007fff59b276c7 libhsa-runtime64.so.1`rocr::os::ThreadTrampoline(void*) + 23
    frame #6: 0x00007ffff7a8e432 libpthread.so.0`start_thread + 226
    frame #7: 0x00007ffff1e86913 libc.so.6`__clone + 67

I don't know what's up. One detail is that I'm running fedora, and am not using the bundled amdgpu modules, as it doesn't compile on 5.8. Could that be the issue?

Every time I use rocm OpenCL, either in blender, or davinci resolve, I get a callback queue abort:
* thread #113, name = 'blender', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff1dc19e5 libc.so.6`raise + 325
    frame #1: 0x00007ffff1daa895 libc.so.6`abort + 295
    frame #2: 0x00007fff603fc87b libamdocl64.so`roc::callbackQueue(hsa_status_t, hsa_queue_s*, void*) + 75
    frame #3: 0x00007fff59b4176f libhsa-runtime64.so.1`rocr::AMD::AqlQueue::DynamicScratchHandler(long, void*) + 159
    frame #4: 0x00007fff59b75fbb libhsa-runtime64.so.1`rocr::core::Runtime::AsyncEventsLoop(void*) + 171
    frame #5: 0x00007fff59b276c7 libhsa-runtime64.so.1`rocr::os::ThreadTrampoline(void*) + 23
    frame #6: 0x00007ffff7a8e432 libpthread.so.0`start_thread + 226
    frame #7: 0x00007ffff1e86913 libc.so.6`__clone + 67

I don't know what's up. One detail is that I'm running fedora, and am not using the bundled amdgpu modules, as it doesn't compile on 5.8. Could that be the issue?

What does it have to do with this issue?
Open a separate issue and delete your comment please.

Every time I use rocm OpenCL, either in blender, or davinci resolve, I get a callback queue abort:
* thread #113, name = 'blender', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff1dc19e5 libc.so.6`raise + 325
    frame #1: 0x00007ffff1daa895 libc.so.6`abort + 295
    frame #2: 0x00007fff603fc87b libamdocl64.so`roc::callbackQueue(hsa_status_t, hsa_queue_s*, void*) + 75
    frame #3: 0x00007fff59b4176f libhsa-runtime64.so.1`rocr::AMD::AqlQueue::DynamicScratchHandler(long, void*) + 159
    frame #4: 0x00007fff59b75fbb libhsa-runtime64.so.1`rocr::core::Runtime::AsyncEventsLoop(void*) + 171
    frame #5: 0x00007fff59b276c7 libhsa-runtime64.so.1`rocr::os::ThreadTrampoline(void*) + 23
    frame #6: 0x00007ffff7a8e432 libpthread.so.0`start_thread + 226
    frame #7: 0x00007ffff1e86913 libc.so.6`__clone + 67

I don't know what's up. One detail is that I'm running fedora, and am not using the bundled amdgpu modules, as it doesn't compile on 5.8. Could that be the issue?

What does it have to do with this issue?
Open a separate issue and delete your comment please.

This is regarding navi support? I failed to specify, but I'm running a 5700xt

This is regarding navi support? I failed to specify, but I'm running a 5700xt

@h33p You will probably get better luck reaching developers by opening separate issue, since this thread has too many replies. Create new issue with good title e.g. "Blender OpenCL fails on 5700xt with SIGABRT". Try to include as much info in the issue (hardware, OS, versions, ...)

@baryluk Stop whining! Meanwhile I have been proactive and engaged with AMD's developers to get pytorch building. It looks like the only remaining thing to get pytorch and tensorflow running on Navi is to enable rocBLAS for Navi. If you can file a detailed bug report it'll probably get fixed. I've already talked to AMD devs about it, but it doesn't seem to be on any PMs priority list.
It's clear that AMD product management has dropped the ball on this since there are no responses in this thread. AMD's CEO sees ML as a growth opportunity and "is partner deeply with a couple of large cloud vendors" so that is at least a good sign.

Thank you very much for taking your time to engage with the devs and drive this topic :heart:
In the meantime there is a new feature branch gfx10 on  rocBLAS see https://github.com/ROCmSoftwarePlatform/rocBLAS/tree/gfx10
Let's keep our fingers crossed that the changes are not too complicated and the branch can be merged soon :crossed_fingers:

Im seeing a lot of gfx10 or gfx1030 branches created in the past few days on almost all projects. Question is how big the difference from gfx1010 and 1030 is. Does anyone know if gfx1030 includes CDNA or if its RDNA 2?

@niculw
I hope there is not big difference between gfx101x and gfx103x. But if AMD dont add gfx1010 to CMakeLists.txt, we will need re-compile by ourselves.
You can refer llvm page for GPU ISA relations: https://www.llvm.org/docs/AMDGPUUsage.html#processors
gfx1030 is indeed the RDNA2, aka SIENNA_CICHLID: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/master/src/topology.c#L239
And AMD had already announced CDNA aka gfx908, arcturus, Instinct MI 100 on sc20. you can find the news on phoronix: https://www.phoronix.com/scan.php?page=article&item=amd-mi100-rocm4. But I dont think CDNA is for indivisual customer.

@niculw
I hope there is not big difference between gfx101x and gfx103x. But if AMD dont add gfx1010 to CMakeLists.txt, we will need re-compile by ourselves.

At least gfx1010 was added to Tensile and that should enable gfx1010 usage in several other rocm modules, shouldn't it?
See: https://github.com/ROCmSoftwarePlatform/Tensile/wiki/Languages

@niculw
I hope there is not big difference between gfx101x and gfx103x. But if AMD dont add gfx1010 to CMakeLists.txt, we will need re-compile by ourselves.

GFX1030 is hopefully pretty similar to GFX1010 as i understand it GFX1030 just has extra instructions for ray tracing and a larger cache.. But the devil may hide in the details.. Like fixed instructions which where disabled in GFX1010 and are now working / used on GFX1030 or something like that..

This is the most commented (and most requested) issue of ROCm on Github and still no support from AMD.  So much for listening to the customer.

This is the most commented (and most requested) issue of ROCm on Github and still no support from AMD. So much for listening to the customer.

Again... this issue is opened (probably) because there were many closed issues and people were opening new ones. You can read comments and find out what is current status for navi10. Officially still unsupported.
To my understanding, AMD is developing ROCm stack to be used for high-margin (high cost) Radeon Instinct cards. AMD is not your fried, it's a for-profit company, even tough they are much more open source/standard friendly than the other GPU company.
AMD now clearly divided gaming and non-gaming cards with RDNA and CDNA. RDNA gaming cards (few $100) will be second class citizens, while CDNA (few $1000) cards will be first class.
So in the end, 5700xt, 6800xt, etc might never be supported at all.

Makes sense up to a certain point, yet it remains super frustrating not having an up to date OpenCL installed, which can be used in various programs to speed things up. Pretty much every NVidia card has support for CUDA, which can be used in many tools that are pretty much NVidia exclusive by now (besides falling back to CPU), since AMD is so far behind and as someone who really likes to use AMD, it's just frustrating.
I know that there is support for it in the amdgpu-pro stack, but it's pretty much worthless when you are dependent on an up to date kernel, like I am, as the kernel module compilation fails.
I have the same with ROCm, where the kernel module breaks, but somehow OpenCL is now working up to a certain degree after reinstalling the ROCm packages a few days ago. It's not really super stable and I wouldn't call it super fast, but it seems to work in e.g. Blender.
If I would know only a bit about this technology I'd be happy to help to make it work, but in this case I'm just a user. I would like to install it and have it work in my apps. Digging into the very details of how it works behind the curtains is way over my head and there is only so much time I can spend on things, so I cannot really help, I'm really sorry.

https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-opencl&num=1
for OpenCL  (like OpenGL and Vulkan) it is supported...
what is missing is official support for compute part (tensorflow...)
for a actual state my be some good description here:
https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-linux&num=1
https://www.phoronix.com/scan.php?page=article&item=amd-rx6800-opencl&num=1
(yes focus en RX6800 but apply for RX5700 in some way...)

OpenCL works only out of default Ubuntu (mesa) drivers. amdgpu-pro failed to install on my Ryzen 5 3600 xt + RX5700xt PC under Ubuntu 18 and Ubuntu 20 recently. Getting compilation errors.
I guess amdgpu-pro supposed to provide certain SYCL intermediate layer which is used by Codeplay's ComputeCpp™, though it's not working, limiting GPU compute options drastically, basically making it irrelevant (rewriting the whole code base from C++ to OpenCL when you want to speed it up instead of pressing one button is not the way to go).

OpenCL works only out of default Ubuntu (mesa) drivers. amdgpu-pro failed to install on my Ryzen 5 3600 xt + RX5700xt PC

OpenCL works fine with amdgpu-pro drivers. Also works fine with the latest (20.45) and rocm-smi returns info from the GPU.
========================ROCm System Management Interface========================
================================================================================
GPU[0] 		: Card series:		Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
GPU[0] 		: Card vendor:		Sapphire Technology Limited
GPU[0] 		: 1da3  Habana Labs Ltd.
GPU[0] 		: Card SKU:		D19901

GPU  Temp   AvgPwr  SCLK    MCLK    Fan   Perf  PwrCap  VRAM%  GPU%
0    46.0c  7.0W    800Mhz  100Mhz  0.0%  auto  220.0W   20%   0%
================================================================================
==============================End of ROCm SMI Log ==============================

@sofiageo what OS have you managed to install amdgpu-pro drivers on? Thanks in advance.

@sofiageo what OS have you managed to install amdgpu-pro drivers on? Thanks in advance.

I'm on Arch Linux using the opencl-amd package, which is using the files from the Ubuntu archive. I have no idea if I can run something ROCm specific though, every software I have already worked with OpenCL.
I made some tests with Blender and ProRender but I'm not sure that requires ROCm support either.

Never tried ArchLinux. It even says package is required by computecpp, amf-amdgpu-pro, etc. packages - all those I had so much troubles with in Ubuntu. I should give it a try. Thanks!

This is the most commented (and most requested) issue of ROCm on Github and still no support from AMD. So much for listening to the customer.

Again... this issue is opened (probably) because there were many closed issues and people were opening new ones. You can read comments and find out what is current status for navi10. Officially still unsupported.
To my understanding, AMD is developing ROCm stack to be used for high-margin (high cost) Radeon Instinct cards. AMD is not your friend, it's a for-profit company, even tough they are much more open source/standard friendly than the other GPU company.
AMD now clearly divided gaming and non-gaming cards with RDNA and CDNA. RDNA gaming cards (few $100) will be second class citizens, while CDNA (few $1000) cards will be first class regarding ROCm (my assumption).
So in the end, 5700xt, 6800xt, etc might never be supported at all.

If that's the route they go I'd unfortunately have to start looking at Nvidia again.

This is the most commented (and most requested) issue of ROCm on Github and still no support from AMD. So much for listening to the customer.

Again... this issue is opened (probably) because there were many closed issues and people were opening new ones. You can read comments and find out what is current status for navi10. Officially still unsupported.
To my understanding, AMD is developing ROCm stack to be used for high-margin (high cost) Radeon Instinct cards. AMD is not your friend, it's a for-profit company, even tough they are much more open source/standard friendly than the other GPU company.
AMD now clearly divided gaming and non-gaming cards with RDNA and CDNA. RDNA gaming cards (few $100) will be second class citizens, while CDNA (few $1000) cards will be first class regarding ROCm (my assumption).
So in the end, 5700xt, 6800xt, etc might never be supported at all.

If that's the route they go I'd unfortunately have to start looking at Nvidia again.

Agreed, I've been scouring to secure a 5700xt for my research work that uses Tensorflow, but honestly, if this is the response from AMD regarding using their products (which tend to be better) in direct competition, this is a shame. The fact that I have to pay another $100 - $150 for an arguably weaker GPU because of sheer ease of access is sad. I guess I'll have to try and scoop up a chapter RTX 2060 or 2070 if I'm lucky.

Agreed, I've been scouring to secure a 5700xt for my research work that uses Tensorflow, but honestly, if this is the response from AMD regarding using their products (which tend to be better) in direct competition, this is a shame. The fact that I have to pay another $100 - $150 for an arguably weaker GPU because of sheer ease of access is sad. I guess I'll have to try and scoop up a chapter RTX 2060 or 2070 if I'm lucky.

Do not go with Radeon if deep learning is primary objective!
I have similar story. I got RX480 when it came out as "display adapter" for me then new work pc. I just started my deep learning research after that time on servers with nvidia GPUs. Around that time ROCm came out, but my DL framework (modified caffe) didn't work with ROCm. Later switched to tensorflow and updated work pc's GPU to 5700xt since the ROCm+RX480 was working somehow with tensorflow. But support for navi still didn't came. I do my work on remote server with four Titan X gpus, so it doesn't affect me so much.
Anyway if you are student or would not like to dig too deep in gpu support, just go with nvidia. AMD wouldn't care too much if you do. They do care for enterprise server solutions with for specific solutions (accelerate specific workload).

This is the most commented (and most requested) issue of ROCm on Github and still no support from AMD. So much for listening to the customer.

Again... this issue is opened (probably) because there were many closed issues and people were opening new ones. You can read comments and find out what is current status for navi10. Officially still unsupported.
To my understanding, AMD is developing ROCm stack to be used for high-margin (high cost) Radeon Instinct cards. AMD is not your friend, it's a for-profit company, even tough they are much more open source/standard friendly than the other GPU company.
AMD now clearly divided gaming and non-gaming cards with RDNA and CDNA. RDNA gaming cards (few $100) will be second class citizens, while CDNA (few $1000) cards will be first class regarding ROCm (my assumption).
So in the end, 5700xt, 6800xt, etc might never be supported at all.

If that's the route they go I'd unfortunately have to start looking at Nvidia again.

Agreed, I've been scouring to secure a 5700xt for my research work that uses Tensorflow, but honestly, if this is the response from AMD regarding using their products (which tend to be better) in direct competition, this is a shame. The fact that I have to pay another $100 - $150 for an arguably weaker GPU because of sheer ease of access is sad. I guess I'll have to try and scoop up a chapter RTX 2060 or 2070 if I'm lucky.

Nobody is stopping you. Bye.
AMD is fully aware of the situation.
It is your job to decide what to do with available tools.

Anyway if you are student or would not like to dig too deep in gpu support, just go with nvidia. AMD wouldn't care too much if you do. They do care for enterprise server solutions with for specific solutions (accelerate specific workload).

Well they should, as the students of today, spending a couple hundred bucks for a GPU to accelerate their work for their thesis are the exact same people who will influence the decision to buy GPUs / Accelerator for a couple 100.000 bucks in the future.
Ease of access to an ecosystem is really important if you want to have qualified people on the open market.. If as a company i search for  a HPC expert which is fit in Solution/Ecosystem A and have a market of 100.000 qualified people and there is an Ecosystem B which is slightly faster and slightly cheaper but there is only a small set of people knowing how to work with it, the decision will lean to investing into Ecosystem A as it´s easier to get employees for the tasks..

I cannot understand this policy (“ROCm only for the enterprise hardware”).
Even though, I love AMD as a stock holder, Ryzen and Radeon user, I cannot suggest my friends to buy Radeon. (I CAN FOR RYZEN) User experience for the software support (including the other problems) was awkward. Please be better than NVIDIA in the software support!
I can understand that CDNA will have more energy efficieny for calculations. I can understand that RDNA will have less computing power than Radeon Instinct. However, I cannot understand RDNA cannot even run the officially supported ROCm or the other AI softwares.
As AMD has less market share, AMD should be more attractive in both hardware and SOFTWARE.

On Phoronix forums bridgman, one of AMD developers was rather vocal about the issue. From what I could gather they simply are lacking on the manpower, and chose to support enterprise, where the big money is, at the start. Supposedly that is about to change given Navi 2 cards use ROCm OpenCL instead of PAL in the official binary drivers, and work will start to be done in regards to the rest of the ecosystem.
But idk, it would be really nice to hear something official, at least "it's in the plans, but may take a while longer" from AMD

To be honest there is bunch of issues with ROCm-deep-learniing stack that for some reason does not exist for gpu-pro drivers

Support of Polaris GPUs that connected via PCI-E not connected directly to CPU
Support of APU - have have very decent  power
Support of RDNA and RDNA2

There is nothing special in deep learning code - bunch of well written kernels that enqueued to device via GPU compute API. I have no idea why for example convolution kernel can't run on ALL amd devices.
Today ROCN/AMD is by no means a viable platform for deep learning, The only working solution that does not bring too much issues is to run Caffe-OpenCL or plaidml... but performance is poor since AMD developers don't even bother to provide decent opencl kernels like cuDNN does.

On Phoronix forums bridgman, one of AMD developers was rather vocal about the issue. From what I could gather they simply are lacking on the manpower, and chose to support enterprise, where the big money is, at the start. Supposedly that is about to change given Navi 2 cards use ROCm OpenCL instead of PAL in the official binary drivers, and work will start to be done in regards to the rest of the ecosystem.
But idk, it would be really nice to hear something official, at least "it's in the plans, but may take a while longer" from AMD

Yup, just saw this post too:
https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-734881850
Quoting:

We are working on RDNA support as a lower priority project; trying to secure staffing to make it a high priority so it can happen quickly. For the last few years the ROCm focus has been on datacenter parts but that is gradually changing.

That sounds promising at least.

To be honest there is bunch of issues with ROCm-deep-learniing stack that for some reason does not exist for gpu-pro drivers

Which deep-learning framework options does one have with the gpu-pro drivers then?
Sorry for the dumb question, for me this AMD software/driver ecosystem is still a mystery :sweat_smile:

To be honest there is bunch of issues with ROCm-deep-learniing stack that for some reason does not exist for gpu-pro drivers

Which deep-learning framework options does one have with the gpu-pro drivers then?
Sorry for the dumb question, for me this AMD software/driver ecosystem is still a mystery 😅

Good question
There are two deep learning frameworks that just work with opencl Caffe/opencl branch and Karas/plaidml backend. Of course performance is about 1/2 of rocm-miopen/cudnn
I actually worked a lot with caffe/opencl even on Nvidia platform

I've watching Rocm for a few years now and it seems like it stuck in time, you can use AMD GPUs for Deep Learing with Opencl, but it's not that good, I was able to use an AMD GPU to work for Deep Learning with Tensorflow-Directml, which is such a nice idea, why run MLOps on a graphichs API? Vulkan might be a multiplatform DL runtime accelarator, being able to be used in every GPU manufacturer and any OS that's supports Vulkan, the Tensorflow seems to be willing to add new hardware accelarators, unfortunately the Pytorch seems quite averse to anything besides CUDA.  I think that DirectX and Vulkan are in a certain way a good start point for new ML execution ops.
Sources:
https://github.com/microsoft/tensorflow-directml
https://github.com/EthicalML/vulkan-kompute

Alright, thanks for your pointers. It looks like those deep-learning frameworks eventually need to be adapted to real computing language standards like OpenCL or Vulkan, instead of only supporting proprietary "standards" such as CUDA / cuDNN...
Isn't ROCm also going into that direction too, being open to other vendors too?

Alright, thanks for your pointers. It looks like those deep-learning frameworks eventually need to be adapted to real computing language standards like OpenCL or Vulkan, instead of only supporting proprietary "standards" such as CUDA / cuDNN...
Isn't ROCm also going into that direction, being open to other vendors too?

It isn't open to itself...
MIOpen a very critical DL component has Opencl version but

it doesn't work over non-rocm driver (windows, mac, AMD gpu-pro or clover)
it also doesn't support non AMD gpu
it doesn't support RDNA! And it wouldn't happen in near future unless somebody writes some assembly
The winograd kernel source doesn't exist it is just embedded binary blob written for GCN only

So unless AMD takes it seriously there's no decent way to use AMD

@artyom-beilis See #1100 and #1338. RDNA support is comming soon, according to @ROCmSupport.
It's known to all that ROCm is not mature yet. If you have an AMD GPU, it's probably better to wait and see.
So far ROCm is designed based on the Linux kernel. It directly calls the Linux kernel libraries. So I can see there will be a ton of work to do trying to bring this to Windows or macOS. Since they haven't got ROCm work properly even on Linux, I don't expect this coming soon.
As for productivity, of course, you should go with NVidia and CUDA, which is a more stable and effective choice after all.

No official support for Navi on ROCm 4.0.0. It's disappointing.

No official support for Navi on ROCm 4.0.0. It's disappointing.

I don't understand the point of this comment. The person above you showed proof that Navi support was being added in 2021, yet you're whining about not having support in a 2020 release? It isn't disappointing, it's expected. Sometime in 2021 we'll get Navi support, and they'll give us more details as they progress.

No official support for Navi on ROCm 4.0.0. It's disappointing.

I don't understand the point of this comment. The person above you showed proof that Navi support was being added in 2021, yet you're whining about not having support in a 2020 release? It isn't disappointing, it's expected. Sometime in 2021 we'll get Navi support, and they'll give us more details as they progress.

Considering that Navi is 1.5 years old by now, he's perfectly right to be disappointed. Finally just gave up waiting for AMD to seriously compete, just switched to a 3090 and it's already a massive improvement over ROCm.

No official support for Navi on ROCm 4.0.0. It's disappointing.

I don't understand the point of this comment. The person above you showed proof that Navi support was being added in 2021, yet you're whining about not having support in a 2020 release? It isn't disappointing, it's expected. Sometime in 2021 we'll get Navi support, and they'll give us more details as they progress.

Considering that Navi is 1.5 years old by now, he's perfectly right to be disappointed. Finally just gave up waiting for AMD to seriously compete, just switched to a 3090 and it's already a massive improvement over ROCm.

Considering that the ROCm team announced a few days ago that Navi support would come in 2021, and that the person I was replying to made a comment after that announcement, there was no reason to be disappointed. To be disappointed is to be saddened by the non-fulfillment of one's hopes or expectations. If someone hoped they'd get Navi support in 2020 after it's been announced it'd come in 2021, that is negligence.
I too am disappointed at this whole thing, as I've been following this for all of Navi's existence, and now use DirectML on WSL2. But to be disappointed that Navi support wasn't added in a specific version after an announcement was made that confirmed it wouldn't come in said version, is not right.

Actually, the latest is that RDNA 2 support is coming in 2021, they still won't talk about Navi/RDNA https://github.com/RadeonOpenCompute/ROCm/issues/1172#issuecomment-747215616

Actually, the latest is that RDNA 2 support is coming in 2021, they still won't talk about Navi/RDNA https://github.com/RadeonOpenCompute/ROCm/issues/1172#issuecomment-747215616

Actually, the latest is that Navi is being supported in 2021, as already mentioned by a previous commenter as per https://github.com/RadeonOpenCompute/ROCm/issues/1338#issuecomment-745182551

Actually, the latest is that RDNA 2 support is coming in 2021, they still won't talk about Navi/RDNA #1172 (comment)

Actually, the latest is that Navi is being supported in 2021, as already mentioned by a previous commenter as per #1338 (comment)

That comment is older than the one I linked, which suggests they're referring specifically to 6000 series in the one you linked.

Actually, the latest is that RDNA 2 support is coming in 2021, they still won't talk about Navi/RDNA #1172 (comment)

Actually, the latest is that Navi is being supported in 2021, as already mentioned by a previous commenter as per #1338 (comment)

That comment is older than the one I linked, which suggests they're referring specifically to 6000 series in the one you linked.

I'm wondering why they said "Navi" instead of "Big Navi", maybe that message was rushed?

Actually, the latest is that RDNA 2 support is coming in 2021, they still won't talk about Navi/RDNA #1172 (comment)

Actually, the latest is that Navi is being supported in 2021, as already mentioned by a previous commenter as per #1338 (comment)

That comment is older than the one I linked, which suggests they're referring specifically to 6000 series in the one you linked.

I'm wondering why they said "Navi" instead of "Big Navi", maybe that message was rushed?

Maybe, here's hoping it was a mistake and they clarify soon.

Stop wining, it works with Rocm 4.0.0: https://www.youtube.com/watch?v=-iYwbnvV2w0

It takes all of 2 seconds to read the description, consider reading it next
time before telling people to stop "wining".
On Sat, Dec 26, 2020, 8:38 PM Spacefish<EMAIL_ADDRESS>wrote:

Stop wining, it works with Rocm 4.0.0:
https://www.youtube.com/watch?v=-iYwbnvV2w0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-751414893,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7OP7JGA47W2HFAZYHJKU3SW2FZRANCNFSM4IWLS7FA
.

2020-12-27 UPDATE
After do some patch on ROCm-4.0, we can compiling binary which RX5700xt can run successfully.
Pytoch-1.7.1 can run successfully on RX5700xt, too.
BUT the loss of mnist wont change on pytorch.
So need AMD do more work on navi10.
Thanks spacefish for testing. He also upload a video for this unchanged loss situation.
https://github.com/RadeonOpenCompute/ROCm/issues/1306#issuecomment-751414407

Hi All,
Official support of Navi will come in 2021. Please stay tuned.
Thank you.

Hi All,
Official support of Navi will come in 2021. Please stay tuned.
Thank you.

Does this include Navi 10/RDNA cards or just RDNA 2 cards?

Hi @jemzipx
I can not comment on this right now. Request you to wait for some time.
Thank you.

@ROCmSupport Thank you for responsing the navi supporting plan. Right now, it seems like MIOpen cannot support navi10 for convulution layer, and full connection layer looks like OK. Waiting for your good news.

@ROCmSupport That's the attitude that we expect from AMD, happy New Year to everybody in the ROCm community and ML in general.

I just bought an AMD Sapphire 5700 XT and really would like to learn, explore, study and develop with ROCm using AI frameworks like TensorFlow for practical logistic problems. These exercies may be implemented at work in the future.
Please, be active in 2021 and add support for this graphic board as soon as possible. We payed a lot for this board (at least here in Brazil, saving for years in order to buy a decent graphic board like 5700 XT). It's very sad for us developers not to be allowed to use AMD boards at their full performance to solve real-world problems with Deep Learning and CV.
Thank you very much for listening.

I just bought an AMD Sapphire 5700 XT and really would like to learn, explore, study and develop with ROCm using AI frameworks like TensorFlow for practical logistic problems. These exercies may be implemented at work in the future.
Please, be active in 2021 and add support for this graphic board as soon as possible. We payed a lot for this board (at least here in Brazil, saving for years in order to buy a decent graphic board like 5700 XT). It's very sad for us developers not to be allowed to use AMD boards at their full performance to solve real-world problems with Deep Learning and CV.
Thank you very much for listening.

Am closing this as this is not a defect actually.
I request you to stay tuned for the new updates via our ROCm Documenation.
We will keep updating our ROCm documentation with all of the information.
Thank you.

Am closing this as this is not a defect actually.
I request you to stay tuned for the new updates via our ROCm Documenation.
We will keep updating our ROCm documentation with all of the information.
Thank you.

How can I subscribe to the ROCm documentation as easily as I have subscribed to this thread?

How can I subscribe to the ROCm documentation as easily as I have subscribed to this thread?

Thank you for your query about ROCm documentation.
You can access ROCm documentation at http://rocmdocs.amd.com. If you are unable to find what you need, please let us know. We do not have a community for ROCm Documentation as yet. However, we can help answer your ROCm product questions in this forum.
AMD ROCm Documentation Team

Thank you for your query about ROCm documentation.
You can access ROCm documentation at http://rocmdocs.amd.com. If you are unable to find what you need, please let us know. We do not have a community for ROCm Documentation as yet. However, we can help answer your ROCm product questions in this forum.
AMD ROCm Documentation Team

So AMD posts a comment here in December hinting that it might finally be happening and then a month later they just close the thread without any news? Sounds like a confirmation it isn't happening. Real nice.

So AMD posts a comment here in December hinting that it might finally be happening and then a month later they just close the thread without any news? Sounds like a confirmation it isn't happening. Real nice.

It definitely isn't happening, the thing about Navi support glosses over that they aren't saying anything about the 5000 series cards. At this point a refusal to commit to support is clearly just a way of avoiding admitting that they have no intentions to support them.   Going to be selling off my Anniversary Edition 5700XT and VII as soon as lockdowns ease and make it practical to do so.

It definitely isn't happening, the thing about Navi support glosses over that they aren't saying anything about the 5000 series cards. At this point a refusal to commit to support is clearly just a way of avoiding admitting that they have no intentions to support them.   Going to be selling off my Anniversary Edition 5700XT and VII as soon as lockdowns ease and make it practical to do so.

Hi @Qwertie- and @himanshugoel2797
As I informed before, we will come up with the support very soon, but I can not comment on specific series of cards right now.
More over, this is not a defect to keep it open for a long time.
I hope you understand my point.
We request you to wait for few more days for official support and keep watching our documentation.
Thank you.

THANK YOU FOR AT LEAST ACKNOWLEDGING IT

"ROCm does not seem to work on cards released in the last 18 months." is an arguably valid issue report, and leaving this issue open served as a sort of butterfly net to consolidate these interactions. Closing this issue without resolution will likely result in new fragmented reports, to nobody's benefit.

Is ROCm even still a thing? It does appear that the project has stalled with no support for new hardware architectures. How can it be that the newest architecture that is supported by ROCm is Vega which is nearly 3 years old.
As potential enterprise buyers, this roadmap does not instill any confidence of future support of AMD GPUs for compute workloads.

@hwchong I'm pretty sure it'll be supported on the current architecture and future ones( RDNA 1, 2 and 3) at least for the enterprise, but the consumer cards is the main focus, I wanna know how good is the RX 6800 for Deep Learning, there's some benchmarks on Directml and is seems promising.

It looks like the red team does not bother of ML/DL market at all. Like, formally, they tried, but it seems that the blue team will develop and produce GPU with all proper software sooner than AMD will add support for the two own last GPU generations to the already existing library.
I don't understand why this happens, but it's sad.

Is ROCm even still a thing? It does appear that the project has stalled with no support for new hardware architectures. How can it be that the newest architecture that is supported by ROCm is Vega which is nearly 3 years old.

There is support for newer hardware, it is only not released to this repo, yet. The latest amdgpu-pro OpenCL driver is fully ROCm based and supports RDNA 1 + 2.

@oleid and I can use it to run TF/pytorch using official documentation from rocmdocs? Like, everything works with the proprietary driver, just almost nobody knows that, and all dissatisfaction is about when opensource version will support the same features?

People forget that the technology that ROCm is competing is almost 15 years old, ROCm it's only getting close to what it should have been now. AMD has to make this work in the long-term, I'm looking forward to Windows support through WSL-2. Someone ran some Deep Learnig code on this card (RX 5700), but it doesn't run right yet.
https://www.youtube.com/watch?v=-iYwbnvV2w0

@oleid and I can use it to run TF/pytorch using official documentation from rocmdocs?

I only know about ROCm based OpenCL in amdgpu-pro. For the machine learning things more is needed. AFAIK MiOpen (which is used within tensorflow for the machine learning things) has an OpenCL based implementation as well as a HSA based implementation. It could be possible that the OpenCL bits from amdgpu-pro are already enough, but I don't really know. And I cannot test it.
It seems to be possible to use Keras with PlaidML and the OpenCL driver from amdgpu-pro:
https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-593420020 (many comments ago)
Maybe that would work for you as well?

So, "no"

Hi @Qwertie- and @himanshugoel2797
As I informed before, we will come up with the support very soon, but I can not comment on specific series of cards right now.
More over, this is not a defect to keep it open for a long time.
I hope you understand my point.
We request you to wait for few more days for official support and keep watching our documentation.
Thank you.

Well, almost two months has passed, how soon is "very soon"?

Yes, any news? Why is it taking so long?

Internal validation is in progress.
We need to stabilize it w.r.to ROCm, which it takes more time.
I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months.
Thank you.

Internal validation is in progress.
We need to stabilize it w.r.to ROCm, which it takes more time.
I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months.
Thank you.

Thank you. The ETA is all that I wanted to know, now I feel a lot better.

Internal validation is in progress.
We need to stabilize it w.r.to ROCm, which it takes more time.
I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months.
Thank you.

Thanks,
Does it include MIOpen? Winograd convolution kernels update?

Internal validation is in progress.
We need to stabilize it w.r.to ROCm, which it takes more time.
I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months.
Thank you.

Does this include Navi and Navi 2?

Internal validation is in progress.
We need to stabilize it w.r.to ROCm, which it takes more time.
I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months.
Thank you.

Does this include Navi and Navi 2?

If Navi1 is being considered then I believe it's safe to assume Navi 2 will be supported aswell
(Tin foil hat theory)
AMD is doing this right now after so much time because, Intel made their oneAPI public (including support for their entire gpu stack which is coming soon), NVIDIA dumped huge amount of AI based SAAS and IAAS services and now AMD wants to step in as well.

Wow AMD, no surprise that nVidia GPUs sell a lot more. It is 2 years since Navi 1 release still no proper support for 5700 let alone the newly released Navi 2 (6000 series).
I am going to buy nVidia makes no sense to buy AMD with this kind of support.

Wow AMD, no surprise that nVidia GPUs sell a lot more. It is 2 years since Navi 1 release still no proper support for 5700 let alone the newly released Navi 2 (6000 series).
I am going to buy nVidia makes no sense to buy AMD with this kind of support.

If you have nothing useful to say, don't say anything at all. The timeframe has already been given, either wait for it or buy something else, no need to state your frankly useless opinion that's already been repeated here a million times

Wow AMD, no surprise that nVidia GPUs sell a lot more. It is 2 years since Navi 1 release still no proper support for 5700 let alone the newly released Navi 2 (6000 series).
I am going to buy nVidia makes no sense to buy AMD with this kind of support.

If you have nothing useful to say, don't say anything at all. The timeframe has already been given, either wait for it or buy something else, no need to state your frankly useless opinion that's already been repeated here a million times

Actually I find his opinion very useful, it made me think on support behavior of AMD ROCm folks, when the open source driver is not in shape for usage with some new hardware they just say that the hardware is not supported and close the issue. I find this behavior incorrect from a professional stand point. Instead, as a multi-year AMD client, I would appreciate more collaboration with the user and prompt taking charge of the issue.

Wow AMD, no surprise that nVidia GPUs sell a lot more. It is 2 years since Navi 1 release still no proper support for 5700 let alone the newly released Navi 2 (6000 series).
I am going to buy nVidia makes no sense to buy AMD with this kind of support.

If you have nothing useful to say, don't say anything at all. The timeframe has already been given, either wait for it or buy something else, no need to state your frankly useless opinion that's already been repeated here a million times

Actually I find his opinion very useful, it made me think on support behavior of AMD ROCm folks, when the open source driver is not in shape for usage with some new hardware they just say that the hardware is not supported and close the issue. I find this behavior incorrect from a professional stand point. Instead, as a multi-year AMD client, I would appreciate more collaboration with the user and prompt taking charge of the issue.

Not only has this opinion been shared several times, it doesn't add anything to this discussion. The timeframe for support has already been stated. If you can't wait, then go buy another product, no need to needlessly vent on this issue. ROCm closed this issue as it was no longer an "issue", as it has already begun development to support these GPUs. Repeating the same opinions over and over again is not a reason to notify every subscriber here, it's just not the point of this forum.

Wow AMD, no surprise that nVidia GPUs sell a lot more. It is 2 years since Navi 1 release still no proper support for 5700 let alone the newly released Navi 2 (6000 series).
I am going to buy nVidia makes no sense to buy AMD with this kind of support.

If you have nothing useful to say, don't say anything at all. The timeframe has already been given, either wait for it or buy something else, no need to state your frankly useless opinion that's already been repeated here a million times

Actually I find his opinion very useful, it made me think on support behavior of AMD ROCm folks, when the open source driver is not in shape for usage with some new hardware they just say that the hardware is not supported and close the issue. I find this behavior incorrect from a professional stand point. Instead, as a multi-year AMD client, I would appreciate more collaboration with the user and prompt taking charge of the issue.

Not only has this opinion been shared several times, it doesn't add anything to this discussion. The timeframe for support has already been stated. If you can't wait, then go buy another product, no need to needlessly vent on this issue. ROCm closed this issue as it was no longer an "issue", as it has already begun development to support these GPUs. Repeating the same opinions over and over again is not a reason to notify every subscriber here, it's just not the point of this forum.

But you should admit that your last two comments are somehow impolite, and if I was you I would apologize.

I was going to stay out of this (mostly not to notify everyone subscribed for something useless) but I figured 6 notifs isn't too different from 5. sigh
Please stop this. I don't care for anybody apologizing to anybody else. I agree with everything PeterNjeim said, and I think "apologizing" is a waste of time for everyone who's subscribed that would rather not be notified.

The timeframe has been stated, you can decide if that's acceptable for you or not. Read this: https://github.com/RadeonOpenCompute/ROCm/issues/887#issuecomment-822222885
If you looked at the past comments of this Issue, there have been many similar complaints. No new opinions are being discussed.

With the above factors considered, I don't think it's worth notifying everyone. Or, to put it more blunt, I don't want to be notified for this. If you want to complain, please use a different medium.
I only want to be notified when there is actual progress, or a breakthrough/roadblocker is found that might change the ETA.

I was going to stay out of this (mostly not to notify everyone subscribed for something useless) but I figured 6 notifs isn't too different from 5. sigh
Please stop this. I don't care for anybody apologizing to anybody else. I agree with everything PeterNjeim said, and I think "apologizing" is a waste of time for everyone who's subscribed that would rather not be notified.

The timeframe has been stated, you can decide if that's acceptable for you or not. Read this: #887 (comment)
If you looked at the past comments of this Issue, there have been many similar complaints. No new opinions are being discussed.

With the above factors considered, I don't think it's worth notifying everyone. Or, to put it more blunt, I don't want to be notified for this. If you want to complain, please use a different medium.
I only want to be notified when there is actual progress, or a breakthrough/roadblocker is found that might change the ETA.

Has the timeframe for support been stated with any confidence? For example:
In Jan.

"We request you to wait for few more days for official support and keep watching our documentation."

Then in April (three months later),

"I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months."

If you have confidence in the time frame (and only a passing interest in ROCm) then you could just as easily mute the notifications for the next two months, or longer, and just check in then. If you don't have confidence but still want to know when things happen, just get updates when they release new versions.
The only groups that would actively need to follow this are: 1) Active dev community working on adding support, or 2) the rest of the followers that are tired of AMD lacking any kind of software support and would like to see changes being made or comment on the lack thereof.
It is definitely valid to call out complaints on this forum because that is exactly how AMD has provided any kind of acknowledgment of feedback.
That being said, I personally was tired of waiting for two years, so I bought a 3090 and I can say I have never looked back.

Just to remember to everybody discussing here: if you are not a ROCm developer or github admin, it is not your task to reprimand people here on whatever you might disagree with.  If you don't want to be notified it is as simple as to mute notifications or change your notification preferences to something less invasive.

I was going to stay out of this (mostly not to notify everyone subscribed for something useless) but I figured 6 notifs isn't too different from 5. sigh
Please stop this. I don't care for anybody apologizing to anybody else. I agree with everything PeterNjeim said, and I think "apologizing" is a waste of time for everyone who's subscribed that would rather not be notified.

The timeframe has been stated, you can decide if that's acceptable for you or not. Read this: #887 (comment)
If you looked at the past comments of this Issue, there have been many similar complaints. No new opinions are being discussed.

With the above factors considered, I don't think it's worth notifying everyone. Or, to put it more blunt, I don't want to be notified for this. If you want to complain, please use a different medium.
I only want to be notified when there is actual progress, or a breakthrough/roadblocker is found that might change the ETA.

Has the timeframe for support been stated with any confidence? For example:
In Jan.

"We request you to wait for few more days for official support and keep watching our documentation."

Then in April (three months later),

"I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months."

If you have confidence in the time frame (and only a passing interest in ROCm) then you could just as easily mute the notifications for the next two months, or longer, and just check in then. If you don't have confidence but still want to know when things happen, just get updates when they release new versions.
The only groups that would actively need to follow this are: 1) Active dev community working on adding support, or 2) the rest of the followers that are tired of AMD lacking any kind of software support and would like to see changes being made or comment on the lack thereof.
It is definitely valid to call out complaints on this forum because that is exactly how AMD has provided any kind of acknowledgment of feedback.
That being said, I personally was tired of waiting for two years, so I bought a 3090 and I can say I have never looked back.

So you have a 3090, claimed to have "never looked back", yet you are here in this thread, which is the definition of looking back. All these passive aggressive remarks need to stop. This opinion has been shared numerous times. It adds zero substance to this thread. Stop notifying people if there are no updates. An update to your opinion is not an update to the state of this thread. I am subscribed for updates to ROCm, not to your opinion. Almost every single one of your claims was already countered by Sage.  You admit that the timeframe could be uncertain, and so, I, someone who can't know for sure if that's a proper timeframe, will remain subscribed and unmuted.
Please, stop this nonsense. Someone shared an opinion that has been shared too many times. That is not a reason to reply on this thread. Every time someone argues against this they say something like: "I think that onion is useful". That's great, I thought it useful the first time too, but since this opinion has already been shared several times, it is no longer useful.
That was the only point I made. I never said you couldn't complain, I made a specific point and the people who replied to me made strawmen against me. The irony of asking me to apologize when I was completely logical and telling others to stop unnecessary emails to subscribers. As Sage said, this stops now.

I was going to stay out of this (mostly not to notify everyone subscribed for something useless) but I figured 6 notifs isn't too different from 5. sigh
Please stop this. I don't care for anybody apologizing to anybody else. I agree with everything PeterNjeim said, and I think "apologizing" is a waste of time for everyone who's subscribed that would rather not be notified.

The timeframe has been stated, you can decide if that's acceptable for you or not. Read this: #887 (comment)
If you looked at the past comments of this Issue, there have been many similar complaints. No new opinions are being discussed.

With the above factors considered, I don't think it's worth notifying everyone. Or, to put it more blunt, I don't want to be notified for this. If you want to complain, please use a different medium.
I only want to be notified when there is actual progress, or a breakthrough/roadblocker is found that might change the ETA.

Has the timeframe for support been stated with any confidence? For example:
In Jan.

"We request you to wait for few more days for official support and keep watching our documentation."

Then in April (three months later),

"I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months."

If you have confidence in the time frame (and only a passing interest in ROCm) then you could just as easily mute the notifications for the next two months, or longer, and just check in then. If you don't have confidence but still want to know when things happen, just get updates when they release new versions.
The only groups that would actively need to follow this are: 1) Active dev community working on adding support, or 2) the rest of the followers that are tired of AMD lacking any kind of software support and would like to see changes being made or comment on the lack thereof.
It is definitely valid to call out complaints on this forum because that is exactly how AMD has provided any kind of acknowledgment of feedback.
That being said, I personally was tired of waiting for two years, so I bought a 3090 and I can say I have never looked back.

So you have a 3090, claimed to have "never looked back", yet you are here in this thread, which is the definition of looking back. All these passive aggressive remarks need to stop. This opinion has been shared numerous times. It adds zero substance to this thread. Stop notifying people if there are no updates. An update to your opinion is not an update to the state of this thread. I am subscribed for updates to ROCm, not to your opinion. Almost every single one of your claims was already countered by Sage.  You admit that the timeframe could be uncertain, and so, I, someone who can't know for sure if that's a proper timeframe, will remain subscribed and unmuted.
Please, stop this nonsense. Someone shared an opinion that has been shared too many times. That is not a reason to reply on this thread. Every time someone argues against this they say something like: "I think that opinion is useful". That's great, I thought it was useful the first time too, but since this opinion has already been shared several times, it is no longer useful.
That was the only point I made. I never said you couldn't complain, I made a specific point and the people who replied to me made strawmen against me. The irony of asking me to apologize when I was completely logical and telling others to stop unnecessary emails to subscribers. As Sage said, this stops now.

Repeating:
Just to remember to everybody discussing here: if you are not a ROCm developer or github admin, it is not your task to reprimand people here on whatever you might disagree with.  If you don't want to be notified it is as simple as to mute notifications or change your notification preferences to something less invasive.

I was going to stay out of this (mostly not to notify everyone subscribed for something useless) but I figured 6 notifs isn't too different from 5. sigh
Please stop this. I don't care for anybody apologizing to anybody else. I agree with everything PeterNjeim said, and I think "apologizing" is a waste of time for everyone who's subscribed that would rather not be notified.

The timeframe has been stated, you can decide if that's acceptable for you or not. Read this: #887 (comment)
If you looked at the past comments of this Issue, there have been many similar complaints. No new opinions are being discussed.

With the above factors considered, I don't think it's worth notifying everyone. Or, to put it more blunt, I don't want to be notified for this. If you want to complain, please use a different medium.
I only want to be notified when there is actual progress, or a breakthrough/roadblocker is found that might change the ETA.

Has the timeframe for support been stated with any confidence? For example:
In Jan.

"We request you to wait for few more days for official support and keep watching our documentation."

Then in April (three months later),

"I can not comment on exact timelines as of today, but, roughly, will be available in next 2 to 4 months."

If you have confidence in the time frame (and only a passing interest in ROCm) then you could just as easily mute the notifications for the next two months, or longer, and just check in then. If you don't have confidence but still want to know when things happen, just get updates when they release new versions.
The only groups that would actively need to follow this are: 1) Active dev community working on adding support, or 2) the rest of the followers that are tired of AMD lacking any kind of software support and would like to see changes being made or comment on the lack thereof.
It is definitely valid to call out complaints on this forum because that is exactly how AMD has provided any kind of acknowledgment of feedback.
That being said, I personally was tired of waiting for two years, so I bought a 3090 and I can say I have never looked back.

So you have a 3090, claimed to have "never looked back", yet you are here in this thread, which is the definition of looking back. All these passive aggressive remarks need to stop. This opinion has been shared numerous times. It adds zero substance to this thread. Stop notifying people if there are no updates. An update to your opinion is not an update to the state of this thread. I am subscribed for updates to ROCm, not to your opinion. Almost every single one of your claims was already countered by Sage.  You admit that the timeframe could be uncertain, and so, I, someone who can't know for sure if that's a proper timeframe, will remain subscribed and unmuted.
Please, stop this nonsense. Someone shared an opinion that has been shared too many times. That is not a reason to reply on this thread. Every time someone argues against this they say something like: "I think that opinion is useful". That's great, I thought it was useful the first time too, but since this opinion has already been shared several times, it is no longer useful.
That was the only point I made. I never said you couldn't complain, I made a specific point and the people who replied to me made strawmen against me. The irony of asking me to apologize when I was completely logical and telling others to stop unnecessary emails to subscribers. As Sage said, this stops now.

Repeating:
Just to remember to everybody discussing here: if you are not a ROCm developer or github admin, it is not your task to reprimand people here on whatever you might disagree with.  If you don't want to be notified it is as simple as to mute notifications or change your notification preferences to something less invasive.

I wrote my message before you sent yours, that's why it looks like I ignored you. No need to repeat

Just to remember to everybody discussing here: if you are not a ROCm developer or github admin, it is not your task to reprimand people here on whatever you might disagree with.  If you don't want to be notified it is as simple as to mute notifications or change your notification preferences to something less invasive.

This statement has confused me so much that I'm implored to ask: So, are you a dev/admin and making this statement from the position as such? (I honestly can't tell, as I fail to see why somebody not in the position would make such a comment)
If so, sure, agreed. If not, I do still agree but that sounds oddly hypocritical. Especially from a person who recommended another person to apologize. (Is that not reprimanding?)
I also fail to see how "unsubscribe or change your notification settings" is a solution. I - and I presume others too - want to be notified, that is, for stuff I consider relevant to the issue of "Any update on 5700 Xt support?". But yes, I'll follow your advice and unsubscribe for a day or two or three.

Just to remember to everybody discussing here: if you are not a ROCm developer or github admin, it is not your task to reprimand people here on whatever you might disagree with.  If you don't want to be notified it is as simple as to mute notifications or change your notification preferences to something less invasive.

This statement has confused me so much that I'm implored to ask: So, are you a dev/admin and making this statement from the position as such? (I honestly can't tell, as I fail to see why somebody not in the position would make such a comment)
If so, sure, agreed. If not, I do still agree but that sounds oddly hypocritical. Especially from a person who recommended another person to apologize. (Is that not reprimanding?)
I also fail to see how "unsubscribe or change your notification settings" is a solution. I - and I presume others too - want to be notified, that is, for stuff I consider relevant to the issue of "Any update on 5700 Xt support?". But yes, I'll follow your advice and unsubscribe for a day or two or three.

No I am not a dev/admin, only a long time ROCm user and app contributor. My reply was in defense of free speaking and personal liberty to express opinion. The alleged recommendation to apologize, was merely given as suggestion (would and not must) for the sake of community respect. I didn't start this flame and my attempt to help make peace failed miserably. For penitence I will skip dinner.

@PeterNjeim You wrong in saying that complaining does not work and it does not add to the conversation. It works very very well if there is enough numbers. AMD is completely ignorant on GPGPU tasks that so many of us need to use from a professional perspective. I tried to find a channel that has direct connection with AMD higher ups for a long time to understand their viewpoint on this topic. This is the only place that the complain actually reaches to their lower level engineers. For example if in this thread 10000 people said they need this i can guarantee you AMD would put significant resource on this task. And regarding the point that they already gave a time line, check the optimistic timeline already almost passed. They did not gave any other explanation of the progress. Similar thing has been going on for the last 1.5 years. It is totally within my rights to voice my frustration that how AMD can be such oblivious to such an obvious thing. My suggestion to  you is to keep your suggestion to yourself if you are not a contributor to this endeavor. Please refrain yourself from trying to educate others on what makes sense when you clearly dont understand the point.
FYI: i am a long time AMD user(15 years+) and Software Developer. Currently have in possession both AMD and nVidia products.

@PeterNjeim You wrong in saying that complaining does not work and it does not add to the conversation. It works very very well if there is enough numbers. AMD is completely ignorant on GPGPU tasks that so many of us need to use from a professional perspective. I tried to find a channel that has direct connection with AMD higher ups for a long time to understand their viewpoint on this topic. This is the only place that the complain actually reaches to their lower level engineers. For example if in this thread 10000 people said they need this i can guarantee you AMD would put significant resource on this task. And regarding the point that they already gave a time line, check the optimistic timeline already almost passed. They did not gave any other explanation of the progress. Similar thing has been going on for the last 1.5 years. It is totally within my rights to voice my frustration that how AMD can be such oblivious to such an obvious thing. My suggestion to you is to keep your suggestion to yourself if you are not a contributor to this endeavor. Please refrain yourself from trying to educate others on what makes sense when you clearly dont understand the point.
FYI: i am a long time AMD user(15 years+) and Software Developer. Currently have in possession both AMD and nVidia products.

I agree with this, AMD timelines have been optimistic for at least 3 years now, often they release software past the timeline where the issues are not yet resolved, and they push a subsequent extension to timeline. This gives the impression of, at best, poor estimation of workload to do, or excessive estimation of developer capacity. Professionally this makes a loss to credibility of AMD estimation capabilities.