問題タブ [vulkan]

全体vkDeviceMemoryが ( 経由で) マップされ、vkMapMemoryで割り当てられていない場合は、デバイスが書き込みを確認できるように、バッファーへの変更が行われた後に行う必要があります (ドキュメントに従って)。VK_MEMORY_PROPERTY_HOST_COHERENT_BITvkFlushMappedMemoryRanges

大きなバッファーの小さなセクションのみを変更しているため、影響を受ける領域のみをフラッシュしたいと考えています。したがって、さまざまなとフィールドを使用して複数のVkMappedMemoryRange構造を作成しますが、同じ を指します。これはすべて、期待どおりに機能するようです。ただし、有効にすると、エラーが発生します。offsetsizevkDeviceMemoryVK_LAYER_LUNARG_threading

代わりに、配列ではなく単一のフラッシュ範囲のみを使用して複数回呼び出すとvkFlushMappedMemoryRanges、エラーは発生しません。同じバッファの複数のサブ範囲をフラッシュすることは有効なユースケースではありませんか?

Vulkan 1.0 仕様書、chapter.5(Command Buffers) 4 番目の段落を引用すると、

「特に指定されていない限り、また明示的な同期がなければ、コマンド バッファーを介してキューに送信されたさまざまなコマンドは、相互に関連する任意の順序で、および/または同時に実行される可能性があります。」

章 2.1.1 (キュー操作) の第 1 段落では、次のようにも述べています。

「...単一のキューに送信されたコマンド バッファーは、送信された順序で再生され、各バッファー内のコマンドは、記録された順序で再生されます」

第 5 章の「任意の順序」は、順不同でさえ意味しますか? では、2.1.1 章の「提出された順に再生する」という記述に抵触しませんか? または、コマンドは順番どおりに「PLAYED BACK」されますが、「EXECUTED」は順不同ですか？

現在、Visual Studio で Vulkan のデバッグ レイヤー dll を使用するように強制しようとしていますが、ライブラリを読み込めません。私の手順は次のとおりです。

1. クローンhttps://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/BUILD.md
2. Visual Studio 2015 用のビルド (リリースおよびデバッグ)
3. 私のVulkanアプリケーションでは、これを環境変数に入れました（x64の場合-デバッグ）（プロジェクト設定->デバッグ）：VK_LAYER_PATH=F:\Projects\Vulkan-LoaderAndValidationLayers\build\layers\Debug

アプリケーションを起動すると、インスタンスを作成しようとするまで実行され、インスタンスが返さVK_ERROR_LAYER_NOT_PRESENTれ、Visual Studio の出力ウィンドウで dll がまったく読み込まれていないことがわかります。上記のパスにVulkanバイナリへの「通常の」パスを入れるだけで、再び正常に動作します。.json ファイルも存在することを確認しました。この問題は、LoaderAndValidationLayers フォルダーからリリース DLL を使用しようとした場合にも発生します。

私は何を間違っていますか？これを機能させる方法を知っている人はいますか？

