#graphics #gpu #render #vulkan
Вопрос:
Рассматривая буферы, видимые хостом (в основном связанные с буферами потоковой передачи, т. Е. буферами, поддерживаемыми VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT памятью), давайте представим следующую схему использования:
- Запишите новые данные на сопоставленный адрес на хосте (после надлежащей синхронизации).
- Прочитайте буфер с содержимым, записанным на шаге 1 в семействе очередей A.
- Запишите новые данные на сопоставленный адрес на хосте (после надлежащей синхронизации).
- Прочитайте буфер с содержимым, записанным на шаге 3 в семействе очередей B.
Теперь, если я опущу передачу права собственности на семейство очередей (QFOT), будут ли данные, записанные на шаге 3, недоступны для семейства очередей B на шаге 4?
Данные , записанные на хосте, становятся видимыми для устройства, когда я отправляю команду(команды) шага 4 с использованием vkQueueSubmit , из-за неявной зависимости памяти от гарантии заказа записи хоста.
Как это работает с различными семействами очередей?
Комментарии:
1. Похоже на менее жестокую версию ХроносгРуппы/Вулкан-Документы#1050 случай 3. В любом случае, достаточно хорошо изученные особенности должны быть прокомментированы в соответствии со спецификацией , чтобы убедиться, что все находятся на одной странице и, возможно, соблюдаются CTS.
2. @krOoze В любом случае, рабочим решением может быть (даже требуется QFOT или нет) приобретение права собственности на ресурс в семействе очередей B без QFOT (с использованием буфера в семействе очередей B, вероятно, с фиктивным барьером, влияющим на соответствующий диапазон подресурсов) в отдельном представлении, только между этапами 2 и 3. Затем запишите новые данные на хосте на шаге 3 и, наконец, отправьте шаг 4. Как вы думаете, будет ли достаточно нежданного фиктивного барьера ресурсов, чтобы «украсть» право собственности?
3. Возможно, но у некоторых производителей драйверов может быть другое мнение. Просто спросите Хроноса и решите этот вопрос. Все, в чем я могу быть уверен, — это то, что запись делает свое дело (даже если даже этот случай не так хорошо сформулирован в спецификации). То, что записи хоста направляются в следующую очередь первого использования, кажется относительно разумным; надеюсь, вы даже сможете решить эту проблему таким образом с помощью разработчиков спецификаций. (Это, по крайней
VK_IMAGE_LAYOUT_PREINITIALIZEDмере, так работает, кстати).4. @krOoze Разрешит это Хроносом, просто ради любопытства. На самом деле использование
VK_SHARING_MODE_CONCURRENTдля буферов может быть лучшим решением этой проблемы, так как кто-то сказал мне, что параллельный режим (в отличие от изображений) ничего не делает для буферов, по крайней мере, в известных реализациях с открытым исходным кодом, так что это было бы более эффективным, чем дополнительное требование ожидания семафора в моем предлагаемом решении.
Ответ №1:
Итак, у нас есть буфер, изменяемый процессором. И по какой-то причине этот буфер был создан в эксклюзивном режиме. И вы хотите сделать следующее:
- Запишите данные в буфер.
- Скопируйте данные с помощью семейства очередей A.
- Запишите данные в буфер.
- Скопируйте данные с помощью семейства очередей B.
Для того, чтобы шаг 4 сработал, вам необходимо выполнить передачу права собственности. В стандарте это прописано прямо перед тем, что вы процитировали:
Если зависимости памяти правильно выражены между использованием такого ресурса между двумя очередями в разных семействах, но передача прав собственности не определена, содержимое этого ресурса не определено для любых обращений на чтение, выполняемых вторым семейством очередей.
У вас действительно есть правильно выраженные зависимости (я предполагаю). Но копирование данных-это «доступ для чтения». И это выполняется семейством очередей B, которое отличается от семейства очередей A. Поэтому шаг 4 («доступ для чтения») запускает это предложение: «содержимое этого ресурса не определено».
«Содержимое» означает все содержимое. Те, которые вы написали на шаге 1 и шаге 3. Все они не определены для шага 4, если только вы не передадите семейную собственность очереди.
Комментарии:
1. Что ж, это не очень хорошая новость для меня. Хотел избежать подисточниковых QFOTs огромных буферов потоковой передачи. Кроме того, не нужно разделять доступные 256 МБ потоковой памяти AMD между различными типами очередей, чтобы обеспечить выделенный огромный буфер потоковой передачи для каждого подходящего семейства очередей, просто чтобы избежать QFOT, но все равно с точки зрения производительности это лучшее решение, если вы хотите использовать потоковую передачу как на выделенных графических, так и на вычислительных семействах очередей.
2. Я думаю, что отправки фиктивного или неоперативного барьера буферной памяти в новом семействе очередей достаточно, чтобы украсть права собственности у предыдущего семейства очередей, так как вы начинаете использовать буфер в новом семействе очередей, что запускает миграцию прав собственности (конечно, предыдущее содержимое становится неопределенным, но кого это волнует). Затем хост может записать новые данные на сопоставленный адрес, а затем в другой отправке они могут быть прочитаны в новом семействе очередей без каких-либо проблем. Таким образом, вам не придется оплачивать стоимость QFOT.
3. @plasmacel: » Кроме того, я не хочу разделять доступные 256 МБ потоковой памяти AMD между различными типами очередей «. Вы не должны использовать это в качестве исходных данных для копий . Вы должны записать его на центральный процессор и использовать его непосредственно с помощью какой-либо операции с графическим процессором. Вот почему он помечен как «локальное устройство». Если вы не можете использовать эту память для какой-либо конкретной операции с графическим процессором, вам следует просто выполнить DMA из другого хранилища. Эти 256 МБ предназначены для потоковой передачи данных ЦП, которые вы хотите использовать, а не копировать.
4. Вы можете избежать любых затрат на передачу прав собственности, избегая использования одних и тех же буферов потоковой передачи для разных очередей. Или просто не использовать эксклюзивный флаг в этих буферах. Если вам нужно разместить несколько семейств очередей, я не знаю, зачем вам понадобился эксклюзивный буфер.
5. Это другой сценарий для буферов потоковой передачи, а не промежуточных буферов. Их использование отличается (косвенное и прямое), но проблема передачи семейного владения очередью и записи на хост одинаковы. Случай промежуточных буферов только лучше, потому что их практическое использование позволяет использовать их только в одном семействе очередей, которое выбрано для передачи (и на основе выбора может быть или не быть унифицировано с графической/вычислительной очередью). Я не смешиваю понятия промежуточных и потоковых буферов/памяти. Тем не менее, теоретическая проблема остается той же самой.