Occa: Новый макрос квалификатора ядра

Поскольку это похоже на HIP/CUDA/OpenCL, как насчет передачи его в качестве свойства сборки?

  addVectors = device.buildKernel("addVectors.okl",
                                  "addVectors",
                                  "launch_bounds: 1024");

Это было бы хорошо, я думаю.

Я просто столкнулся с этим. Я рад внести свой вклад, но у меня есть вопрос. Знает ли OCCA размеры внутреннего цикла во время JIT?

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

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

Он говорит, что размеры внутренних циклов могут быть переданы в качестве аргументов, т.е. мы не обязательно знаем размеры блоков потоков во время JIT-компиляции.

О верно. Я вижу, что ты сейчас говоришь @tcew. Хорошая точка зрения.

Вот что я имел в виду:

<strong i="6">@kernel</strong> void runtimeArgs(const int B,
                         const int T,
                         const int N,
                         const float *x,
                         const float *y,
                         float *xPy) {
  for (int b=0;b<B;++b;@outer(0)){
    for (int t=0;t<T;++t;@inner(0)){

      if(b==0 && t==0) printf("B=%d, T=%d\n", B, T);

      int  n = t + T*b;
      if(n<N){
        xPy[n] = x[n] + y[n];
      }
    }
  }
}

OCCA, очевидно, не может знать числовые границы цикла во время JIT.

Однако он создает средство запуска, которое устанавливает размеры сетки потоков:

extern "C" void runtimeArgs(occa::modeKernel_t * *deviceKernel,
                            const int & B,
                            const int & T,
                            const int & N,
                            occa::modeMemory_t * x,
                            occa::modeMemory_t * y,
                            occa::modeMemory_t * xPy) {
  {
    occa::dim outer, inner;
    outer.dims = 1;
    inner.dims = 1;
    int b = 0;
    outer[0] = B - 0;
    int t = 0;
    inner[0] = T - 0;
    occa::kernel kernel(deviceKernel[0]);
    kernel.setRunDims(outer, inner);
    kernel(B, T, N, x, y, xPy);
  }
}

Таким образом, пользователь может указать любой размер границ цикла во время выполнения.

Перекрещенные посты.

SYCL использует аналогичный синтаксис:

sycl::range<2> global_range(Bx*Tx,By*Ty);
sycl::range<2> local_range(Tx,Ty);
sycl::nd_range<2> kernel_range(global_range, local_range);

device_queue.submit([&](sycl::handler &cgh) {
    ...
  cgh.parallel_for(kernel_range, kernel);
});

(Буферы имеют связанный с ними диапазон, что позволяет избежать необходимости передавать N)

Синтаксис SYCL sycl::range адаптирован из OpenCL, который сам адаптирован из CUDA.

В вашем примере спецификация размеров потоков отделена от тела параллельных циклов for.

Синтаксис OCCA OKL специально разработан для приведения размеров цикла и основного кода в более знакомый синтаксис параллельного цикла for.

for (int b=0;b<B;++b;@outer(0)){ /*  grid dimension defined here */
    for (int t=0;t<T;++t;@inner(0)){ /* thread block dimension defined here */

      if(b==0 && t==0) printf("B=%d, T=%d\n", B, T);

      int  n = t + T*b;
      if(n<N){
        xPy[n] = x[n] + y[n];
      }
    }
  }

Предполагается, что код внутри ядра удерживает границы параллельного цикла for в непосредственной близости от тела параллельного цикла for. Кроме того, граница цикла не определяется каким-либо входным массивом, поскольку более общее ядро ​​может потребовать совершенно другой конфигурации сетки потоков, чем массивы данных.

Конструкции ядра OKL были преднамеренным выбором, вызванным необходимостью неоднократно объяснять синтаксис ядра CUDA/OpenCL, параметры запуска ядра и философию многопоточности ядра при обучении людей.

Есть ли в SYCL аналогичная подсказка о размере блока потока, как __launch_bounds__ в CUDA/HIP, которую мы здесь обсуждаем?

