DirectX12 フルスクリーンの罠

DirectX12 でフルスクリーン描画を行おうとしたときに、予想外に色々と苦戦しました。
DirectX12 というよりは、フルスクリーンは DXGI の機能・制御管轄なので、もしかすると今回の話は DirectX11 でも症状が出るのかもしれません。もしかすると環境要因もあるのかもしれませんが、何かの参考になれば幸いです。

出遭ったこと

「ALT+ENTER でフルスクリーンとウィンドウモードを行き来(切り替え)をしたい。」
これを実現するのに苦戦しています。

ディスプレイの解像度に対してのフルスクリーンとウィンドウモードの切り替えは、標準 DXGI の機能で問題なく出来ました。
ですが、描画の内容によっては指定された解像度でフルスクリーンとしたいことがあり、描画ターゲットの解像度を変えるのでは無く、ディスプレイの解像度設定のほうを変更したいという条件になります。

これには初期化時に DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH フラグを設定しますが、これがあると色々と問題に出遭いました。

続きを読む


Vulkan での排他フルスクリーン

Vulkan でフルスクリーンアプリケーションを作ろうと思ったら、全画面のウィンドウを枠なしで作るという方法でした。
いわゆる仮想フルスクリーンの手法です。OpenGL でもフルスクリーンのアプリケーションは同様の手順で作るので、特に違和感はありませんでした。
ただ、DirectX9 時には専用のフルスクリーン設定がありましたし、9.0c 以降では DXGI がそのあたりの設定を引き受けてくれていました。

VK_EXT_full_screen_exclusive

しかしつい最近に Vulkan にも排他フルスクリーンの拡張が用意されました!
それが VK_EXT_full_screen_exclusive です。紹介文を軽く読むと、ディスプレイのコンポジッタを迂回してフルスクリーン化が出来るようなので、画面表示完了までのレイテンシーは短くなるのではないかと期待です。

拡張そのものの説明は https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/VK_EXT_full_screen_exclusive.txt に記載されています。

NVIDIA の環境では、 Windows 版だと 425.89, Linux 版だと 418.52.14 のドライバでサポートされるようです。ただどちらもまだベータドライバなのでその点には注意が必要です。
RADEON の環境では、Adrenalin 2019 19.6.2 から対応されて居るみたいですね。

最近は不安定なドライバを入れて実験する時間がないので、安定版になってから試してみようと思います。


Git LFS について(オブジェクトとロック)

以前に 「Git LFS を使ってみる」という記事を書いたのですが、現在のものと少し合わなくなってきている感じがしたので書き直しました。
Git LFS が出始めの頃と比較すると利用できる環境は格段に増えています。

Git LFS について

出始めの頃は別パッケージとしてインストールが必要でしたが、現在は Git for Windows の中に含まれています。
Git LFS は、指定されたファイルタイプ(拡張子による設定など)によって、特別な処理を行いバージョン管理させる仕組みとなっています。
具体的には、比較的ファイルサイズが大きくなるバイナリファイルを対象に指定して、バイナリファイルへのリンク情報をテキストの形にして git によるバージョン管理に載せる動きとなります。
リポジトリ上では、バイナリファイルは git の標準のデータ構造とは別の場所に格納されていたりします。

現在においては、各種 git リポジトリサービスが、この Git LFS に対応しています。

  • GitHub
  • GitLab
  • GitBucket
  • GitBlit
  • Bitbucket
  • Azure DevOps

ただ Git LFS にもバージョンがあり、現時点においては git-lfs のバージョンは 2.7.2 となっています。この過程で Git LFS の通信プロトコルにも拡張が入ることがあり、機能が増えたり、作業の改善があったりとします。
例えば初期では LFS 対象のバイナリファイルが1つずつしかダウンロード出来ていなかったのが、複数を並列でダウンロード出来るようになったりしました。
こういった点より、リポジトリサービスを提供するアプリケーションもバージョン更新が定期的であることが理想的です。GitBlit はかなりの間、バージョン更新が無いようなので利用はあまりオススメできないかと思います。

続きを読む


OpenGL で描画先独立なブレンディング設定を使う

OpenGL でデュアルソースブレンディングを使うと、出力先カラーバッファが1つになってしまう!という話を聞いて、「1つのカラーバッファに2色出力し、ブレンド設定でさらに演算」という場面ってどのくらいあるのだろうと疑問に思いました。(おそらくデスティネーション色と処理したいのでしょうが)。
そんな中、Multiple Render Target (MRT)で、各カラーバッファのブレンディング設定は独立に出来たはず、と思うことがあったので使い方を確認してみました。
ちなみに、DirectX11 ではカラーバッファのブレンディング設定の独立(個別)は簡単にできます。D3D11_BLEND_DESC構造体を見るとすぐに分かります。

結果としては、 OpenGL でもこのようにブレンディング設定を変えて描画できます。

続きを読む


技術書典6の感想など

技術書典6に本を出す側で無事に参加出来たので、今回もその感想を残しておこうと思います。技術書典への頒布側での参加は2度目となります。
前回は、疲れと解放感から感想まとめまでが時間が掛かっていたのですが、今回は後処理で色々と作業をしていて遅れました。

頒布内容の紹介は別ページを参照ください。

