[미리보는 C++ AMP-2] C++ AMP 맛 보기

DirectX 11 2011. 12. 1. 08:00 Posted by 알 수 없는 사용자


백문이 불여일견이라고들 하죠?
글로써 언급하는 것보다,
프로그래머들은 코드로 볼 때 더 직관적인 이해를 할 수 있는 경우가 많습니다.

간단하게 두 배열의 합을 구하는 코드를 통해서,
이를 AMP 적으로 어떻게 작성하는지를 보겠습니다.

아래는 우리가 일반적으로 생각할 수 있는 CPU를 활용해서
합을 구하는 코드입니다.

void AddArrays(int n, int * pA, int * pB, int * pC)

{

   for (int i=0; i<n; i++)

   {

      pC[i] = pA[i] + pB[i];

   }

}


자세한 설명은 생략해도 될 것이라 생각합니다.^^
아래는 C++ AMP로 작성된 합을 구하는 코드입니다.

#include <amp.h>

using namespace concurrency;

void AddArrays(int n, int * pA, int * pB, int * pC)

{

   array_view<int,1> a(n, pA);

   array_view<int,1> b(n, pB);

   array_view<int,1> sum(n, pC);

   parallel_for_each( sum.grid,

                                          [=](index<1> i) restrict(direct3d)

   {

      sum[i] = a[i] + b[i];

   }   );

}


 

위의 AMP 구현 부분에서 색상이 들어간 부분이 CPU를 활용한 부분과 다른 부분입니다.
코드량이 증가해버린 단순한 사실을 우리는 확인할 수 있습니다.
코드가 증가한 가장 기본적인 이유는 메모리 문제입니다.
우리가 지금까지 C++ 에서 사용하는 메모리는 CPU 가 접근할 수 있는 시스템 메모리입니다.
이 메모리를 GPU 로 처리하기 위해서는 GPU가 직접적으로 접근 가능해야 합니다.
그런데 C++ 에서 할당한 메모리는 GPU가 접근할 수가 없습니다.
그래서 비디오-메모리에 시스템-메모리의 데이터를 복사하는 과정이 필요합니다.
그 과정이 바로 코드의 증가를 불러오는 것입니다.
( 복사라고 보기는 조금 모호합니다만, 지금은 그냥 넘어가겠습니다. )

이 증가한 코드들에 대해서 지금부터 살펴보겠습니다.


#include <
amp.h>

using namespace concurrency;


AMP를 사용하기 위한 헤더의 선언입니다.
기본적으로 AMP를 사용하기 위해서는 람다식과 concurrency  에 대한 이해가 있어야 합니다.


array_view
<int,1> a(n, pA);

array_view<int,1> b(n, pB);

array_view<int,1> sum(n, pC);

이 부분은 앞서 언급했던 GPU가 접근할 수 있는 메모리 영역으로
데이터를 만드는 부분입니다.
이 데이터를 만들 수 있는 메모리 영역이
array 와 array_view 라는 것으로
구분됩니다.
이 둘의 차이는 이후에 다루어 드릴테니,
지금은 GPU가 접근할 수 있는 메모리 영역으로 생각해 주셨으면 합니다.^^


parallel_for_each(
 ... ) restrict( direct3d )

c++ 에 main(...) 이 있다면, AMP 에는 parallel_for_each( ... ) restrict( direct3d ) 가 있습니다.
이 부분은 GPU가 연산을 시작하는 진입점( EntryPoint ) 입니다.

parallel_for_each를 잘 모르시는 분들은 아래의 링크를 참고하시 바랍니다.
http://vsts2010.net/123
더 자세한 사항은 이 블로그의 VC++ 10 Concurrency Runtime 카테고리를 참고하시기 바랍니다.

 

제가 단순하게 정리해 드리면,
기존에 VC++ 10 에서 사용되는 parallel_for_each 는 CPU를 활용해서 병렬적으로 처리하는 것이지만,
뒤에 restrict( direct3d )를 명시함으로써 이를 GPU에서 병렬적으로 처리
하도록 합니다.
 

이 진입 함수는 parallel_for_each(  람다식 ) 형태를 가지게 됩니다.
이는 GPU의 많은 스레드들에게 '이 람다식을 각각 실행해 주세요' 라고 명령을 내리는 것입니다.
역시 람다( Lambda ) 에 대해서 잘 모르시는 분은 옆의 카테고리에서
c++0x 를 보시기 바랍니다.
람다의 첫번째 설명 링크는 아래와 같습니다.
http://vsts2010.net/73

 