Хороший вопрос. Я дважды проверил стандарт SYCL (v1.2.1), чтобы выяснить это. Поддерживаются любые атрибуты, доступные в OpenCL C, и их можно задать с помощью спецификатора атрибута C++ 11 с использованием пространства имен cl . Например, __attribute__(((reqd_work_group_size(n))) в OpenCL C эквивалентно [[cl::reqd_work_group_size(n)]] в SYCL.

Существует два варианта указания размера группы потоков: work_group_size_hint(n) — это мягкая версия, предполагающая, что размер группы потоков будет n , тогда как req_work_group_size(n) является строгим требованием. .

Некоторые варианты OCCA:

1. добавьте функцию-член "innerDimHint" в класс occa::kernel, которая вызывает перекомпиляцию (если она еще не в хэше) с подсказкой потока для CUDA/OpenCL/HIP.

2. добавьте некоторую логику внутри средства запуска, чтобы вызвать перекомпиляцию, когда указан новый размер массива потоков. Эта функция может быть включена/выключена некоторыми определениями OCCA_ * .

Оба они могут быть выполнены обратно совместимым способом.

На самом деле я бы доверил управление этим отдельным средам выполнения и предпочел бы ничего не перекомпилировать. По сути, используйте оригинальное предложение @ dmed256 сделать его опорой сборки, а затем добавить соответствующую подсказку __launch_bound__ в ядро ​​​​при переводе, если серверная часть поддерживает это.

Для CUDA и HIP __launch_bound__ на самом деле просто подсказка, поэтому, возможно, больше похоже на work_group_size_hint в OpenCL. Он используется только для того, чтобы сообщить компилятору, сколько регистров, по его предположению, будет доступно каждому потоку в блоке. Если пользователь нарушает границу запуска, это не обязательно ошибка, так как ядро ​​может не активно использовать регистрацию. В случае, когда пользователь нарушает границу запуска и регистра действительно недостаточно, среда выполнения выдаст ошибку, которую должен отловить OCCA.

При запуске автоматического тюнера я заметил ошибки сегментации для ядер OCCA:HIP , которые требовали слишком много LDS или REG. Я скептически относился к тому, что HIP будет выдавать ошибки, которые будут обнаружены. Надеюсь, теперь это исправлено.

Меня устраивает пользовательская подсказка или средство запуска, которое определяет новые конфигурации потоков во время выполнения.

К вашему сведению, я был счастлив как шутка, просто указав явные границы цикла выполнения из кода хоста с помощью подстановки макроконстант в коде ядра OKL (например, K_blockDim для внешнего, K_threadDim для внутреннего), которые я передаю вниз через реквизиты ядра. Конечно, у меня есть собственный код API, который запрашивает характеристики и состояние GPU. Я использую эту информацию для вычисления границ цикла для передачи вниз. Да, такие динамические вещи иногда вызывают повторную компиляцию JIT во время выполнения, но в моем случае это редко, потому что я изменяю пороговое значение шага, поэтому фактические границы цикла обычно остаются неизменными или попадают в какой-то общий набор для данного ядра. Я также использую предварительную компиляцию для некоторых своих ядер, что также уменьшает повторную компиляцию JIT.

Явное определение этих границ цикла во время выполнения также облегчает определение размера массивов локальной памяти графического процессора во время выполнения с их помощью в коде OKL.

Похоже, эта функция будет важна:
https://rocmdocs.amd.com/en/latest/Current_Release_Notes/Current-Release-Notes.html#performance-impact-for-kernel-launch-bound-attribute

Приношу извинения за неуклюжую реализацию, это обходной путь, который я использую для ядра в libparanumal, для которого требуется Np (> 256) потоков:

occa::properties kernelInfo; 
...
 if(platform.device.mode()=="HIP"){
      char newflag[BUFSIZ];
      sprintf(newflag, " --gpu-max-threads-per-block=%d", mesh.Np);
      kernelInfo["compiler_flags"] += newflag;
    }

Использование флага компилятора hipcc для указания границ запуска было предложено Ноэлем Чалмерсом. Грубая реализация моя.

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

Чтобы избежать использования неподходящих ограничений, я создаю отдельные копии объекта occa::properties для ядер, использующих другое максимальное количество потоков.

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