私は、Vulkanプログラミングを簡単にするライブラリを作りたがっていました。あなたはGithubでそれを見ることができますが、すぐに大きなものは期待しません。私はすべてのレイヤプロパティ（明らかに）を返すgetInstanceLayerPropertiesという関数を作りたいと思います。これが遅くなる可能性があることを見て、私はそれを最適化したかったのです。私の考えは単純です：あらかじめ計算された配列として保存してください。私が知る必要があるのは、実行時にVulkanレイヤーが変わることができることです。たとえば、vkEnumerateInstanceLayerPropertiesの値をキャッシュしたとします。新しいレイヤーのプロパティを削除、追加、変更することができますので、その関数を再度呼び出すと別の結果が得られますか？Vulkan Layersは実行時に変更できますか？
それが存在するようvkEnumerate *プロパティは、システムの状態に関する情報を返します呼び出しが行われた時点で。私たちが仕様書を書いていたとき、それは私たちにはかなりわかりましたが、Vulkanを初めて使う人にとってはそれがどういうものか分かりません。
層はバルカンの外部で定義されているように、それらは時間の経過とともに変化させることができます。そうは思わないが、そうすることができる。これは、これらの呼び出しがVK_INCOMPLETEを返すことができる理由の1つです。典型的な使い方は、最初に呼び出しを行ってカウントを取得し、結果のスペースを割り当ててからデータを取得することです。これらの2つの呼び出しの間にリストが成長した場合、アプリケーションはVK_INCOMPLETEを見て何かが変更されたことを知ります。
まず第一に、私はこのコードを最適化しないように最適な方法であることに注意します。それは意味がなくてもホットスポットにはなり得ません。
古いインスタンス/デバイスを破棄して新しいインスタンス/デバイスを作成しない限り、キャッシュされた情報を使用することはできません。
スペックごとに明示的結果の無効化を防ぐために文がありません：今答える
。
アップデート2：したがって、これらのがいつでも変更されることがあります。それはまれです。確定した結果は、vkCreateInstance()はVK_SUCCESSまたはVK_ERROR_LAYER_NOT_PRESENTです。
（実際に私はちょっと実質的にすべてのvkGet*とvkEnumerate*コマンドはその結果の不変の性質を述べていないこと、嫌いしかし、私はややGitHubの問題...アップデート2としてそれを上げるのを忘れ：。ということでした今、前に私はそれをやって
実装ワイズコードはオープンソースでなければなりません）、再び忘れています。これは公式のThe Loader（LunarG SDKの一部でもあります）の一部である必要があります。私は後で調査するかもしれない。レジストリから毎回レイヤの新しいセットが読み込まれると仮定することは合理的です（Windows上では、そうです）。確かに、それはとにかくそれらの行動を変更することを決定するかもしれないので、やや役に立たない情報です。
UPDATE：私はちょうどだけすぐにそれをスキャンしますが、確かに層がvkEnumerateInstanceLayerPropertiesの呼び出しごとに新たにスキャンされそうです： https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/74d013a5438f47a66a77d5375d1cdeef3f0beca7/loader/trampoline.c#L227
あなたの答えの最初の部分は間違っていると思います。 'vkEnumerateInstanceLayerProperties'と' vkEnumerateInstanceExtensionProperties'を呼び出すことは、単一のインスタンスから完全に独立しており、インスタンスが作成される前に行われます。それらの機能の全体的なポイントは、それらの特定のレイヤー/拡張子を持つインスタンスを作成できるかどうかも分かりません！ – Jerfov2
どのように間違っていますか？実際、このような記述が仕様に含まれていますか？ "共通の理由" /彼らがどう振るべきであるかの期待について何も主張していない、 – krOoze
または "前の答え"の部分を意味する。ただ、最適化するものは何もないと言っています。列挙は、インスタンス/デバイスの作成ごとに1回だけ行われるはずです...（もちろん**作成前**） – krOoze