やっぱり物理本はいい

今回も前回同様、物理的な本を出す、ということを重要視していました。但し今回は電子版の用意をしてみることにしました。
物理本の印刷関連は前回体験したので、今回のチャレンジは電子版のダウンロードカードをどうするか、といったところでした。

サークル:すらりんラボが採った方法は以下の2つです。

  • 対面電書でのコード発行
  • BOOTHでのパスワードzipの配布

ここまで準備して挑んだのですが、電子版単体としては売れ行きは今ひとつでした。きっと技術書典という場所も関係しているのでしょう、圧倒的に物理本に人気がありました。
物理本が無くなってから、仕方なく電子版で妥協という方も居たのではないかと思います。

ダウンロードカードですが、安価な価格設定でバリアブル印刷可能なところを見つけるのが大変ですね。
シリアルコードを自分のプリンタでシールラベル印刷して、カードに貼る形式も最悪ケースで考えていましたが、色々と考えると BOOTH でのパスワード zip の配布が一番手軽だと思います。
手軽な方法が採れるということは、コストを抑えられるので物理本のオプションで電子版を付けられる!ということにも繋がります。今回バリアブル印刷でコストを掛けてしまったため、別料金を頂く形になってしまいました。これがさらに問題に繋がったわけですが・・・後ほど。

続きを読む


VisualStudio2019 オフラインインストール準備

Visual Studio 2019 が公開されました!
とりあえずインストールをと思いつつも、今は時間がないのでオフラインインストール出来るように仕掛けてみました。

Visual Studio 2019 のインストーラーファイルを取得した後で、コマンドラインで、 “vs_professional.exe –layout D:\VS2019Ja –lang ja-JP” と打ち込んでファイルを収集させてみました。
この方法は従来通りで変わっておらず、うまく動き出しているようです。


技術書典6に向けて追い込み中です

今週の初めに告知したように、技術書典6へ参加してきます。
DirectX12 や Vulkan の入門書籍を今回は用意しました。
一緒に参加する相棒は3Dオーディオ入門という書籍を書き上げてくれました。

・・・というより、みんな最後の締め間際の追い込み作業中です。

すらりんラボは技術書典6に参加します

なかなかブログ更新出来ていない点がありますが、その分これらの冊子に力を入れたので、是非見てもらえたらと思います。


RDPでGraphicsAPIは実行出来るか実験

前回、RDP で OpenGL アプリを起動させる方法を考えましたが、そもそも他のグラフィックスAPIではどうなのか、気になってきたので調べてみました。

RDP で動作するか?

  • OpenGL : 動作しない
  • DirectX11 : 動作する
  • DirectX12 : 動作する
  • Vulkan : 動作する

まさかの OpenGL だけが動作しないという状況だったようです。確認したのは、2台とも Windows10 1809 の環境で、デスクトップPCとノートPCという構成でした。
低レイヤーグラフィックスAPIのDirectX12/Vulkan らが RDP 経由でも使えたという点で驚きました。画面を単なる画像として送るなら、これらの動作に納得もあるのですが、かつては DirectX9 や OpenGL がリモートデスクトップ環境下で動かなかった時代を味わったために動作しないという思い込みがあったようです。

プログラムコードで考えてみると、デバイスコンテキストが不要な API だと動作しているようですね。あとは、画面ロック・UACの暗転でいわゆるデバイスロストが発生しない時代になってきたから、というのもありそうです。


リモートデスクトップで OpenGL アプリを操作したい

Windows のリモートデスクトップで OpenGL を使用したアプリケーションの起動は出来ないことは、経験上知っていたのですが、OpenGL アプリを起動した状態で、リモートデスクトップ接続すると問題なくアプリが使用できる、という話を聞きました。

RDP接続後にOpenGLアプリを起動したい

事前にOpenGLアプリを起動した状態で、他の端末から RDP で接続すれば問題なくアプリは操作できますが、事前に起動しておくことが不可能な時もあります。
また、アプリケーションを終了してしまって、再度起動したいということもあると思います。

このようなときには、 tscon コマンドを使うとよいようです。
このコマンドを用いるとセッションを切り替えることができるようなので、一度物理的なコンソールを持つセッションに切り替えてアプリケーションの起動をする、という方法が使えます。このときに、一度リモートデスクトップは切断されてしまいますが、再接続すればアプリケーションが起動した状態から再開できます。

アプリケーションの起動をするまでを次のような内容でバッチファイルにして、起動する際にはこのバッチファイルを実行するようにします。

実行する際には、管理者権限ありのコマンドプロンプトで実行してうまくいきました。一般権限のコマンドプロンプトだと、このままのバッチではうまく動作しない可能性があります。

他にもセッションのIDが必要な場面では、 “query session” を実行してみて、どのようなセッションが生きているかを見てみるのもよさそうに思います。


VisualStudio の HLSL テンプレートがおかしい その2

以前に、 VisualStudio の HLSL テンプレートがおかしい として、修正したシェーダー用のプロジェクトテンプレートですが、 Visual Studio 2017 の更新をしたら、また妙な状況になってしまったようです。
もしかすると、先の手作業の修正が引き金で新規にインストールした場合には、おかしな構造ながらも正常に動くのかもしれません。

続きを読む