Occa: 새로운 커널 한정자 매크로

이것은 HIP/CUDA/OpenCL에만 해당되는 것이므로 빌드 속성으로 전달하는 것은 어떻습니까?

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

좋은 것 같아요.

나는 방금 이것에 부딪쳤다. 기여하게 되어 기쁩니다. 하지만 질문이 있습니다. OCCA는 JIT 시간에 내부 루프 치수를 알고 있습니까?

루프 차원이 커널 인수로 전달될 수 있다고 생각합니다.

맞는 말이지만 왜 유용한지 이해가 되지 않습니다. occa가 JIT 시간에 __launch_bounds__ 속성을 내보내는 방법을 묻고 있습니다. 그 지점에서 루프 치수를 알아야 합니다. 이것은 커널 인수와 직교하지 않습니까?

그는 내부 루프의 희미한 값이 인수로 전달될 수 있다고 말합니다. 즉, 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에는 여기에서 논의 중인 CUDA/HIP의 __launch_bounds__ 와 같은 유사한 스레드 블록 크기 힌트가 있습니까?

좋은 질문. 알아보기 위해 SYCL 표준(v1.2.1)을 다시 확인했습니다. OpenCL C에서 사용 가능한 모든 속성이 지원되며 cl 네임스페이스를 사용하여 C++ 11 속성 지정자와 함께 제공될 수 있습니다. 예를 들어 OpenCL C의 __attribute__(((reqd_work_group_size(n))) [[cl::reqd_work_group_size(n)]] 와 같습니다.

스레드 그룹 크기를 지정하는 데 사용할 수 있는 두 가지 유형이 있습니다. work_group_size_hint(n) 는 소프트 버전입니다. 스레드 그룹 크기는 n 가 될 것을 제안하지만 req_work_group_size(n) 는 엄격한 요구 사항입니다. .

OCCA에 대한 몇 가지 옵션:

1. occa::kernel 클래스에 "innerDimHint" 멤버 함수를 추가하여 CUDA/OpenCL/HIP에 대한 스레드 딤 힌트를 사용하여 (아직 해시에 없는 경우) 재컴파일을 강제 실행합니다.

2. 새 스레드 배열 크기가 지정될 때 수행되는 재컴파일을 트리거하기 위해 실행기 내부에 일부 논리를 추가합니다. 이 기능은 일부 OCCA_ * 정의에 의해 설정/해제될 수 있습니다.

이 두 가지 모두 이전 버전과 호환되는 방식으로 수행할 수 있습니다.

나는 실제로 이것을 관리하기 위해 별도의 런타임을 신뢰하고 아무 것도 다시 컴파일하지 않기로 선택합니다. 본질적으로 @dmed256 의 원래 제안을 사용하여 빌드 소품으로 만든 다음 백엔드에서 지원하는 경우 번역 시 커널에 각각의 __launch_bound__ 힌트를 추가합니다.

CUDA 및 HIP의 경우 __launch_bound__ 는 실제로 힌트일 뿐이므로 OpenCL의 work_group_size_hint 와 더 유사할 수 있습니다. 블록의 각 스레드에서 사용할 수 있다고 가정할 수 있는 레지스터 수를 컴파일러에 알리는 데만 사용됩니다. 사용자가 시작 범위를 위반하더라도 커널이 레지스터를 많이 사용하지 않을 수 있으므로 반드시 오류는 아닙니다. 사용자가 시작 범위를 위반하고 실제로 레지스터가 충분하지 않은 경우 런타임은 OCCA가 잡아야 하는 오류를 발생시킵니다.

자동 튜너를 실행할 때 너무 많은 LDS 또는 REG가 필요한 OCCA:HIP 커널에 대한 분할 오류를 발견했습니다. 나는 HIP가 잡아낼 오류를 던질 것이라고 회의적이었다. 이제 해결되었길 바랍니다.

사용자가 제공한 힌트나 런타임에 새 스레드 구성을 발견하는 실행기로는 괜찮습니다.

참고로 저는 OKL 커널 코드(예: 외부의 경우 K_blockDim , 내부의 경우 K_threadDim )에서 매크로 상수 대체를 통해 호스트 코드에서 명시적인 런타임 루프 경계를 지정하는 것만으로도 만족했습니다. 커널 소품을 통해 물론 GPU의 특성과 상태를 쿼리하는 자체 API 코드가 있습니다. 이 정보를 사용하여 전달할 루프 경계를 계산합니다. 예, 그런 종류의 동적 문제로 인해 런타임 중에 JIT 재컴파일이 가끔 발생하지만 제 경우에는 임계값 변경을 단계적으로 변경하기 때문에 드문 경우이므로 실제 루프 경계는 일반적으로 동일하게 유지되거나 주어진 커널에 대한 일부 공통 세트에 속합니다. 또한 JIT 재컴파일을 줄이기 위해 일부 커널에 대해 사전 컴파일을 활용합니다.

런타임에 이러한 루프 경계를 명시적으로 정의하면 OKL 코드에서 GPU 로컬 메모리 배열을 사용하여 런타임 크기 조정을 용이하게 합니다.

이 기능이 중요할 것 같습니다.
https://rocmdocs.amd.com/en/latest/Current_Release_Notes/Current-Release-Notes.html#performance -impact-for-kernel-launch-bound-attribute

서투른 구현에 대한 사과와 함께 Np(>256) 스레드가 필요한 libparanumal의 커널에 사용하는 해결 방법입니다.

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 컴파일러 플래그를 사용하는 것이 Noel Chalmers에 의해 제안되었습니다. 총체적인 구현은 내 것입니다.

커널이 최대 경계를 위반하는 경우 어떤 일이 발생하는지 불분명하므로 이 작업을 수행할 때 주의하는 것이 중요합니다.

부적절한 범위를 사용하지 않기 위해 다른 최대 스레드 수를 사용하는 커널에 대해 occa::properties 개체의 별도 복사본을 만듭니다.

앞으로 시작 범위를 위반하면 런타임 오류가 될 가능성이 높습니다.