В чем цель нового расширения VK KHR vulkan memory model?
Khronos только что выпустили свое новое расширение модели памяти,но еще предстоит неофициальное обсуждение, пример реализации и т. д. поэтому я запутался в основном подробности.
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model
Что именно пытаются решить эти новые расширения? Они пытаются решить проблемы синхронизации на уровне языка (скажем, удалить обременительные мьютексы в ваш код C++), или это новый и сложный набор функций, чтобы дать вам больше контроля над тем, как GPU имеет дело с синхронизацией внутри?
(спекулятивный вопрос) было бы хорошей идеей изучить и включить эту новую модель в общий случай или эта модель будет применяться только к определенным многопоточным шаблонам и потенциально добавлять накладные расходы?
2 ответов
большинству разработчиков не нужно знать о модели памяти подробно или использовать расширения. Точно так же, как большинству разработчиков C++ не нужно быть близко знакомым с моделью памяти C++ (и это не только из-за x86, это потому, что большинству программ не нужно ничего, кроме надлежащего использования стандартных мьютексов библиотеки).
но модель памяти позволяет определять когерентность памяти вулкана и примитивы синхронизации с гораздо меньшей двусмысленностью - и в некоторых случаи, дополнительная ясность и последовательность. По большей части определения на самом деле не изменились: код, который раньше был свободен от данных, продолжает оставаться свободным от данных. Для нескольких разработчиков, выполняющих расширенную или мелкозернистую синхронизацию, дополнительная точность и ясность позволяет им точно знать, как сделать свои программы без гонки данных без использования дорогостоящей чрезмерно сильной синхронизации.
наконец, при построении модели группа нашла несколько вещей, которые были плохо спроектированные или сломанные ранее (многие из них возвращаются в OpenGL). Теперь они могут точно сказать, что эти вещи делают, независимо от того, полезны они или нет, и построить замены, которые делают то, что было на самом деле предназначено.
расширение объявляет, что эти изменения доступны, но даже более того, как только расширение является окончательным, а не временным, это будет означать, что реализация была проверена, чтобы фактически соответствовать памяти модель.
помимо всего прочего, он обеспечивает тот же вид мелкозернистых гарантий упорядочения памяти для атомарных операций, которые описаны для C++ здесь. Я бы рискнул сказать, что многие, возможно, даже большинство разработчиков PC c++ не очень много знают об этом, потому что архитектура x86 в основном делает заказ памяти излишним.
однако графические процессоры не являются архитектурой x86 и вычислительные операции, выполняемые массово параллельно на ядрах шейдеров GPU, вероятно, могут, а в некоторых случаях должны используйте явные гарантии заказа, чтобы быть действительными при работе с общими наборами данных.
видео - хорошая презентация по атомике и упорядочению, как это относится к C++.