그러면 얼마나 많은 스레드들이 람다식을 실행해야 하는지에 대한 명시가 있어야 합니다.
그것이 바로 paralle_for_each( ... ) 의 첫번째 인자인 sum.grid 입니다.

grid 에 대한 설명은 뒷부분에서 자세히 다루겠으니,
지금은 스레드 갯수에 대한 정의로 보시면 충분합니다.

람다식의 인자로 index<1> idx 가 보이실 것입니다.
이 인자는 람다식에 전달되는 스레드들의 ID들입니다.
이 ID들을 통해서 스레들을 식별할 수 있습니다.
스레드들의 ID를 통해서 배열 형태의 데이터를 캡쳐해서 값을 저장하는 것입니다.

간단한 프로그램이지만, 사실 이런 형태가 C++ AMP의 전부입니다.^^

물론 이렇게 간단히 끝나면 무척 행복하겠지만,
난이도는 역시 알면 알수록 높아집니다.^^


본 글에서 사용된 예제들은 MS에서 사용된 예제들입니다.
제가 구현한 것들이 아님을 알려드립니다.^^

[StartD2D-2] 왜 GPU 인가?

DirectX 11 2011. 3. 25. 08:00 Posted by 알 수 없는 사용자

 

우리가 예전에 생각했던 PC는 어떤 모습 이였을까요?

앞서 언급했듯이, 아주 오래 전의 PC들은 하나의 CPU를 통해서 연산을 수행하고

결과를 저장하는 구조를 가지고 있었습니다.

또한 오늘 날의 그래픽 처리를 위한 GPU라는 개념도 초창기에는 상상하기 힘든 개념 이였습니다.

하지만, 오늘 날의 PC는 CPU는 여러 개이며, GPU의 성능 또한 아주 막강합니다.

거기다 멀티 GPU인 상황이기도 합니다.

이런 변화들은 Windows 운영체제 차원에서 많은 변화를 요구하게 되었습니다.

사실 현재의 개발 환경은 굉장히 과도기적인 상태라고 할 수 있습니다.

이제 막 이러한 패러다임의 변화들에 대해서 많은 소프트웨어적인 기술들이 공개되고,

개발자들의 선택을 기다리고 있는 상황입니다.

( 대표적으로는, TBB나 CUDA 같은 기술들이 있을 것입니다.^^ )

 

XP 시대까지는 많은 부분들이 전통적인 아키텍쳐 구조들을 기반으로 해서 구현되었고,

꾸준히 개선되어 왔습니다.

즉, XP 시대까지는 싱글코어 기반으로 대부분의 아키텍쳐들이 설계되었습니다.

그래서 Windows XP가 안정적이고 훌륭한 운영체제로 평가 받는 것입니다.

 

하지만, Windows 7 운영체제를 시작으로 앞으로는 많은 수의 CPU를 활용한 구조와

GPU를 활용하는 구조로 변경되고 있으며, 빠르게 XP세대를 대체해 나갈 것입니다.

( 정확하게는 Windows Vista 운영체제부터 시작되었습니다.^^ )

 

앞서 DirectX의 탄생의 과정에 대해서 짧게 살펴보았습니다.

DirectX의 가장 큰 장점은 그래픽 하드웨어의 지원을 받아서

빠른 성능으로 고품질의 결과를 처리할 수 있다는 것이다.

마이크로소프트는 DirectX를 이용해서 고속으로 드라이버에 접근할 수 있는 구조를 만들었습니다.

이를 HAL 이라고 합니다.

 

결론을 얘기하자면,

DirectX 이용한 렌더링( rendering ) 작업이 GDI를 이용한 작업보다 훨씬 더 빠르고 뛰어납니다.

품질은 비교해 보면, 아래와 같습니다.

 

 

현 세대의 PC들은 막강한 성능의 GPU를 탑재하고 있으며,

이들은 대부분 게임과 같은 멀티미디어 관련 애플리케이션을 실행하지 않는 이상은

거의 사용되지 못하고 있었습니다.

그래서 Windows 7 운영체제는 이를 활용하기 위해서 화면에 그리는 작업 패러다임을

완전히 변경해 버렸습니다.( 물론 비스타도 포함됩니다.^^ )

아래의 그림이 이제는 윈도우즈 운영체제 환경의 기본 추상화 계층입니다.

 

 

 

