OpenCL векторизация на смежных рабочих элементах

Question

Предположим, у меня есть ядро ​​OpenCL, где каждый рабочий элемент выполняет одну операцию int_32, а мой GPU поддерживает операцию SIMD с 256 битами, сможет ли OpenCL объединить 8 рабочих элементов вместе, чтобы воспользоваться преимуществами SIMD? т.е. один блок обработки выполняет несколько рабочих элементов одновременно. Если да, то когда это произойдет? На этапе «clBuildProgram» или когда бинарный файл фактически выполняется на графическом процессоре (компиляция JIT)?

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

Я посмотрел файл nvidia ptx после «clBuildProgram», и я все еще видел скалярный ИК-порт, но я не уверен в Intel или AMD.

Answer 1

Вообще говоря, если GPU будет выполнять инструкции SIMD для ваших данных, он решит, когда ваш код будет скомпилирован (будь то онлайн-компилятор или автономным компилятором). Вероятно, это не решит, основываясь на том, как/когда вы определяете свои рабочие группы.

Что касается векторизации ваших данных или нет ... Это немного сложнее.

Это зависит от того, как именно вы выложили свои данные и логику вашего ядра, а также о том, насколько оптимизирован ваш (предположительно он-лайн) компилятор. Это ТАКЖЕ сильно зависит от фактического оборудования, но я расскажу об этом через мгновение.

• типы векторные данные (например, float4, int4, float8 и т.д.) являются самыми легкими векторизации, и, вероятно, даже не требуют оптимизации пропуска сделать это, так как код довольно явно говоря «это данные все принадлежат друг другу и, вероятно, будут иметь те же самые операции, которые применяются к нему, поэтому, если у вас есть оборудование, чтобы сделать это(но, как я объясню ниже, это довольно большой «если»)let's используйте инструкции SIMD для этих типов! "
• Скалярные типы данных, вероятно, не будут оптимизированы, если у вас нет действительно умного компилятора. Не каждый компилятор будет работать. «Ну, у вас есть int s i1, i2, i3, i4, и все они имеют те же самые операции, что и к ним, поэтому давайте их SIMD!".
• Скалярные типы данных в рабочих группах почти наверняка не будут векторизованы. Они все равно будут выполняться одновременно (потому что, если нет, то почему, черт возьми, мы даже пишем код GPGPU в первую очередь ????), но компиляторы и среды выполнения почти наверняка не смогут их оптимизировать.
• EDIT: Как указано, существуют Compiler Tricks, которые могут сделать такую ​​возможность векторизации возможной. Но стоит иметь в виду, что эти трюки возникают во время компиляции, а не во время выполнения, что означает, что он сильно зависит от того, как написан код и какой компилятор (и какие флаги оптимизации, если они существуют) используется для компиляции ядра код.

Главное, чтобы все это зависело от аппаратных возможностей вашей карты. По крайней мере, среди вычислительных карт потребительского класса (в переводе: графические процессоры) инженеры-аппаратчики фактически не делают существенных обновлений своих возможностей векторизации, и на самом деле часто предпочитают сокращать векторизацию, чтобы сосредоточиться на создании меньших ядер, которые затем могут уложите больше на чип.Например, у вас есть карта с 128 ядрами, каждая из которых может выполнять 256-битные SIMD-инструкции, но зачастую гораздо проще иметь карту с крошечными ядрами, которые не могут (или могут " t) обрабатывать инструкции SIMD и просто складывать так много ядер (например, на самом последнем запуске NVidia, выше 4k), которые могут запускаться параллельно, выполняя ту же работу (часто быстрее), не завися от того, что программист записывает явные инструкции SIMD.

Я действительно верю (но не цитирую на этом), что и AMD, и NVidia гарантируют 128-битную векторию для float, потому что объекты типа float4 чрезвычайно распространены в графическом программировании, и если вы делаете какие-либо графическая обработка (что является нормой для таких приложений), они значительно выиграют от операций SIMD на таких объектах, но все, что не, вероятно, не увидит каких-либо оптимизаций SIMD.