Поэтому я хотел сделать библиотеку, чтобы упростить программирование на Vulkan. Вы можете увидеть его на Github, но не ждите ничего серьезного в ближайшее время ;). Я хочу создать функцию с именем getInstanceLayerProperties, которая возвращает все свойства слоя (очевидно). Увидев, что это может быть медленнее, я хотел его оптимизировать. Моя идея проста: сохранить его как предварительно вычисленный массив. Все, что мне нужно знать, это: могут ли слои Vulkan меняться во время выполнения. Например, скажем, я кэшировал значения vkEnumerateInstanceLayerProperties. Можно ли удалить, добавить или изменить новые свойства слоя, чтобы при повторном вызове этой функции я получал другие результаты?
Могут ли слои Vulkan изменяться во время выполнения?
Ответы (2)
vkEnumerate*Properties возвращает информацию о состоянии системы на момент выполнения вызова. Это казалось нам довольно очевидным, когда мы писали спецификацию, но я понимаю, что это может быть не так очевидно для тех, кто плохо знаком с Вулканом.
Поскольку слои определены вне Vulkan, они могут меняться со временем. Вряд ли, но могут. Это одна из причин, по которой эти вызовы могут возвращать VK_INCOMPLETE. Типичным использованием было бы сначала сделать вызов, чтобы получить количество, выделить место для результата, а затем получить данные. Если между этими двумя вызовами список расширится, приложение увидит VK_INCOMPLETE и узнает, что что-то изменилось.
person
Courtney Goeltzenleuchter
schedule
12.07.2016
Прежде всего, я хотел бы отметить, что это идеальный способ НЕ оптимизировать код. Это не так, и семантически даже не может быть горячей точкой.
Вы даже не можете использовать кэшированную информацию, если не уничтожите свой старый экземпляр/устройство и не создадите новый.
Теперь ответ:
В спецификации нет утверждений, которые явно предотвращают аннулирование результата.
ОБНОВЛЕНИЕ 2: поэтому они могут измениться в любое время. Хотя это было бы редкостью. Единственным окончательным результатом является то, возвращает ли vkCreateInstance() VK_SUCCESS или VK_ERROR_LAYER_NOT_PRESENT.
(На самом деле мне немного не нравится, что практически все команды vkGet* и vkEnumerate* не указывают характер неизменности своих результатов. Но потом я несколько забыл поднять это как проблему GitHub... ОБНОВЛЕНИЕ 2: сделал это сейчас, пока я снова не забыл)
Код реализации, делающий это, должен быть с открытым исходным кодом. Это должно быть частью официального «Загрузчика» (также являющегося частью LunarG SDK). Я могу исследовать позже. Хотя разумно предположить, что новый набор слоев считывается каждый раз из реестра (то есть в Windows). По общему признанию, это в любом случае бесполезная информация, поскольку они могут решить изменить свое поведение.
ОБНОВЛЕНИЕ: я только что отсканировал его только быстро, но действительно кажется, что слои сканируются заново при каждом вызове vkEnumerateInstanceLayerProperties: trampoline.c#L227" rel="nofollow">https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/74d013a5438f47a66a77d5375d1cdeef3f0beca7/loader/trampoline.c#L227
person
krOoze
schedule
10.07.2016
Я думаю, что первая часть вашего ответа неверна. Вызов
vkEnumerateInstanceLayerProperties, а также vkEnumerateInstanceExtensionProperties полностью не зависит от какого-либо отдельного экземпляра и происходит до создания экземпляров. Весь смысл этих функций заключается в том, чтобы увидеть, можете ли вы создать экземпляр с этими определенными слоями/расширениями!
- person Jerfov2; 11.07.2016
Как это неправильно? Есть ли такие утверждения в спецификации? Никогда ничего не заявлял об общей причине/ожиданиях того, как они должны себя вести,
- person krOoze; 11.07.2016
Или вы имеете в виду часть перед ответом. Сразу скажу, что оптимизировать нечего. Перечисление должно выполняться только один раз при создании экземпляра/устройства... (конечно, перед созданием)
- person krOoze; 11.07.2016
Почему вы хотите вызывать их один раз при создании экземпляра? Как я уже говорил, эти две функции не зависят от какого-либо одного экземпляра, что означает, что слои и их последующие миры расширений остаются одинаковыми для разных творений (при условии, что слои не меняются во время выполнения). Следовательно, в идеале вы хотели бы вызвать их только один раз, потому что, как только вы получите информацию, вам не нужно снова ставить ее в очередь. (Все еще предполагая, что слои не меняются). Я спрашиваю, верно ли это предположение. P.S. Судя по вашему редактированию, свойства слоя ставятся в очередь при каждом вызове.
- person Jerfov2; 11.07.2016
Вопрос в том, почему вы хотите вызывать их более одного раза (и, следовательно, иметь разумную потребность в их оптимизации). ;; Ваше второе утверждение является тавтологией (не меняйте, предполагая, что они этого не делают) - кроме того, (не)зависимость от экземпляра не имеет отношения к этому. ;; Перефразируя, в идеале вы должны сделать это на ассемблере. Не значит, что это разумно. В вашем случае в среднем вы экономите 0 ЦП за счет некоторой памяти. И это даже не имеет значения, потому что это не команда точки доступа. ;; В Windows слои перечислены в реестре (что указывает на некоторые файлы json). Если я не прочитал код неправильно, они могут измениться.
- person krOoze; 11.07.2016
Как грустно @krOoze, в спецификации нет утверждений, которые явно предотвращают аннулирование результата. Я предполагаю, что вы не планируете сохранять эти данные на диске, так как они могут запускаться один или несколько раз за запуск приложения. Вы должны реализовать его, когда ваша библиотека станет зрелой и когда эта функция может показаться необходимой. У вас есть много работы для реализации других более приятных функций, таких как устранение двойных вызовов Vulkan, как я предложил Здесь. Удачи!
- person Alex Byrth; 11.07.2016
@AlexByrth На самом деле я уже объединил эти вызовы в один хороший, удобный вызов! Но теперь мне было интересно, должен ли я кэшировать этот результат. (Я знаю, что не знаю, из-за krOoze и Кортни
- person Jerfov2; 13.07.2016