위의 그림에서 보이는 것처럼, 이제 화면에 무엇인가를 그리는 모든 작업은

DirectX를 이용해서 수행하게 되었습니다.( DXGI가 바로 DirectX 입니다. )

이 말은 즉, 기본적으로 GPU를 활용한 한다는 의미입니다.

그렇다고 현재 GDI 가 당장 사라져 버린 것은 아닙니다.

아직까지는 호환성 유지를 위해서 상당기간 공존할 것입니다.

하지만 DirectX 를 활용하는 이 방법은 빠르게 GDI를 대체해 나갈 것이다.

 

 

CPU는 범용 목적으로 설계되었기 때문에,

렌더링 목적으로 설계된 GPU 보다는 렌더링에 대한 작업만큼은 느릴 수 밖에 없습니다.

왜냐하면 GPU는 복잡하고, 많은 수치 연산에 특화된 구조이기 때문입니다.

 

이 DirectX를 강력함을 사용하기 때문에 XP 세대의 운영체제보다 Windows 7이 좋습니다.

( 왠지 홍보하는 것처럼 들리겠지만, 부인할 수 없는 사실이랍니다. ^^ )

 

앞으로 윈도우 프로그래밍에서도 이 DirectX를 이용하는 것이 보편화 될 것입니다.

이제 윈도우 프로그래밍 세계도 큰 변화가 예고되고 있습니다.

 

왜 GPU인가?

 

오늘 날, 프로세싱 유닛의 관점에서 컴퓨터를 바라보면 아래와 같습니다.

 

 

위의 그림에서 CPU는 4개입니다. 이 말은 연산 처리가 가능한 유닛이 4개라는 얘기입니다.

오른쪽 그림은 그래픽 카드를 표현한 것인데,

그래픽 카드는 SIMD 형태로 데이터를 병렬적으로 처리할 수 있는 유닛이 매우 많이 존재합니다.

직관적으로 평가해도 좌측의 CPU 4개 보다는 훨씬 많아 보입니다.

컴퓨터에 CPU 3GHz 가 4개 구동되고 있다면, 초당 연산을 하는 횟수가 48~96GFlops 라고 합니다. ( GFlops 는 109 Flops입니다. )

반면 1GHz GPU 1개가 처리할 수 있는 연산 횟수는 1TeraFlops 입니다. ( TeraFlops는 1012 Flops 입니다. )
GPU는 실수(float) 처리와 병렬처리에 이미 최적화 된 유닛이기 때문에 이것이 가능합니다.

반면 CPU는 범용 목적으로 설계된 유닛입니다.

그래서, If 문과 같은 조건 분기 명령어들은 GPU보다 CPU가 훨씬 빠르게 처리할 수 있습니다.

지금까지는 GPU는 그래픽 처리만을 위해서 존재했었습니다.

특히나 게임과 같은 대용량의 그래픽 처리를 필요로 하는 경우에는
이들의 역할이 절대적 이였습니다.

하지만, 그 이외의 경우는 사용되고 있었을까요?

대답은 '아니다' 입니다.

게임과 같은 경우 DirectX를 통해서 이들을 활용할 수 있었지만,

일반 애플리케이션의 경우에는 이 GPU를 활용할 방법이 없었습니다.

즉, 일반 애플리케이션에서 GPU는 거의 아무 일도 하지 않고 방치되어 있는 것입니다.

CPU의 일을 GPU에게 분담해서 CPU의 부담을 줄이고,

GPU의 활용 능력을 극대화 하면 자연스럽게 최적화가 가능합니다.

그래서 GPU를 활용하는 것이 현재 Windows 7 운영체제에서는

하나의 중요한 이슈로서 자리 잡고 있습니다.

[JumpToDX11-12] DirectCompute 의 절차.

DirectX 11 2010. 4. 26. 09:00 Posted by 알 수 없는 사용자


앞선 시간에서 우리는 GPGPU 의 실행에 대한 간단한 개념에 살펴보았습니다.
이제 실제적으로 GPGPU 를 활용하는 절차를 살펴볼 차례입니다.
큰 절차는 다음과 같습니다.


 

< DirectCompute 의 초기화 >

가장 먼저 DirectCompute 를 초기화 해야 합니다.
 

hr = D3D11CreateDevice