編集：それが問題のようであることがわかりましたVK_LAYER_LUNARG_threading。使用VK_LAYER_LUNARG_standard_validationしても何もロードされません。含まれているすべてのレイヤーを手動で指定するだけで (ここで説明: https://vulkan.lunarg.com/app/docs/v1.0.3.1/layers )、VK_LAYER_LUNARG_threadingレイヤーなしで正常に動作します。なぜこれが考えられるのでしょうか？

過去 2 週間、Vulkan を使用していますが、AMD カードでのみ発生する問題に遭遇しました。具体的には AMD 7970M です。プロジェクトを GTX 700 および 900 シリーズのカードで問題なく実行しました。Nvidiaカードを搭載したWindowsとLinux（Steam OS）でも問題なく実行しました。この問題は、AMD カードと私のプロジェクトでのみ発生します。Sascha Willemsのすべてのサンプルとプロジェクトは問題なく動作します。

現在、テクスチャ付きのラプター モデルを描いて、その場で回転させています。それをテクスチャにレンダリングし、そのテクスチャをフルスクリーンの三角形に適用します。基本的なオフスクリーン レンダリング。しかし、7970M では深度が正しくクリアされないようです。代わりに、深度が適切にクリアされていないような、この奇妙なアーティファクトが発生します。

もちろん、RenderDoc でこれを掘り下げてみましたが、その深さは完全に間違っています。ラプターとそれが描かれたフルスクリーンの三角形の両方がめちゃくちゃです:

私のコードを Sascha Willems の Offscreen の例と比較してみましたが、ほぼすべて同じ方法で行っているようです。深さを作成する方法に何か問題があるのではないかと思いましたが、私が見たすべての例と比較すると問題ないようです。

深度画像とビューを作成している場所のデバッグ ビューを次に示します。

メソッド全体は次のとおりです。

コードに関する詳細情報が必要な場合は、お気軽にお問い合わせください。提供します。このプロジェクトにはたくさんのコード行があるので、すべての人にすべてを苦労させたくありません。必要に応じて、すべてのコードをhttp://github.com/thirddegree/HatchitGraphics/tree/devで見つけることができます。

編集：もう少し突っついた後、色でさえ実際には適切にクリアされていないことがわかりました. RenderDoc は、各フレームが猛禽類のカットアウトのみをレンダリングし、フレームの残りの部分をクリアしないことを示しています。これはドライバーの問題ですか？

編集：いくつかの詳細情報。何も描画せず、フルスクリーンの三角形を描画せずにレンダー パスを開始して終了すると、画面がクリアされることがわかりました。ただし、三角形だけを描画すると、深さが正しくありません (オフスクリーンから何もブリットしたり、何らかのテクスチャを適用したりしなくても)。

編集:より具体的には、色はクリアされますが、深さはクリアされません。何も描画しない場合、深度は黒のままです。すべて 0 です。フルスクリーンの三角形が奥行きの奇妙なスタティックを引き起こす理由はわかりません。

2D テクスチャ ローダーは、テクスチャの寸法が 2 の累乗であれば問題なく動作しますが、そうでない場合は、テクスチャ データが歪んで表示されます。これを修正するにはどうすればよいですか? この問題は、メモリの配置と行のピッチに関係していると思います。私のローダーコードの関連部分は次のとおりです。

列挙型の項目の名前を理解しようとしていますが、VkFormatこれまでのところ、すべての (非ブロック) 形式の名前のすべての構造を取得していると思いますが、それがいつ何を意味するのかわかりませんPACK8、、PACK16の接尾辞が付いていますPACK32。チャネル サイズを合計すると、常に 8、16、または 32 になります。不規則ではありません。したがって、これらの値をビットパックする意味がわかりません。すべてのビット。

いつものように、ドキュメンテーションはあまり役に立ちません。フォーマットがパックされているだけで、それが何を意味するのかは説明されていません。

Vulkan で S3TC (BC/DXT) 圧縮を使用して圧縮画像を読み込もうとしてきましたが、これまでのところうまくいきませんでした。

圧縮された画像に関する Vulkan 仕様の内容は次のとおりです。

https://www.khronos.org/registry/dataformat/specs/1.1/dataformat.1.1.html#S3TC :

S3TC 圧縮画像フォーマットを使用して格納された圧縮テクスチャ画像は、4×4 テクセル ブロックのコレクションとして表されます。各ブロックには、64 ビットまたは 128 ビットのテクセル データが含まれます。画像は、各 4×4 ブロックが 1 つのピクセルとして扱われる通常の 2D ラスター画像としてエンコードされます。

https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#resources-images :

線形タイリングで作成された画像の場合、rowPitch、arrayPitch、および depthPitch は、線形メモリ内のサブリソースのレイアウトを記述します。非圧縮形式の場合、rowPitch は、隣接する行で同じ x 座標を持つテクセル間のバイト数です (y 座標は 1 異なります)。arrayPitch は、イメージの隣接する配列レイヤーで同じ x 座標と y 座標を持つテクセル間のバイト数です (配列レイヤーの値は 1 異なります)。depthPitch は、3D イメージの隣接するスライスで同じ x 座標と y 座標を持つテクセル間のバイト数です (z 座標は 1 異なります)。サブリソース内のテクセルの開始バイトには、アドレス指定式として表現された次のアドレスがあります。

// (x,y,z,layer) はテクセル座標です

address(x,y,z,layer) = 層配列ピッチ + z深さピッチ + y行ピッチ + x texelSize + オフセット

圧縮形式の場合、rowPitch は隣接する行の圧縮ブロック間のバイト数です。arrayPitch は、隣接する配列層のブロック間のバイト数です。depthPitch は、3D イメージの隣接するスライスのブロック間のバイト数です。

// (x,y,z,layer) はブロック座標です

address(x,y,z,layer) = レイヤーarrayPitch + z depthPitch + y rowPitch + x blockSize + オフセット;

arrayPitch は、配列として作成されていない画像では未定義です。depthPitch は 3D 画像に対してのみ定義されます。

カラー形式の場合、VkImageSubresource のアスペクトマスク メンバーは VK_IMAGE_ASPECT_COLOR_BIT である必要があります。深度/ステンシル形式の場合、アスペクトは VK_IMAGE_ASPECT_DEPTH_BIT または VK_IMAGE_ASPECT_STENCIL_BIT のいずれかでなければなりません。深度とステンシルのアスペクトを別々に格納する実装では、これらのサブリソース レイアウトのそれぞれをクエリすると、そのアスペクトに使用されるメモリの領域を表す異なるオフセットとサイズが返されます。深度とステンシルのアスペクトをインターリーブして格納する実装では、同じオフセットとサイズが返され、インターリーブされたメモリ割り当てを表します。

私の画像は通常の 2D 画像 (0 レイヤー、1 ミップマップ) であるため、arrayPitchまたはdepthPitchはありません。S3TC 圧縮はハードウェアで直接サポートされているため、最初に解凍せずに画像データを使用できるはずです。OpenGL では、これはglCompressedTexImage2Dを使用して実行できます。これは過去に私にとってはうまくいきました。

OpenGL では、画像フォーマットとして GL_COMPRESSED_RGBA_S3TC_DXT1_EXT を使用しました。Vulkan では、同等の VK_FORMAT_BC1_RGBA_UNORM_BLOCK を使用しています。画像データをマッピングするための私のコードは次のとおりです。

イメージを初期化するコードは次のとおりです。

コードは問題なく実行されますが、結果の画像は正しくありません。これはソース画像です：

そして、これは結果です：

問題は私が投稿した最初のコードにあると確信していますが、そうでない場合に備えて、Vulkan SDK の三角形のデモの小さな適応を作成しました。これにより、同じ結果が得られます。ここからダウンロードできます。ソースコードが含まれています。三角形のデモから変更したのは、tri.c の「demo_prepare_texture_image」関数( 803 行目から 903 行目) と、「dds.cpp」ファイルと「dds.h」ファイルだけです。「dds.cpp」には、dds をロードし、イメージ メモリをマッピングするためのコードが含まれています。

上記のダウンロードにも含まれているdds-data（「Vulkanで完全に動作する」はずです）をロードするためにgliを使用しています。プロジェクトをビルドするには、Vulkan SDK インクルード ディレクトリを「tri」プロジェクトに追加し、dds へのパスを変更する必要があります (tri.c、809 行目)。

ソース イメージ (プロジェクト内の「x64/Debug/test.dds」) は DXT1 圧縮を使用します。異なるハードウェアでもテストしましたが、結果は同じでした。

圧縮された画像を初期化/マッピングするためのサンプルコードも大いに役立ちます。