Синхронизация в графических процессорах - PullRequest
7 голосов
/ 13 июля 2011

У меня есть вопрос о том, как графические процессоры выполняют синхронизацию.Как я знаю, когда варп сталкивается с барьером (при условии, что он есть в OpenCL), и он знает, что других варпов той же группы еще не было.Так что это должно подождать.Но что именно делает этот варп во время ожидания?Это все еще активный деформация?Или он будет выполнять какие-то нулевые операции?

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

И, наконец, я сильно удивляюсь, если на количество, добавленное синхронизацией, по сравнению с одним без синхронизации (скажем, барьер (CLK_LOCAL_MEM_FENCE)) влияет количествоДеформация в рабочей группе (или потоковом блоке)?Спасибо

1 Ответ

7 голосов
/ 13 июля 2011

Активная деформация - это та, которая находится на SM, т. Е. Все ресурсы (регистры и т. Д.) Были выделены, и деформация доступна для выполнения при условии, что ее можно запланировать.Если деформация достигает барьера до других деформаций в том же потоке / рабочей группе, она все равно будет активной (она все еще находится на SM, и все ее регистры все еще действительны), но она не будет выполнять никаких инструкций, так как онане готов к планированию.

Вставка барьера не только останавливает выполнение, но и действует как барьер для компилятора: компилятору не разрешается выполнять большинство оптимизаций через барьер, поскольку это может сделать недействительным назначение барьера,Это наиболее вероятная причина, по которой вы видите больше инструкций - без барьера компилятор может выполнять больше оптимизаций.

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

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

...