(

     NULL,     // default gfx adapter

  D3D_DRIVER_TYPE_HARDWARE,  // use hw

     NULL,               // not sw rasterizer

     uCreationFlags,     // Debug, Threaded, etc.

     NULL,               // feature levels

     0,                  // size of above

     D3D11_SDK_VERSION,  // SDK version

     ppDeviceOut,        // D3D Device

     &FeatureLevelOut,   // of actual device

     ppContextOut );     // subunit of device

);

어디서 많이 본 API 라고 생각이 드시죠.
DirectCompute 를 초기화하는 작업은 바로 전통적인 CreateDevice() API 를 사용하는 것입니다.
즉, DirectX 를 사용하는 것입니다.
이로 인해서 DirectX 는 더욱 더 넓은 범위에서 활용되어 질 것입니다.


< HLSL 의 로드 >

그 다음은 실제적으로 GPU 가 실행을 하게될 로직을 로드할 차례입니다.
이것은 워낙 다양할 수 있는 부분이기 때문에, 여기서는 간단하게 예를 들겠습니다.


#define BLOCK_SIZE 256

StructuredBuffer   gBuf1;
StructuredBuffer   gBuf2;
RWStructuredBuffer gBufOut;

[numthreads(BLOCK_SIZE,1,1)]
void VectorAdd( uint3 id: SV_DispatchThreadID )
{
  gBufOut[id] = gBuf1[id] + gBuf2[id];
}


보통 이를 두고 ComputeShader 라고 합니다.
ComputeShader 를 위한 여러종류의 버퍼가 존재합니다.
더 많은 종류의 버퍼는 차후에 설명드리기로 하겠습니다.

StructuredBuffer 라고 정의된 키워드는 C언어의 구조체와 같은 구조를 가집니다.
즉, 개발자가 정의한 구조체입니다.
그런데 앞에 식별자가 없으면 읽기 전용이라는 의미입니다.
반면에 앞에 'RW' 라고 명시된 버퍼는 읽기/쓰기 가 가능한 버퍼라는 의미입니다.
우리는 GPU 가 처리한 결과는 읽기/쓰기가 가능해야 하기 때문에,
결과를 저장하는 버퍼는 'RW" 가 명시되어 있습니다.
최적화를 위해서 각 목적에 맞게 버퍼를 사용해야 할 것입니다.^^


< ComputeShader 의 생성 >

pD3D->CreateComputeShader( pBlob->GetBufferPointer(),
                                             pBlob->GetBufferSize(),
                                             NULL,
                                             &pMyShader );  // hw fmt


CreateComputeShader() API 를 통해서 간단히 ComputeShader 를 생성할 수 있습니다.


< 입력을 위한 GPU 버퍼 만들기 >

우리가 GPGPU 를 활용하는 것은 CPU 를 활용하는 것보다 빠르게 결과를 도출하기 위해서입니다.
이를 위해서는 GPU 가 빠르게 액세스할 수 있는 버퍼가 있어야 할 것이며,
당연히 이것은 비디오 메모리에 존재해야 할 것입니다.
그래서 우리는 DirectX 인터페이스를 통해서 비디오 메모리를 생성을 합니다.


D3D11_BUFFER_DESC descBuf;
ZeroMemory( &descBuf, sizeof(descBuf) );
desc.BindFlags = D3D11_BIND_UNORDERED_ACCESS;
desc.StructureByteStride = uElementSize;
desc.ByteWidth = uElementSize * uCount;
desc.MiscFlags = D3D11_RESOURCE_MISC_BUFFER_STRUCTURED;

pD3D->CreateBuffer( &desc, pInput, ppBuffer );

주의해야 할 것은 바로 'BindFlags' 입니다.
'D3D11_BIND_UNORDERED_ACCESS' 라는 플래그를 주고 있습니다.
이것은 PixelShader 나 ComputeShader 에서 병렬적으로 실행하는 버퍼를 의미
합니다.


< 뷰를 만들자!! >

버퍼 리소스를 만들었으면, 이제 이를 실제 파이프라인에서 액세스할 수 있는 매커니즘을 만들어야 합니다.
즉, ShaderResourceView 를 만들어야 합니다.
DirectX10 부터는 아래와 같이 리소스들을 다루어야 합니다.



앞선 시간들을 통해서 View 라는 개념을 충분히(?) 숙지하셨을 것이라 생각합니다.^^
대체로 ShaderResourceView 는 파이프라인 스테이지에서 읽기 전용입니다.
그런데, 아래 UnorderedAccessView 는 양방향 화살표로 되어있습니다.
읽기/쓰기가 가능한 형태입니다.
이를 통해서 결과를 비디오 메모리에 있는 버퍼에 결과를 기록할 수 있음을 보여주고 있는 것입니다.


