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

2019年01月03日

LinuxVulkan奮闘記

Windows10で作成したVulkanフレームワークをLinux版の自作エンジンで使ってみたのですが動かすの苦労しました。

---------------------------------------------------------------------
OS:LinuxMint18.3 Sylvia Mate64-bit
API:VulkanSDK 1.1.85.0 (Vulkan_hpp)
IDE:QtCreator(4.7.2/non-Qt/CMake)/ NetBeans(8.2)
PC:Corei3/GT1030/RAM8GB
VGA:nvidia-384(現在は415)
---------------------------------------------------------------------


問題:SDL2がSDL_SysWMinfo.info.x11のフィールドを寄越さない
原因:SDL_Config.hが未設定
解決:設定済みSDL_Cofig.hがCMakeの出力ディレクトリにあるのでそれに置き換える



問題:GCCだと起動できるのにClangだとSIGILL
原因:returnを書いてなかった
解決:無駄にメソッドチェーンなんてするもんじゃねぇ



問題:ウインドウをリサイズするとOSを巻き込んだフリーズが発生。
原因:不明.ドライバを384→415に更新したら再現条件と挙動が変わったのでドライバも怪しい
解決:不能



リサイズの問題、ドライバ更新前は縮小リサイズと拡大リサイズでバグの出方が違っていて、縮小リサイズはビューポートの変更がウインドウに反映されない、拡大リサイズは一瞬でOSが固まるという症状でした。
ドライバ更新後は、縮小リサイズ時にビューポートの変更が反映されるようになりましたが、OSがフリーズするようにもなりました。拡大リサイズは相変わらず即時フリーズです。
数分かかりますがフリーズ状態から復帰することが可能なことから、単に処理がビジー状態なだけの気もしますが、ドライバ更新前は縮小方向リサイズではフリーズしなかったことから、そうとも言い切れない部分もあってまぁ結局のところさっぱり分かりません。しねしね。





//番外編

問題:GCCで自作エンジンのシステム+OpenGLが動かない
原因:GCC
解決:Clang

posted by gency at 05:37| Comment(0) | 3DProgramming

2018年08月04日

ダサいロゴでお馴染みのVulkanをやります

OpenGLが使えなくなるMacのためにMetalを実装しようと思ったのですが、いろいろあってVulkanにしました。
めんどくさいAPIだけど頑張るぞー。
とか言って実はもうそこそこ実装は進んでいて、最低限ですがゲームを作れるくらいの機能は揃っていたりします。
いまはオフスクリーンレンダリングを実装中ですが、描画ばかりで飽きたので時々マルチスレッドの設計を混ぜつつという感じでやっています。まぁ、Vulkan自体に飽きてきたってのも正直否めないので、そろそろMetalを始めようかなという感じですね。
Swiftちゃん!!!!(発作


Vulkanをやる前に遊びでD3D12のサンプルもいくつか叩いてみるなどしました。バンドルを使った三角形描画(2D)を実装して、モデルデータ導入(3D)の途中で果てています。
D3D12を自作エンジンに対応させたいと考えていた時期もありましたが、実際にVulkanを実装した今となってはMetalすらちょっとキツイ感じがしているので、D3D12には対応しないことにしました。
D3D12は低オーバーヘッドAPIの入門に良さそうだと思って叩いてみたのですが、対Vulkan用としては大して勉強にならなかった気がします。Vulkanは格が違いましたね(糞さの格


自作エンジンのOpenGL実装についてですが、Vulkanの実装に置き換えしだいOpenGL実装はプロジェクトから削除することにしました。今後の新機能追加やメンテのことを考えると、Vulkanと設計が違うOpenGLを残すことはできないと判断した次第です。
2年かけて育ててきたGL実装を捨てるかどうかの決断なので迷いましたが、Vulkanを実装した後は意外とあっさり「よし捨てよう」って感じで即決できました。Vulkanが動かない環境を切り捨てることでもあるのですけど、どうやら私はその辺のことは気にしてないようです。。
手段が目的かしとるなこれ。



おまけでタイトル回収。

カップ

今のVulkanのロゴはこんな感じになってます(ティーポットの絵文字がなかったのでお茶にしました)。
ティーポットの存在は言われるまで気付かなかったけど、よーく見たら確かにありました。分かり難し。
実はまだ知られざる何かが隠れていたりするんでしょうかね(しない


ちなみに今日のタイトル、本当は上の絵文字だけにしようと思ったのですが、残念ながらこのブログは機種依存文字をタイトルとして使えないようで、編集データを保存しても次に編集しようとしたときには消えてました。
まりなさん、直して(無茶




おまけその2:一週間苦しんだバグの原因


誤)if(cmd) return;

正)if(!cmd) return;


この超絶な凡ミスのせいでタイリング最適化したテクスチャの描画ができなくて1週間嵌りました。バッファかビューかデータ転送が原因だと思ってずーっと探してたのに、コマンドが送信出来てなかったというオチ。
そりゃあティーポットも見つからんわけですよ。

posted by gency at 15:32| Comment(0) | 3DProgramming