Khronos только что выпустили свое новое расширение модели памяти, но еще не было неофициального обсуждения, примера реализации и т. д., Поэтому я не понимаю основных деталей.
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model
Что именно пытаются решить эти новые расширения? Пытаются ли они решить проблемы синхронизации на уровне языка (например, удалить обременительные мьютексы в вашем коде C++), или это новый и сложный набор функций, которые дают вам больше контроля над тем, как графический процессор обрабатывает внутреннюю синхронизацию?
(Спекулятивный вопрос) Будет ли хорошей идеей изучить и включить эту новую модель в общий случай, или эта модель будет применяться только к определенным многопоточным шаблонам и потенциально может увеличивать накладные расходы?
Среди прочего, он обеспечивает такие же гарантии точного упорядочения памяти для атомарных операций, которые описаны для C++ здесь. Рискну сказать, что многие, возможно, даже большинство разработчиков ПК на C++ на самом деле мало что знают об этом, потому что архитектура x86 в основном делает упорядочение памяти излишним.
Однако графические процессоры не являются архитектурой x86, и вычислительные операции, выполняемые массово параллельно на шейдерных ядрах графического процессора, вероятно, могут, и в некоторых случаях должен использует явные гарантии упорядочения, чтобы быть действительными при работе с общими наборами данных.
Это видео - хорошая презентация по атомике и упорядочиванию применительно к C++.
Большинству разработчиков не нужно подробно разбираться в модели памяти или использовать расширения. Точно так же, как большинству разработчиков C++ не нужно хорошо знать модель памяти C++ (и это не только из-за x86, а потому, что большинству программ не требуется ничего, кроме использования мьютексов стандартной библиотеки соответствующим образом).
Но модель памяти позволяет определять примитивы согласованности и синхронизации памяти Vulkan с гораздо меньшей двусмысленностью, а в некоторых случаях с дополнительной ясностью и согласованностью. По большей части определения на самом деле не изменились: код, в котором раньше не было гонки данных, по-прежнему свободен от гонки данных. Для некоторых разработчиков, выполняющих расширенную или детальную синхронизацию, дополнительная точность и ясность позволяют им точно знать, как избавить свои программы от гонки данных без использования дорогостоящей чрезмерно сильной синхронизации.
Наконец, при построении модели группа обнаружила несколько вещей, которые ранее были плохо спроектированы или сломаны (многие из них полностью вернулись в OpenGL). Теперь они могут точно сказать, что эти вещи делают, независимо от того, полезны они или нет, и создать замены, которые делают то, что на самом деле было задумано.
Расширение объявляет, что эти изменения доступны, но даже более того, если расширение является окончательным, а не предварительным, это будет означать, что реализация была проверена на соответствие модели памяти.
Из любопытства, почему? Для большинства разработчиков это не должно аннулировать то, что они уже делали (и если это произойдет, они, вероятно, все равно столкнутся с проблемами переносимости между реализациями).
Разве нам не нужно использовать разные структуры данных и вызовы API, чтобы использовать это новое расширение? У меня есть высокопараллельный API Vulkan для моего движка с настраиваемым распределителем памяти. Множество мьютексов и прочего (на самом деле типов, защищенных Ada), чтобы убедиться, что все настроено в памяти графического процессора перед использованием.
Нет, единственное изменение API - это структура запроса функции физического устройства, которая сообщает вам, поддерживается ли модель памяти, и если да, то поддерживает ли она область «Устройство» (по сравнению с областью «Очередь» как самой широкой областью). Ничего существенного не должно измениться в вашем коде хоста, если он не был некорректным ранее.
С одной стороны, я рад, что добавляются эти замечательные расширения, но теперь мне нужно провести рефакторинг кода и купить еще одну книгу :(