실제 API 를 통한 View 생성은 다음과 같습니다.

D3D11_UNORDERED_ACCESS_VIEW_DESC desc;
ZeroMemory( &desc, sizeof(desc) );
desc.ViewDimension = D3D11_UAV_DIMENSION_BUFFER;
desc.Buffer.FirstElement = 0;
desc.Format = DXGI_FORMAT_UNKNOWN;
desc.Buffer.NumElements = uCount;

pD3D->CreateUnorderedAccessView( pBuffer, // Buffer view is into
                                                      &desc,  // above data
                                                      &pMyUAV ); // result


중요한 부분은 ViewDimension 부분입니다.
'D3D11_UAV_DIMENSION_BUFFER' 를 설정하고 있는데,
이는 ComputeShader 상에서 이 버퍼를 일반적인 버퍼로 보겠다
는 의미입니다.
즉, 샘플링 작업을 전혀하지 않습니다. 
이는 어떠한 수정도 없이 데이터를 있는 그대로 보존합니다.


< 실행 단계 >

이제까지는 모두 준비 단계였습니다.
이제는 실제 실행 단계에 대해서 언급해 보겠습니다.

먼저, ComputeShader 를 현재 파이프라인 스테이지에 아래와 같이 바인딩 해주어야 합니다.
pD3D->CSSetShader( pMyShader, NULL, 0 );


그 다음에는 뷰를 바인딩해야 합니다.
pD3D->CSSetUnorderedAccessViews( 0,
                                                        1,
                                                       &pMyUAV,
                                                       NULL );


이제 마지막으로 GPU 에게 현재 바인딩된 내용을 바탕으로 연산해 줄 것을 요청합니다.
pD3D->Dispatch( GrpsX, GrpsY, GrpsZ );


이제 실행의 단계가 모두 끝났습니다.
이 단계까지 끝나면, 실행 결과가 비디오 메모리에 존재합니다.
우리가 결과를 확인하기 위해서는 CPU 가 액세스할 수 있는 버퍼로 결과를 복사
해야 합니다.


< 결과 복사해 오기 >

결과를 CPU 가 액세스 하기 위해서는 어떻게 해야 할까요?
이전 시간을 통해서 언급드렸듯이,
DX10 부터는 리소스에 대한 세부적인 액세스 권한에 대한 플래그를 설정할 수 있습니다.
그래서 다음과 같은 설정으로 버퍼를 만듭니다.

D3D11_BUFFER_DESC desc;
ZeroMemory( &desc, sizeof(desc) );
desc.CPUAccessFlags = D3D11_CPU_ACCESS_READ;
desc.Usage = D3D11_USAGE_STAGING;
desc.BindFlags = 0;
desc.MiscFlags = 0;
pD3D->CreateBuffer( &desc, NULL, &StagingBuf );


'D3D11_CPU_ACCESS_READ' 라는 플래그를 통해서,
이 버퍼는 CPU 가 액세스 할 수 있는 형태로 만듭니다.
그리고 'D3D11_USAGE_STAGING' 라는 플래그를 통해서
단순히 비디오 메모리에 있는 내용을
CPU 도 접근 할 수 있는 메모리로 복사해오는 버퍼임을 명시
합니다.


그리고 아래와 같이, 준비해둔 버퍼에 실제로 메모리를 복사해 옵니다.
pD3D->CopyResource( StagingBuf, pBuffer );

마침내 우리는 GPU 에 의해서 처리된 결과를 확인할 수 있게 되었습니다.


< 마치며...>

지금까지 DirectCompute 를 활용하는 일련의 절차에 대해서 살펴보았습니다.
DirectX11 의 API 가 생소해서 어려워 보일 수 있지만,
실제로 DirectCompute 의 절차는 그리 복잡하지는 않습니다.
현재 DirectCompute 의 활용은 SDK 샘플에 'NBodyGravity' 라는 이름으로 들어있습니다.
제가 여기에 대해서 자세히 언급드리면 좋겠지만,
그것은 차후로 미루기로 하겠습니다.^^


참고 자료
http://microsoftpdc.com/Sessions/P09-16
본 내용은 위의 PDC 를 참고해서 만들었습니다.

