в OpenCL оптимальный размер группы

Я ответил на аналогичный вопрос здесь что вы можете найти интересным, прежде чем читать следующее.

почему производительность резко снижается, когда я использую 16 строк в группе?

На самом деле он уже ухудшается при использовании 12 строк. Доступ к памяти работает по сделке. Транзакция будет получать определенное количество байтов за один снимок. Теперь, если несколько workitems пытаются получить доступ к нескольким смежным элементам в массиве, это означает, что одна транзакция может достаточно, чтобы служить им всем.

потому что вы получаете доступ к памяти таким образом:

output[get_global_id(0) * get_global_size(1) + get_global_id(1)] = out;

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

таким образом, в случае 12/16 строк, у вас, по крайней мере, 12/16 необходимых операций. Это приведет к твоему второму вопрос:

почему я получаю плохую производительность с 1x48?

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

но здесь возникает проблема холостого хода потоков. Информация, которую вы получили относительно 48 ядер на SM, неверна, как уже указывали другие. Потоки выполняются в группе (называемой warp для NVIDIA) 32 на оборудовании NVIDIA. Эти группы называются wavefront и может быть до 64 потоков для AMD. Поскольку в этом случае рабочая группа состоит из 48 потоков (1 на 48), это означает, что 64 потока запланированы. Это всегда несколько потоков, кратных 32, которые запланированы, потому что вы не можете выполнить часть деформации.

поэтому в этом случае у вас есть четвертая часть потоков, которые ничего не делают. И на самом деле, когда вы сравниваете с результатом, который вы получили для 2x32 (все еще 64 потоков - 2 искривления, но полностью используется) 321 MPixel/s в значительной степени 3/4 из 424 MPixel/s.

стоит отметить и такой результат:2x48: 523 MPixel/s. В этом случае размер рабочей группы 96 кратен 32. Так что никаких холостых потоков.

почему на небесах я получаю максимальную производительность с 3x32, 4x32 и 8x32?!?

ну, ответ приходит из двух предыдущих: вы используете несколько 32, и вы держите количество потоков в измерении 0 относительно небольшим. Но давайте поближе посмотрим на ваш результаты:

2x32:  424 MPixel/s
3x32:  525 MPixel/s
4x32:  525 MPixel/s
8x32:  520 MPixel/s
16x32: 440 MPixel/s

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

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

Итак, как это работает? Возьмем случай 3x32. У вас есть рабочая группа, состоящая из 3 искривлений. Поскольку они принадлежат к той же рабочей группе, они запланированы на том же SM, что и стандарт OpenCL (если бы это было не так, синхронизация между потоками в рабочей группе была бы невозможна).

первый warp начинает работать, пока он не получит остановите, потому что необходим доступ к памяти. Между тем warp 1 ждет завершения транзакций памяти, warp 2 может начать работать. Поскольку на SM много регистров, SM может легко и быстро переключать контекст для запуска других искривлений. Все переменные warp 1 остаются на регистрах, выделенных warp 1. Затем warp 2 попадает в строку, где требуется доступ к памяти, и останавливается. В этот момент далее готов к запуску warp может начать работать. Это может будьте warp 3, но и warp 1, если его доступ к памяти завершен. В вашем случае кажется, что это warp 3, который работает, так как у вас есть разница между 2x32 и 3x32. В первом случае не хватает искривлений, запланированных для скрытия доступа к памяти, хотя во втором случае есть.

по сути, это влияет также на плохую производительность для размера 1x48 из вопроса 2.

почему PREFERRED_WORK_GROUP_SIZE_MULTIPLE возвращает 32 вместо 48?

уже ответил.

есть ли неэмпирический способ выяснить геометрию для максимальной производительности на любом GPU (ATI/Nvidia/Intel HD), учитывая только то, что я получаю от информационных структур OpenCL?

это как для любых других языков. Когда вы знаете, как это работает под капотом, это помогает вам создать хороший первый код. Но вам все равно придется проверить его и пройти процесс проб и ошибок, чтобы настроить его. Помни, что я только что написал. это лишь малая часть того, что важно для производительности. Запрос некоторой информации из OpenCL в сочетании с хорошим пониманием CPU / GPU, очевидно, поможет... но это все.

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

поэтому продолжайте бенчмаркинг;).