Какова цель нового расширения Vulkan VK_KHR_vulkan_memory_model? - PullRequest
0 голосов
/ 13 сентября 2018

Khronos только что выпустили свое новое расширение модели памяти, но еще предстоит неформальное обсуждение, пример реализации и т. Д., Поэтому я не совсем понимаю основные детали.

https://www.khronos.org/blog/vulkan-has-just-become-the-worlds-first-graphics-api-with-a-formal-memory-model.-so-what-is-a-memory-model-and-why-should-i-care

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model

Что именно пытаются решить эти новые расширения?Они пытаются решить проблемы синхронизации на уровне языка (например, удалить обременительные мьютексы в вашем коде C ++), или это новый и сложный набор функций, который дает вам больший контроль над тем, как графический процессор обрабатывает внутреннюю синхронизацию?

(Спекулятивный вопрос) Было бы хорошей идеей изучить и включить эту новую модель в общий случай, или эта модель будет применяться только к определенным многопоточным шаблонам и потенциально может увеличить накладные расходы?

Ответы [ 2 ]

0 голосов
/ 14 сентября 2018

Большинству разработчиков не нужно подробно знать о модели памяти или использовать расширения.Точно так же, как большинству разработчиков C ++ не нужно быть близко знакомыми с моделью памяти C ++ (и это не только из-за x86, но и потому, что большинству программ не нужно ничего, кроме использования соответствующих мьютексов стандартной библиотеки).

Но модель памяти позволяет задавать примитивы когерентности и синхронизации памяти Vulkan с гораздо меньшей неопределенностью, а в некоторых случаях - с дополнительной ясностью и согласованностью.По большей части определения на самом деле не изменились: код, который раньше был свободен от гонки данных, продолжает оставаться свободным от гонки данных.Для немногих разработчиков, выполняющих расширенную или детальную синхронизацию, дополнительная точность и ясность позволяют им точно знать, как сделать свои программы свободными от гонки данных без использования дорогой чрезмерно сильной синхронизации.

Наконец, в сборкеВ модели группа обнаружила несколько вещей, которые были плохо спроектированы или сломаны ранее (многие из них возвращались в OpenGL).Теперь они могут точно сказать, что эти вещи делают, независимо от того, являются ли они полезными или нет, и создавать замены, которые делают то, что было на самом деле.

Расширение объявляет, что эти изменения доступны, но дажеБолее того, если расширение является окончательным, а не предварительным, это будет означать, что реализация была проверена на соответствие модели памяти.

0 голосов
/ 13 сентября 2018

Помимо всего прочего, он обеспечивает те же самые гарантии точного упорядочения памяти для атомарных операций, которые описаны для C ++ здесь .Рискну сказать, что многие, возможно, даже большинство разработчиков на C ++ мало что знают об этом, потому что архитектура x86 делает упорядочивание памяти излишним.

Тем не менее, графические процессоры не являются архитектурой x86, и вычислительные операции, выполняемые массивно параллельно на шейдерных ядрах графического процессора, возможно, и в некоторых случаях должен использовать явные гарантии упорядочения, чтобы быть действительными при работе с общими наборами данных,

Это видео является хорошей презентацией по атомарности и упорядочению в применении к C ++.

...