Оптимальный доступ к памяти при использовании справочных таблиц на GPU?

Я изучаю изоповерхностные алгоритмы на графическом процессоре для проекта бакалавра (особенно концентрируясь только на двоичных входных / выходных данных вокселей, а не на полях с действительными значениями). Итак, у меня есть реализация CPU старых добрых марширующих кубов, запущенная в OpenFrameworks, и сейчас на стадии попытки перенести ее на вычислительные шейдеры GLSL и рассмотреть подводные камни перед тем, как погрузиться в нее. Я написал только vert и frag шейдеры раньше, так что для меня все это ново.

Моя первая проблема заключается в том, как эффективно использовать справочную таблицу для десятков или сотен потоков в рабочей группе? Я понимаю, что у GPU есть разные виды памяти для разных задач, но я не совсем уверен в том, как они работают или какой тип использовать.

Классическая таблица copypasta Пола Бурка представляет собой массив размером 256 * 16, поэтому при использовании скалярного байтового типа он может быть упакован в текстуру 4 КБ или SSBO.

Вопрос в том, как не допустить, чтобы разные потоки сбивали друг друга? Многие кубы в каждой рабочей группе потенциально могут иметь одинаковую конфигурацию, поэтому пытаются получить доступ к одному и тому же месту в буфере в одно и то же время. Есть ли обходной путь или оптимизация для решения этой проблемы?

Лучшее место для размещения справочной таблицы для вычислительного шейдера на GPU зависит от размера справочной таблицы и частоты / согласованности доступа. В вашем случае (вы упомянули 4 КБ) лучше всего использовать совместно используемую локальную память (при условии, что вам не нужна эта память для других целей в том же ядре). Эта память имеет разные имена в разных API, но является одной и той же архитектурной особенностью и соответствует одним и тем же рекомендациям по производительности:

• CUDA: общая память потоковой группы
• DirectCompute: групповая память
• OpenCL: локальная память
• Металл: нить памяти группы
• OpenGL: общая память

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

Обратите внимание, что я предполагаю, что это справочная таблица только для чтения. Таблица поиска для чтения и записи - это совершенно другой зверь, и у вас там нет хороших вариантов.