ROCm pytorch をコンパイルする試み(2018 年 7 月 27 日時点 実行時 seg fault)
https://qiita.com/syoyo/items/ecb0ee0797d1d192666f
から 1 年が経ちましたので振り返ってみます.
2019 年 9 月 24 日追記
ROCm PyTorch ビルド済み Docker イメージがありました.
rocm2.7_ubuntu18.04_py3.6_pytorch など, _pytorch のプレフィックスがついているタグになります.
_pytorch prefix タグなしは, PyTorch ビルド用の環境(e.g. hip コンパイラなど)のみを提供している Docker イメージです.
image が 3.5 GB もあるので, wheel パッケージを配布してほしいところです.
(野良ビルド wheel を作って配布してもよいのですが, オフィシャルから出るのが理想)
2019 年 7 月時点の状況
ROCm, MIOpen など各種ライブラリの整備が整備され, PyTorch も 1.1 となり, ビルドも整備され, やっと基礎的なものが動くくらいにはなりました.
現状では ROCm TensorFlow のように prebuilt バイナリはありません.
Pytorch-ROCm DockerでPytorch-ROCmをビルドしてみる(ROCm2.4編）
https://qiita.com/T_keigo_wwk/items/1a525768ad7585bda34f
などを参考に自前ビルドが必要です.
ビルド所感
HIP でのコンパイルが激重で, 時間がかかります.
Ryzen5 1600 + 24GB + MAX_JOBS 4 で 108 分, Threadripper 1900X + 64GB mem + MAX_JOBS 8 で 58 分でした.
hipcc がメモリを使うので, MAX_JOBS で並列ビルド数あげるばあいはそれなりにメモリが必要です(1 job あたり 6~8 GB 必要そう).
はやく pip などでのコンパイル済みパッケージ配布を整備して欲しいですね.
(もしくは Jenkins での build artifact をダウンロードできるようにしてほしい)
コンパイルが遅いと, 学習時にエラーがおきたりおかしかったときのデバッグもやりずらくなります.
動作所感
MNIST, CIFAR10, VGG など古典的で convolution や画像処理系は学習/推論は問題なく動作すると思われますが, 新し目のモデルや, LSTM, GRU などの RNN 系, 音声系は全滅(うごかない, 計算がおかしい, 動作しても CPU/GPU と比べて 5 ~ 100 倍くらい遅い)でした.
たとえば, deepspeech などいくつか音声認識, tacotron など音声合成系の学習をためしましたが, 1080 Ti ~ 2080 Ti などと比べて 4~6 倍くらいは遅く, また複数 GPU にするとさらに遅くなりまともに使えるものではありませんでした(高性能 CPU で学習したほうが速い). さらにわるいことにはときどき NaN が出たりします.
(正確になにが原因か突き止めるのは面倒で時間もかかるのでやってませんが, 概ね MIOpen や ROCfft など周辺ライブラリに問題がありそうです)
今後の所感
まず, Polaris などの GPU(gfx8xx) は今後の ROCm では基本活発な開発は中止(no active development)になります.
機械学習を始めたい優秀な小学一年生さまに,
冬到来! RX470 8GB マイニングエディションと ROCm TensorFlow で, GPU 機械学習をはじめよう(CIFAR10 7,600 examples/sec @ 88W)
https://qiita.com/syoyo/items/c6bc6dd4efbc10049640
というのをやりずらくなります. 
RX5700 などの NAVI 世代(RDNA)は, 主にゲーム向けというのもあり, まだ ROCm 対応していません(ROCm 以前に, コンパイラ周りの整備も必要になり, 開発環境が対応する時間はかかりそう)
したがって現状しばらくは Radeon VII, VEGA56/64 に限定されます. しかし Radeon VII は製造中止になったらしいというニュースも出てきています(VEGA56/64 はすでに終わっているかしらん).
その上で, ROCm(+ PyTorch/TensorFlow, MIOpen) が今後開発が続きメンテされるか... という不安もあります(MIOpen 含め, 一部のソフトウェアスタックは Roadrunner 向けにサポートが続きそうではありますが).
そんな不安を抱えつつ, ベンダー以外のユーザが ROCm PyTorch ビルドを直したりバグの原因を突き止めるには多大な労力と時間が必要になるため, ROCm PyTorch は参考程度にして, 自作 DNN フレームワークを作ったほうが早そうな感がしています.
(もしくは PlaidML で OpenCL ベースで DNN できる環境を整える)
自作の場合は, Vulkan + Compute Shader(次点で Fragment Shader) というのがよいかもと感じています(少なくともゲーム向けにドライバ周りの開発は十分行われるはずなので. Linux でも AMDGPU-Pro 19.30 ドライバですと Navi で Vulkan 対応は済んでいる模様ですので, headless 環境で multi GPU で動かせるものと思います).
Vulkan だと Windows でも動くという利点があります(ROCm は Windows 未対応)
Vulkan での欠点は, 基本高級言語が HLSL/GLSL に限られる, RCCL が使えない(GPU 間 collective 通信ができない. multi GPU は Vulkan でも対応しているので, もしかしたら拡張でなにかあるかも?)でしょうか.
Vulkan 向けの高級言語については, 限定的ではありますが, OpenCL カーネルを Vulkan(SPIR-V) に変換するツールも出てきています.