2

そこで、Vulkan プログラミングを簡単にするライブラリを作りたいと思っていました。Githubで見ることができますが、すぐに何か大きなものを期待しないでください ;)。すべてのレイヤープロパティを返す関数を作成したいと思いgetInstanceLayerPropertiesます(明らかに)。これは遅くなる可能性があるため、最適化したいと考えました。私の考えは単純です。事前に計算された配列として保存します。私が知る必要があるのは、ランタイム中に Vulkan レイヤーを変更できるかどうかだけです。たとえば、 の値をキャッシュしたとしますvkEnumerateInstanceLayerProperties。新しいレイヤー プロパティを削除、追加、または変更して、その関数を再度呼び出した場合に別の結果が得られるようにすることはできますか?

4

2 に答える 2

5

vkEnumerate*Properties は、呼び出しが行われた時点でのシステムの状態に関する情報を返します。仕様を書いていた私たちにはそれはかなり明白に思えましたが、Vulkan を初めて使用する人にとってはそれほど明白ではないかもしれないことがわかります.

レイヤーは Vulkan の外部で定義されるため、時間の経過とともに変化する可能性があります。可能性は低いですが、可能です。これが、これらの呼び出しが VK_INCOMPLETE を返す理由の 1 つです。典型的な使用法は、最初に呼び出しを行ってカウントを取得し、結果にスペースを割り当ててからデータを取得することです。これらの 2 つの呼び出しの間にリストが大きくなった場合、アプリは VK_INCOMPLETE を確認し、何かが変更されたことを認識します。

于 2016-07-12T14:09:15.940 に答える
1

まず第一に、これはコードを最適化しない完璧な方法であることに注意してください。それはそうではなく、意味論的にもホットスポットになることはできません。
古いインスタンス/デバイスを破棄して新しいインスタンス/デバイスを作成しない限り、キャッシュされた情報を利用することさえできません。

今答えます：

仕様上、結果の無効化を明示的に防止するステートメントはありません。

UPDATE2: したがって、これらはいつでも変更される可能性があります。それはまれでしょうが。唯一の決定的な結果は、どちらvkCreateInstance()が返さVK_SUCCESSれるかVK_ERROR_LAYER_NOT_PRESENTです。

（実際には、すべてのvkGet*andvkEnumerate*コマンドが結果の不変性の性質を述べていないのがちょっと嫌いです。しかし、それをGitHubの問題として提起するのを少し忘れていました...更新2：もう一度忘れる前に、今それをしました）

それを行う実装に関するコードは、オープン ソースにする必要があります。これは、公式の「The Loader」の一部である必要があります (LunarG SDK の一部でもあります)。後で調べるかもしれません。ただし、新しいレイヤーのセットがレジストリから毎回読み取られると想定するのは合理的ですが (Windows の場合)。確かに、彼らはその動作を変更することを決定する可能性があるため、とにかく役に立たない情報です。

更新:私はそれをすばやくスキャンしましたが、実際には、次の呼び出しごとにレイヤーが新たにスキャンされているようですvkEnumerateInstanceLayerProperties:

于 2016-07-10T21:11:54.723 に答える