[JumpToDX11-11] DirectCompute 를 위한 한걸음!

DirectX 11 2010. 2. 11. 09:00 Posted by 알 수 없는 사용자


앞선 시간을 통해서 GPGPU 를 위해서 마이크로소프트가 제공하는 플랫폼이
DirectCompute 라는 것이라고 말씀드렸습니다.
앞으로 DirectX11 을 지원하는 모든 그래픽카드들은 이 DirectCompute 를 지원할 것입니다.
그 이외에도 일부 DirectX10 을 지원하는 그래픽카드들도 지원을 하고 있습니다.


GPGPU 를 위해서 가장 기본적이고 핵심이 되는 기능은 무엇일까요?
저는 GPU 에서 처리된 메모리를 CPU 쪽의 메모리로 보내는 것이라고 생각합니다.
( 이는 개인 의견입니다.^^ )
즉, 그래픽카드에 있는 메모리를 메인메모리로 보내는 작업입니다.
DirectX9 세대까지는 이 작업이 불가능 했습니다.
예를 들면, 그래픽스 파이프라인 중간에 처리된 결과를 다시 가공할 수 있는 방법은
VertexShader 나 PixelShader 같은 쉐이더 스테이지 정도 뿐이였습니다.

하지만 DirectX10 부터는 이들에 대한 중간 결과를 메인메모리로 보내는 기능이 추가되어지면서,
GPGPU 의 시작을 알렸다고 생각합니다.
이 단순한 Copy 작업이 앞으로도 얼마나 유용하게 사용될 수 있을지는 기대가 상당합니다.



< DirectCompute 를 위한 ComputeShader >

DirectCompute 를 위해서 개발자가 할 일은 ComputeShader 를 작성하는 일입니다.
ComputeShader 는 HLSL 이라는 기존 DirectX 의 쉐이더 문법 구조로 작성을 합니다.




HLSL 코드는 DirectX 쉐이더 컴파일러인 FXC 나 API 를 통해서 컴파일 됩니다.
HLSL 은 결국 최적화된 IL 코드를 생성하게 되고,
이 IL 코드를 기반으로 런타임에 각각의 하드웨어에 최적화된 명령어들로 변환
되어져서 실행됩니다.


< GPGPU 에게 실행이란? >

GPGPU 를 활용해서 실행한다는 것은 하드웨어 내부적으로 어떻게 동작하도록 할까요?
앞선 시간에 GPU 는 병렬 처리에 최적화된 많은 SIMD 형태로 구성되어져 있다고 언급했었습니다.
결국 이들은 스레드들의 그룹으로써 실행합니다.
스레드들을 얼마나 많이 생성할 것인지를 개발자가 정해주면, 그에 맞게 연산을 수행합니다.

API 에서는 이들을 큰 그룹으로 나누어 줍니다.
큰 그룹으로 나누어 주는 API 는 ID3D11DeviceContext::Dispatch() 입니다.

ipImmediateContextPtr->Dispatch( 3, 2, 1 );

이렇게 큰 블럭 단위로 나누고 난 후에
ComputeShader HLSL 에서는 이들을 세부적인 스레들로 분할하는 문법을 지정합니다.

[numthreads(4, 4, 1)]
void MainCS( ... )
{
        ....
}




결과적으로 위의 그림처럼 스레드들이 생성되어서 병렬적으로 실행이 됩니다.
위에 나열된 숫자들은 스레드 ID 로써의 역활을 합니다.
즉, 어떤 스레드의 ID 가 MainCS 함수에 파라메터로 넘오오면,
그 ID 를 통해서 해당 버퍼에 값을 작성하게 됩니다.

아래에 간단한 예가 있습니다. 

[numthreads( 256,1,1) ]

void VectorAdd( uint3 id: SV_DispatchThreadID )
{

  gBufOut[id] = gBuf1[id] + gBuf2[id];

}


아무리 스레드들이 복잡하게 동작하더라도, 위와 같이 ID 를 통해서 제어한다면
그 어떤 작업도 문제없이 할 수 있습니다.

일단 먼저 어떻게 DirectCompute 가 실행되어지는지에 대해서 살펴보았습니다.
실행까지 가기 위해서는 일련의 절차를 거쳐야 합니다.
이들에 대해서는 앞으로 차근차근 살펴보겠습니다.



참고 자료
http://microsoftpdc.com/Sessions/P09-16
본 내용은 위의 PDC 를 참고해서 만들었습니다.