2019年05月01日

LinuxでVulkanが動かないのでVulkanやめます

AMDのAPUで自作したPCにUbuntuを入れてVulkanを動かしてみました。構成は以下のとおり。

CPU:Athlon200GE
GPU:Radeon Vega3
MB:MSI B450Mini-ITX
OS:Ubuntu18.04.2
PSU:中華製DC−DCとACアダプター

ドライバについてはよく分かりません。Mesa-vulkan-driversというのが入ってるっぽいです。バージョンは19.1っぽいです。AMDのプロプライエタリなドライバはOSがバグってログインできなくなる可能性があったので入れませんでした。
Vulkanのバージョンは、手動でセットアップするのが面倒臭かったのでaptインストールしたら1.1.70という古めのバージョンを突っ込まれました。私が使っているVulkanSDKは1.1.86(大して変わらんくらい古い)で、それ用に書いたコードなので、まともに動くは怪しいです。
まぁ、このAMDマシン、VulkanどころかそもそもOSすらまともに動いてないですから、Vulkanのバージョンの違いなんて誤差みたいなもんですよ(やけくそ

動作テストの内容は、テクスチャを貼り付けた3つのキューブを回転アニメーション、テクスチャスクロールアニメーションさせるだけの簡単なものです。コマンドはセカンダリーコマンドバッファにレコードしたコマンドを再利用する感じの実装。Uniformはモデルごとのセットを用意し動的Uniformを使って更新しています。PushConstantとかも実装していますが、まぁDynamicUniformがあれば使うことはないですね。テストもできたけどやってないです。

シェーダーはGLSLの埋め込みコードをエンジン内部でSPIR-Vにコンパイルして、シェーダーモジュールを作成しています。glslangは依存関係の解決が面倒なので、shaderc-combinedというクソデカバイナリの力を借りて関数をロードしています。shaderc(glslangのラッパー)自体は使ってないです。なお、コンパイル済みのspvをロードする機能は用意してません。たぶん、あと5年くらいは使わないと思ったので実装しませんでした。このぶんだと未来永劫使うことはないですね。

割と網羅的なテストで、モデルをスキニングして動かすくらいはできると思います。ただ、GPUスキニングは少し怪しいかもしれません。Uniformの配列は実装してなかった気がします(Uniform書いてたのは8ヶ月前なのであらかた忘れてる)。

InputAttachmentとFrameBufferを使った遅延レンダリングは、実装途中のため(半年放置中)テストに含めていません。コマンドの並列化もしていません。また、LinuxMintでコマンドバッファの動的レコードが動かなかったので、このテストもしていません。さらにはリソースの動的構築もテストしていません。理由はもちろん、バ グ る か ら で す。
除外したこれらの機能は、主にエディタ作成で必要になる機能です。Windows10で開発中の未完成品ですが、Windows10ではそこそこ正常に動いています(設定を変えなければバグらない程度に)。ただ、LinuxMintで行った動作テストでは動かなかったので、今回の動作テストからは除外しました。



(テストの時の画像とか貼りたかったけど、Ubuntuが壊れたので貼れなかった跡地)



動作テストの結果ですが、深度テストが動きませんでした。バッファの設定が反映されてないのか描画順になっていました。同じマシン上でデュアルブートしているWindows10でも同じ症状が出ているので、Ubuntuのドライバや、Vulkanのバージョンは関係なさそうです。たぶんですが、Vulkan-hppが怪しいですね。参照の寿命が切れちゃってそう。Vulkan-hppではよくあることです。でも、仮にそうだとしたら同じコードとコンパイラなのにIntelで発生せずAMDで発生した理由が分かりません。CPUが変わったことで発生したと考えるしかない状況だけど、そんなことあるのか謎。参照が原因じゃないとしたらちょっと分からないです。

LinuxMintではウインドウリサイズ時のフリーズが発生していましたが、AMD/Ubuntuでも発生しました。Intel/Nvidia/LinxuMint環境でのようなOS全体を巻き込むフリーズこそなかったですが、AMDはウインドウリサイズが全く動作せず確定でアプリがフリーズしました。原因は、LinuxMintと同じでGPUの過剰酷使(メモリアロケートがデタラメなためっぽい?)だろうと考えていますが、症状が違う理由については分かりません。


目に見える不具合はこの二つだけでした。意外と動いたなという印象ですが、ウインドウリサイズの問題はいつ見てもやはり致命的。スマホなら問題ないとしても、PCアプリとしては終わってます。バグを修正しようにも自作のVulkanフレームワークは、とんでもないウンコードなので、アロケータを修正するのは困難を極めます。たぶん書き直すのと変わらない感じになりそう(仮に書き直すとしたら、Vulkan-hppを使わず書きたいです。あれはバグの素でしかない)。なので、怠いのでウインドウリサイズの問題は修正しないつもりです。

で、修正せずにどうするかですが、とにかくもうVulkanはいちいち面倒臭すぎて大変なので、これっきりでやめることにしました。時間かかるしいちいちバグるので、やる気がゴリゴリ削がれてやってらんねぇです。
Windows10だと適当に書いてもだいたい動いたので、これは行けるかなぁって思ったのですけど、Linuxだと全然ダメですね。かなり厳しいと感じています。特にエディタアプリ用の実装が厳しいです。ゲーム用実装はVulkanの本分のジャンルでもあるので割と動くのですが、私はOpenGLの置き換えを目指しているのでエディタもVulkanで作りたいのです。しかし、それが全くうまく行きません。ていうか、そもそもエディタ関連部分を全て除外した簡単なテストすらクリアできていません。ズタボロです。挫けそう。

とにかく、Vulkanは私には無理だった、というのが今回出た結論ですね。
NextVulkan、というか、真のNextGLが出てくるまで、OpenGLを使い続けることにします。
以上、動作テスト(と愚痴)の話でした。



あっ、ちなみにAMD/Radeon構成で初となるOpenGLの動作テストもしましたが、不具合は一切ありませんでした。素晴らしいの一言ですね。



あと、Metal2実装もやると言ってましたが、それについては、そもそもApple機器への対応をやめることも考えているので、こっちもしばらく凍結します。凍結の理由ですが、昨年10月にMacmini2018がリリースされた後のモハベのアップデートで、我が家のmini2014が急にレインボーカーソルを連発し始めました。どうやら機能制限された模様。悔しいのでAppleとは縁を切りたい。ざっくり言うとそんな感じですね。
開発機なのでOSは常に最新状態にしておきたいのですが、昨年のアプデ後のmojaveは、日本語入力に2、3秒の遅延が発生してまともに入力できなくなっていました。これでは開発機としての使用は無理です。我慢すれば使えるとかいうレベルではなく酷すぎました。OSの起動時間もSSDなのに5分かかるようになったし、スリープ復帰にも30秒以上かかるなど、頭おかしいレベルの機能制限をされたので、正直若干ショックすら受けました。
ここまで酷いと不具合の可能性もありそうですが、当時はそこまで考えが及ばず、さっさとハイシエラに戻しました。今さらMojaveに戻して試す気にはなれません。ていうか、こういう嫌がらせじみたことされた経験ってあまり無かったので悲しいです。Mojaveのことはさっさと忘れたい。
ちなみに、ハイシエラは激遅の内蔵2.5インチHDDで運用していますが、HDDハイシエラは、SSDモハベより全然サクサク動きます。どんだけだよって感じですね。


posted by gency at 01:33| Comment(3) | 3DProgramming
この記事へのコメント
すいません。連絡先がわからなくてこちらに書かせてもらいました。

初音ミクのモデルを使用させてもらってPV作っています。

よろしくお願いします。
Posted by すーぱー at 2019年07月28日 00:13
(≧∇≦)b
Posted by gency at 2019年08月02日 18:58
https://www.youtube.com/watch?v=9ixOdleV9C4
完成していろいろ手続き中なのですが、許可関係を示してくださいとのことでした。

ツイッター ultimatemt4で連絡いただきたくよろしくお願いします。
Posted by すーぱー at 2019年11月26日 16:31
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: