Visual Studio 2010 공식 팀 블로그 @vsts2010

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];

        }

     );

}

array_view 라는 것이 먼저 눈에 보입니다.
C++ AMP 에서는 대규모 메모리를 의미하는 클래스로
array 와 array_view 라는 것이 있습니다.
기본적으로 이 두 클래스의 목적은
accelerator 상으로 데이터를 옮기기 위함 입니다.

array 의 경우에는 실제 데이터 배열입니다.
STL 의 컨테이너와 유사합니다.
반면 array_view 는 데이터 배열의 일종의 래퍼( wrapper ) 입니다.
그래서 array_view 는 STL의 이터레이터( iterator ) 와 유사한 동작을 합니다.
array_view는 한 번에 여러 데이터의 동시에 접근할 수 있으며,
랜덤 액세스( random-access ) 가 가능합니다.

array 에 의해서 정의되는 배열 데이터는 accelerator 상에 메모리를 가지게 됩니다.
이것은 개발자가 직접 정의해서 할당할 수도 있고,
런타임( runtime ) 에 의해서 자동적으로 생성될 수도 있습니다.
그렇기 때문에 실제 데이터가 생성되어질 때 깊은 복사( deep-copy )를 하게 됩니다.
우리가 일반적으로 오브젝트를 메모리에 생성했을 때와 같다고 생각하시면 됩니다.
array 는 다음과 같이 사용할 수 있습니다.( 샘플은 msdn 에서 가져왔습니다 )

vector<int> data(5);
for (int count = 0; count < 5; count++)
{
    data[count] = count;
}

array<int, 1> a(5, data);

parallel_for_each(
    a.grid,
    [=, &a](index<1> idx) restrict(direct3d)
    {
        a[idx] = a[idx] * 10;
    }
);

data = a;
for (int i = 0; i < 5; i++)
{
    cout << data[i] << "\n";
}

반면에 array_view는 이름에서 유추할 수 있듯이,
실제 데이터들은 다른 accelerator 상에 있고,
이를 연산을 위해서 복사를 하는 개념입니다.
즉, 커널 함수가 실행될 때, 데이터가 복사됩니다.
( 커널 함수는 AMP 내의 람다 함수 부분을 의미합니다. )

이 array_view 개념은 DirectX11 에서 보셨던 분들은 쉽게 이해할 수 있는 개념입니다.
바로 ComputeShader 를 위해서 데이터들을 연결하는 바로 그 개념이기 때문입니다.
아래의 그림은 ComputeShader 의 동작 방식을 보여주는데,
SRV( shader resource view )와 UAV( unordered access view ) 라는 것이
결국 view 의 역할을 하는 것입니다.

안녕하세요~ 조진현입니다.
얼마 전 대구에서 KGC 2011 행사가 있었습니다.
저는 그 곳에서 DirectX11 과 관련한 발표를 진행하고 왔습니다.
그래서 발표 슬라이드를 공개해 드립니다.

특히나 이번 발표 때, C++ AMP 에 대한 언급이 있었습니다.
AMP는 아래 링크에 흥배님이 자세히 설명해 주셨습니다.
http://vsts2010.net/591

빠른 시간 내에 발표 때 언급했던 C++ AMP 와 관련한 내용을
팀 블로그에 게재하도록 하겠습니다..^^

행렬의 등장

기존의 윈도우 애플리케이션 개발자가 Direct2D를 접할 때,
가장 생소한 개념은 행렬( Matrix ) 일 것입니다.

즉, 아래의 API 이겠죠?

<코드>

::g_ipRT->SetTransform( ::D2D1::Matrix3x2F::Identity() );

</코드>

우리는 항상 렌더링 작업을 하기 전에, 이 작업을 해주었습니다.
이것은 과연 무슨 의미를 가지고 있는 것일까요?  

불행하게도(?) Direct2D에서 각종 변환 작업을 위해서는 행렬( Matrix )을 사용합니다.
저는 고등학교 2학년 학기 초에 배웠던 기억이 있습니다.
그 때는 주로 연립 방정식의 해를 구하기 위해서 풀이 방법을 익혔습니다.
아마 대부분 저와 비슷하실 것이라 생각이 듭니다.

왜 뜬금없이 행렬이 등장했는지를 언급하고자 하면, 상당히 고통스럽습니다.^^
저는 이 행렬에 대한 깊은 이해를 원하지 않습니다.
제가 원하는 것은 이 행렬 관련 API를 이용해서 화면 상에 나오는 오브젝트들의
이동이나 회전 등과 같은 변환을 표현 할 수 있다는 것만 아셨으면 좋겠습니다.^^

Direct2D 에서는 3ⅹ2 행렬을 사용합니다.
행렬의 각 성분들은 아래와 같습니다.  

이 행렬은 D2D1_MATRIX_3X2 라는 구조체로 표현됩니다.
Direct2D에서는 이 행렬을 손쉽게 다루기 위해서 Matrix3x2F 라는 유틸리티 기능을 지원합니다.
우리는 주로 이 Matrix3x2F 의 기능을 이용해서 변환 정보를 설정할 것입니다.
행렬의 M11, M12, M21, M22 성분은 회전과 확대/축소와 관련된 수치가 입력됩니다.
M31과 M32에는 이동과 관련된 수치가 입력됩니다.
행렬의 수치를 통해서 우리가 원하는 변형을 하고자 할 때,
이들 수치를 직접 입력해서 행렬을 제어하기는 무척 어렵습니다.

그래서 Direct2D 에서 제공하는 개발자 편의를 위한 여러 클래스들을 사용해서 이들 수치를 제어합니다.

스크린 좌표계  

변환의 이해를 위해서는 좌표계에 대한 이해가 필수적입니다.
우리가 가장 많이 사용하는 좌표계는 당연히 2차원 좌표계입니다.
바로 모니터가 2차원이기 때문입니다.
하지만 이전에도 언급드린 적이 있지만,
컴퓨터 모니터의 좌표계는 우리가 일반적으로 알고 있는 2차원 좌표계가 아닙니다.

좌측이 우리가 흔히 학창시절에 배우는 2차원 데카르트 좌표계( 2D Cartesian coordinate system ) 입니다.
우측이 컴퓨터 모니터가 사용하는 스크린 좌표계입니다.
이점 잘 숙지 하시고, 다음 내용을 보시기 바랍니다.^^

이번에 제공되는 샘플의 결과는 다음과 같습니다.

이동( Translate )

먼저 살펴 볼 것은 이동( Translate ) 입니다.
가장 위에 있는 이미지가 바로 이동만 적용된 형태입니다.
샘플에서는 단순히 ( X,Y ) 축으로 +20씩만 움직였습니다

<코드>
D2D1::Matrix3x2F matTranslation; 
matTranslation = ::D2D1::Matrix3x2F::Translation( 20.0f, 20.0f );
::g_ipRT->SetTransform( matTranslation );                    
::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea );    
</코드>  

D2D1::Matrix3x2F::Translation() 를 통해서 우리가 원하는 이동을 수행하고 있습니다.
쉽죠? 이런 식으로 하면 행렬에 대한 깊은 이해도 필요하지 않을 것이라 생각합니다.^^  

회전( Rotate ) 

두 번째는 회전입니다.
샘플에서는 두 번째 그림과 세 번째 그림이 바로 회전 변환에 대한 결과물입니다.
사실 회전은 행렬의 성분들을 굉장히 복잡한 수치로 변경시킵니다.
왜냐하면 이들 회전 수치들은 삼각함수 값들이기 때문입니다.

하지만, 두려워하지 마시기 바랍니다.
Direct2D 에서는 이를 편리하게 수행하기 위해
::D2D1::Matrix3x2F::Rotation() 를 제공하고 있습니다.
회전 시킬 때, API 에 입력되는 값이 회전량과 회전 중점입니다.
회전량의 경우에는 라디안 값이 아닌, 각도 값이 입력됨을 주의하시기 바랍니다. 
즉, Degree 값입니다.
그리고 이 회전량의 경우 음의 값과 양의 값을 모두 입력이 가능합니다.
음의 값이 입력이 되면 시계 반대 방향으로 회전을 수행하게 됩니다.
( 양수면 시계방향으로 회전 합니다. )

또한 회전 중점의 경우도 유의해야 하는데, 아래의 그림을 보시기 바랍니다.

좌측 그림의 경우에는 물체의 중점 위치를 기준으로 회전을 수행한 것입니다.
반면에, 우측 그림의 경우에는 물체의 좌측 상단을 기준으로 회전을 수행한 것입니다.
결과물이 다르죠?
이처럼 회전 변환을 할 때는 이 두 가지를 잘 고려해서 수행해야 합니다.  

<코드>
matRot = ::D2D1::Matrix3x2F::Rotation( -30.0f,
                                       D2D1::Point2F( 120.0f, 320.0f ) );
 
::g_ipRT->SetTransform( matRot );                           
::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea );    
</코드>

이동과 회전의 결합 

지금까지 이동과 회전을 각각 수행해 보았습니다.
만약에 이동 작업과 회전 작업이 모두 한 오브젝트에 필요하다면 어떻게 해야 할까요?
그런 경우가 필요하다면 바로 행렬의 곱셈 작업을 적용합니다.
그러면 이 두 가지 작업을 모두 표현 할 수 있습니다.
그런데 이 때 주의 할 부분이 있습니다.
행렬은 교환 법칙이 성립하지 않습니다.
즉 행렬 A, B 가 있을 때, A * B != B * A 라는 것입니다.

<코드>
matTranslation = ::D2D1::Matrix3x2F::Translation( 20.0f, 220.0f );         matRot = ::D2D1::Matrix3x2F::Rotation( -30.0f,
                                       D2D1::Point2F( 120.0f, 320.0f ) ); matTM = matTranslation * matRot;            
::g_ipRT->SetTransform( matTM );                          
::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea );     

 
matTranslation = ::D2D1::Matrix3x2F::Translation( 300.0f, 220.0f );         matRot = ::D2D1::Matrix3x2F::Rotation( -30.0f, 
                                       D2D1::Point2F( 400.0f, 320.0f ) );
matTM = matRot * matTranslation;                        
::g_ipRT->SetTransform( matTM );
::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea ); 
</코드>

이 코드가 우리의 샘플에서 두 번째와 세 번째 그림의 차이를 보여주는 것입니다.
두 번째 그림은 이동을 한 후에 회전 작업을 수행한 것이고,
세 번째 그림은 회전 작업을 수행한 후에 이동 작업을 수행한 것입니다.  

실제로 우리가 수행하는 모든 변환은 좌표계 변환입니다.
위에서 우리가 했던 변환은 모두 실제로 오브젝트들의 좌표계를 변환시켜서 얻은 결과물들입니다.
이 개념들은 분명히 이해하기 어려운 부분들입니다.
굳이 이렇게 어려운 부분까지 이해하실 필요는 없습니다.
샘플을 올려드리니, 수치를 바꿔보면서 여러 결과들을 눈으로 확인해 보시기 바랍니다.^^

 

MatrixSample.zip

Direct2D 리소스( Resource ) 기본 개념

Direct2D 에서 리소스라는 것은 단지 메모리를 의미합니다.

그 메모리는 지오메트리(Geometry)나 비트맵 이미지가 될 수도 있습니다.

즉, 이들 리소스는 메모리들이 추상화 된 일종의 개념적인 분류들입니다.

이들 리소스를 처리해서 모니터에 최종적으로 보여주는 것이 Direct2D의 역할입니다.

이전 까지 사용되던 GDI 도 바로 이런 역할을 하는 것입니다.

하지만, GDI와 Direct2D 는 리소스 처리 방식이 완전히 다릅니다.

앞선 시간을 통해서, GDI는 CPU만을 활용한다고 꾸준히 언급했습니다.

반면에, Direct2D는 CPU와 GPU를 동시에 활용합니다.

CPU와 GPU를 동시에 활용하기 때문에,

리소스들도 이들에 맞게 추상적으로 재분류 되어야 합니다.

Direct2D는 이 리소스들을 크게 두 가지 형태로 분류합니다.

바로 디바이스 독립적인 리소스( device-independent resource )와

디바이스 의존적인 리소스( device-dependent resource )로 분류하고 있습니다.

이들 두 리소스들은 모두 ID2D1Resource 인터페이스를 상속받습니다.

디바이스 독립적인 리소스

디바이스 독립적인 리소스라고 하는 것은 CPU에 의해서 처리되는 리소스를 의미합니다.

단어 자체에서 볼 수 있듯이,

이들 리소스는 사용자의 그래픽 하드웨어와 상관없는 처리 결과를 보장합니다.

뒤에서 살펴보겠지만, 지오메트리를 표현하는 인터페이스들이 여기에 속합니다.

( 조금 더 정확히 나열하면, ID2D1DrawingStateBlock, ID2D1Factory, ID2D1Geometry,

ID2D1GeometrySink, ID2D1SimplifiedGeometrySink, ID2D1StrokeStyle 등이 여기에 속합니다. )

아래는 이런 디바이스 독립적인 리소스들의 계층구조를 보여주는 그림입니다.

디바이스 의존적인 리소스

반면에 디바이스 의존적인 리소스는 GPU에 의해서 처리되는 리소스를 의미합니다.

사용자들이 가지고 있는 그래픽 하드웨어들은 매우 다양하기 때문에, 그 기능들을 모두 동일한 방식으로 처리하는 것이 쉽지 않습니다.

( 각각의 하드웨어마다 성능이나 명령어들이 모두 차이가 나기 때문이겠죠..^^ )

즉, 이들은 사용자의 하드웨어들에 따라서 결과가 차이가 날 수 있습니다.

이 차이라는 것은 눈으로 확인 가능한 차이를 얘기하는 것이 아니라,

그래픽 하드웨어들이 생성하는 명령어들과 성능 등과 같은 차이를 얘기하는 것입니다.

우리가 보는 모니터는 그래픽 하드웨어들이 생성한 명령어들의 최종적인 결과입니다.

리소스들도 바로 이 그래픽 하드웨어의 영향을 받아서 결과가 생성되는 것입니다.

앞서 우리가 화면에 렌더링 하기 위해서 만들었던 렌더타겟이나 브러시, 이미지 같은 리소스들은 모두 여기에 속합니다.

아래의 그림은 디바이스에 의존적인 리소스들의 계층구조를 표현하는 그림입니다.

Direct2D는 리소스 처리 방식은 되도록이면 GPU를 활용합니다.

GPU 처리가 불가능하다면, 자동적으로 CPU로 처리하게 됩니다.

GPU를 활용하는 리소스라면, 더욱 높은 품질로 빠르게 처리할 수 있습니다.

이들 리소스에 대한 설명은 다음 시간부터 차근히 살펴보겠습니다.^^

 

첫 번째 Direct2D 프로그래밍~  

지난 시간을 통해서 Direct2D의 필요성에 대해서, 제가 열심히(?) 언급해 드렸습니다.^^

이번 시간에는 Direct2D 프로그래밍의 세계에 대해서 들어가기 전에,

간단하게 프로그램을 작성해 볼 것입니다.

부끄럽지만, 저는 박식한 이론 내용 없이도 많은 프로그래밍 작업을 했었습니다.^^

그 만큼, 직접 프로그램을 작성하면 쉽게 이해할 수 있는 부분이 많이 있을 것입니다.

기본적으로 Direct2D는 2차원 그래픽을 만들기 위한 API입니다.

기존의 GDI를 이용한 프로그램의 일부분을 Direct2D로 대체를 하는 것만으로도 성능을 향상시킬 수 있습니다.

기본적으로 Direct2D로 작업하는 순서는 다음과 같습니다.

1. Direct2D 팩토리를 생성한다.
2. 팩토리에서 렌더타겟을 생성한다.
3. 렌더타겟에서 리소스들을 생성한다.
4. 생성 되어진 리소스들을 이용해서 그리기 작업을 수행한다.

Direct2D의 모든 작업은 위의 순서를 따릅니다.

이제 이들 순서를 어떻게 API로 표현하는지 살펴보겠습니다.

화면 작업을 위해 준비하기

첫 번째로 작성해볼 프로그램은 특정 색상으로 화면을 채우는 작업을 하는 것입니다.

먼저 마법사로 프로젝트를 생성하고, "stdafx.h" 헤더파일에 Direct2D와 관련된 선언을 추가시켜주기 바랍니다.

위의 내용은 Direct2D와 관련된 라이브러리와 헤더파일을 선언해 준 것입니다.

그리고 작업을 수행할 .cpp 파일에 전역 변수를 두 개 선언합니다.

Direct2D 프로그래밍을 위해서 가장 먼저 해야 하는 일은 ID2D1Factory 를 생성하는 일입니다.

D2D1CreateFactory()의 첫 번째 인자는 멀티 스레드 지원 여부를 설정합니다.

이번 내용에서는 싱글 스레드만을 사용합니다.( 멀티스레드 어려워요~~)

두 번째 인자는 팩토리가 생성되어서 결과를 반환 받을 수 있는 팩토리 포인터를 넘겨줍니다.

이것이 성공하면, Direct2D 와 관련된 작업을 할 수 있게 됩니다.( 참~~ 쉽죠잉!! )

우리가 만들려고 하는 프로그램이 화면에 어떤 내용을 그리는 것입니다.

화면에 무엇인가를 그린다는 개념은 하드웨어 입장에서 봤을 때는 메모리에 값을 쓰는 것입니다.

여러분들이 보고 있는 모니터 화면은 거대한 메모리에 색상 값이 기록되어 있는 것입니다.

이번에 할 일은 바로 이 메모리 영역을 생성하는 일입니다.

Direct2D의 가장 큰 장점이 바로 이 메모리 영역에 값을 기록하는 작업( 이하 렌더링 )이

GDI를 이용하는 것보다 훨씬 빠르다는 것입니다.

왜냐하면, 바로 이 메모리 영역이 그래픽 카드에 있기 때문입니다.

그리기 명령을 수행할 메모리 영역을 생성하기 위해서 다음과 같이 코딩을 합니다.

바로 이 메모리 영역을 렌더타겟( RenderTarget ) 이라 합니다.

CreateHwndRenderTarget() 의 첫번째 인자는 화면에 대한 정보를 설정합니다.

픽셀 포맷이나 DPI 등의 많은 플래그와 옵션이 있지만, 현재는 디폴트 정보로 넘겨주었습니다.

두 번째 인자는 하드웨어 가속을 받는 렌더링에 대한 옵션을 설정합니다.

간단하게 크기 정보만 넘겨주는 것으로 마무리했습니다.

마지막으로는 이 API 호출이 성공했을 때 리턴되어지는 렌더타겟의 포인터를 저장할 변수를 넣어주었습니다.

이렇게 함으로써 간단하게 우리는 하드웨어 가속을 받을 수 있는 렌더타겟을 생성할 수 있습니다.

옵션이나 인자에 대한 설명을 충분히 드리면 좋겠지만, 너무 많습니다.^^

중요한 인자나 옵션에 대해서만 설명 드리는 점 양해 부탁 드립니다.

이제 우리는 렌더타겟을 가지고 있으니 이 메모리 영역에 값을 쓰면, 모니터로 결과를 확인할 수 있습니다.

윈도우가 화면에 그리기 위해서 발생하는 메시지가 WM_PAINT 입니다.

저는 이 메시지를 처리해서, 원하는 색상으로 렌더타겟의 색상을 채울 것입니다.

다음과 같이 코딩을 합니다.

이번 코드를 실행시키면, 파란색으로 칠해진 윈도우 프로그램을 만나게 될 것입니다.

더 정확하게 얘기하면, 메모리 영역( 렌더타겟 )이 파란색 색상데이터로 채워진 것입니다.

샘플을 올려둡니다.( SimpleDraw.zip )

도움이 되셨으면 좋겠습니다.^^

 


GDI vs Direct2D 비교해 보기.  

제가 아무리 Direct2D가 GDI보다 좋다고 혼자 말하는 것 보다, 여러분들이 직접 결과를 확인하는 것이 좋습니다.

그래서 이번에는 GDI와 Direct2D를 이용해서 타원을 렌더링 할 것입니다.

그리고 결과로 나오는 것을 보고, 여러분들이 직접 확인해 보기 바랍니다.

GDI 로 작업하기.

GDI를 이용하는 것은 전통적인 윈도우 프로그래밍에서 사용되던 방식입니다.

주변에서 이와 관련한 많은 내용들을 접할 수 있어서, 내용에 대한 자세한 설명은 생략하겠습니다.

Windows 운영체제에서 모든 드로잉(Drawing) 작업은

디바이스 컨텍스트 오브젝트( device-context object )를 통해서 실행이 됩니다.

이를 줄여서 'DC' 라고 줄여서 얘기합니다.( 다 아시죠? ^^ )

DC란, 윈도우즈 운영체제에서 컴퓨터 모니터나 프린터에 그리기 명령을 수행하기 위한

여러 속성 정보들을 구조화한 데이터입니다.

우리는 Windows API를 이용해서 DC를 이용한 그리기 작업을 수행할 수 있습니다.

DC를 이용하면, 우리는 어떠한 하드웨어 장치와는 관련이 없이 공통된 형식으로 화면에 그릴 수 있습니다.

이것이 가능한 이유는 DC는 CPU가 그리기 작업을 처리해 주기 때문입니다.

<코드>

HDC hDC;

HBRUSH hBrush,

hOldBrush;

if (!(hDC = GetDC (hwnd)))

return;

hBrush = CreateSolidBrush (RGB(0, 255, 255));

hOldBrush = SelectObject (hDC, hBrush);

Rectangle (hDC, 0, 0, 100, 200);

SelectObject (hDC, hOldBrush);

DeleteObject (hBrush);

ReleaseDC (hwnd, hDC);

</코드>

위의 코드는 간단히 DC를 이용해서 사각형을 그리는 코드입니다.

위에서 보는 것과 같이,

GetDC() 라는 API 를 통해서 현재 윈도우 애플리케이션에 대한 DC를 얻어서 작업을 수행합니다.

DC와 관련된 코드를 살펴보면, SelectXXX() 형식을 자주 볼 수 있습니다.

이는 DC가 일종의 상태 정보를 유지하고 있기 때문입니다.

예를 들면, 빨간 펜과 파란 펜으로 두 개 동시에 작업을 할 수는 없습니다.

하나의 펜으로 먼저 작업을 한 후에, 작업한 펜을 제거하고 다음 펜을 선택한 후에 작업을 해야 한다는 얘기입니다.

이점을 잘 고려해서 작업을 해야 하는 것이죠.

이것은 DC를 이용하는 하나의 방법일 뿐입니다.

만약 WM_PAINT 메시지 내부에서 처리하고자 한다면, 아래와 같은 구조를 취할 수 있습니다.

<코드>

PAINTSTRUCT ps;

case WM_PAINT :

hdc = BeginPaint(hWnd, &ps);

{

DoSomething()

}

EndPaint(hWnd, &ps);

break;

</코드>

PAINTSTRUCT 는 내부에 DC 관련 멤버 변수를 가지고 있습니다.

BeginPaint()를 통해서 DC 정보가 채워지게 되는 것입니다.

이러한 DC를 활용하는 것이 GDI 를 이용하는 것의 핵심입니다.

이와 관련된 내용을 더 언급하고 싶지만, 이 정도에서 정리하겠습니다.

이미 많은 분들이 저 보다는 훨씬 많은 지식을 가지고 있을 것이며,

관련 자료들도 이미 훌륭히 찾아 볼 수 있기 때문입니다.^^

우리가 지금 하려는 것은 GDI와 Direct2D의 비교입니다.

프로젝트를 만들고, 시스템을 셋팅하시기 바랍니다.( Direct2D 오브젝트도 생성해 주어야 합니다. )

WM_PAINT 메시지에 이 두 가지 방법을 사용해서 렌더링 하는 함수를 호출했습니다.

( 제가 정의한 함수들입니다. )

먼저, Direct2D를 이용해서 타원을 렌더링 하는 코드를 살펴보겠습니다.

이 방법은 뒤에도 설명을 하겠지만, Direct2D에서 DC를 활용하는 렌더링 방법입니다.

몇몇 생소한 개념들이 보이지만, 이들에 대해서는 차후에 설명을 할 것입니다.

GDI를 활용해서 타원을 렌더링 하는 코드는 다음과 같습니다.

자, 이제 이 둘의 결과는 예제 코드를 실행시키면, 다음과 같이 확인할 수 있습니다.

이는 타원의 일부를 캡쳐한 화면입니다.

좌측은 Direct2D의 결과이고, 우측은 GDI를 이용한 결과입니다.

겉으로 보기에는 차이가 없어 보이지만,

자세히 보면 우측의 경우는 울퉁불퉁한 계단 현상이 심한 것을 알 수 있습니다.

( 잘 보이지 않는다면, 샘플을 실행시켜보시기 바랍니다.^^ )

분명히 같은 기능을 하는 두 함수이지만, 결과에서는 이렇게 차이가 납니다.

샘플 파일( BasicRender.zip )을 같이 첨부했으니, 도움이 되셨으면 좋겠습니다.^^

BasicRender.zip

SimpleDraw.zip

우리가 예전에 생각했던 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 는 10⁹ Flops입니다. )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'윈도우즈 7 운영체제가 왜 좋은 것일까?'

이 물음에 프로그래머라면, 어떤 대답을 할 수 있을까요?

여러 가지 대답들이 존재하겠지만, 그 중에 하나인 부분을 지금부터 진행하려 합니다.

지금부터 언급하는 내용은 모니터에 무엇인가를 표현하는 것과 관련이 있습니다.

즉, 드로잉( Drawing ) 작업에 관한 내용입니다.

혹시 여러분들은 'GDI' 와 'DirectX' 이들 단어에 대해서 들어본 적이 있습니까?

컴퓨터를 가지고 작업을 경험했던 이들이라면, 들어봤을 법한 용어들입니다.

여러분들이 사용하는 컴퓨터의 모니터는 어떤 과정을 거쳐서 우리에게 전달되는 것일까요?

분명히 이것은 하드웨어적인 영역일 수도 있습니다.

조금 더 애플리케이션 프로그래머 관점으로 이 호기심을 확장해 보겠습니다.

'어떻게 하면 모니터 화면을 제어할 수 있을까?'

'어떻게 하면 내가 원하는 모습으로 모니터의 화면에 나타낼 수 있을까?'

'윈도우즈 운영체제에서 화면을 무엇인가를 그리는 시스템은 어떻게 구성되어 있을까?'

위의 그림은 XP를 포함한 이전 세대의 Windows 운영체제( 이하 XP세대 )가

화면을 제어하는 시스템 구조입니다.

즉, 하드웨어 추상화 계층이라고도 합니다.

XP세대의 운영체제에서는 화면에 무엇인가를 그리기 위해서는

GDI 와 DirectX API, 이 두 가지를 통해서 제어가 가능했습니다.

최종적으로 GDI 와 DirectX API 는 드라이버와 통신을 하면서,

우리의 명령어를 처리해서, 하드웨어로 결과를 보내주게 됩니다.

그런데 왜 동일한 일을 하는 구조가 2개씩이나 존재하는 것일까요?

그것은 컴퓨터의 탄생과 발전이 예상을 벗어났기 때문에 생긴 일입니다.

초창기 컴퓨터의 구조는 굉장히 간단했습니다.

아래의 그림을 살펴보겠습니다.

컴퓨터라는 것은 결국 CPU 에게 연산을 부탁해서 처리된 결과를 메모리에 저장을 합니다.

그리고 이들에 대한 제어를 우리는 I/O 장치들을 통해서 수행하고 확인합니다.

초창기 컴퓨터는 프로세싱 유닛이 CPU 오직 하나였습니다.

그래서 API들은 프로세싱 유닛이 CPU 하나임을 전제로 개발되었습니다.

우리가 지금 배우고 있는 Windows API 역시 CPU가 한나인 경우에

포커스를 두어서 개발되었던 API 였습니다.

하지만 오늘날의 컴퓨터는 어떠합니까?

컴퓨터에서 CPU의 수는 2개 이상이고, 앞으로도 그 개수는 증가할 것입니다.

거기다 이제는 프로세싱 유닛이 CPU 뿐만 아니라, GPU 도 활용이 가능한 시대입니다.

메모리는 또 얼마나 발전하고 있습니까?

굉장히 방대한 용량의 메모리를 여러 개 꽂아서 사용하고 있으며,

그래픽 카드에는 비디오 메모리라는 것도 별도로 존재합니다.

컴퓨터의 큰 구조는 변한 것이 없지만, 기능이 점점 세분화 되고 있는 것입니다.

이런 하드웨어들의 변화들은 결국 API를 만드는 사람들의 개발 패러다임을 변화시킵니다.

그러한 패러다임의 변화는 애플리케이션 개발자들에게 새로운 학습을 요구합니다.

즉, 여러분들은 그런 변화에 맞추어서 더 많은 공부를 해야 하는 것입니다.T.T

초창기 Windows 운영체제 차원에서 화면에 그리기 위한 방법은,

GDI 관련 API 를 사용하는 것뿐 이였습니다.

운영체제 차원에서 모든 것을 관리하고 싶었기 때문에,

MS측에서도 별다른 문제를 느끼지 못했을 것입니다.

그런데 예측을 빗나간 부분이 있었는데, 그것은 게임 이였습니다.

게임 개발자들은 GDI 라는 훌륭한 모델이 있음에도 불구하고,

여전히 MS-DOS 기반으로 화면을 제어하고 있었던 것 이였습니다.

이유는 간단했습니다.

GDI 를 활용하면 분명히 쉬운 방법으로 개발을 할 수 있었지만,

DOS 기반의 방법보다 상대적으로 느렸습니다.

MS-DOS를 활용하면 하드웨어를 개발자가 직접 제어할 수 있기 때문에,

Windows 운영체제의 관리를 받는 GDI 보다는 훨씬 빨랐던 것입니다.

( 이 당시만 해도, CPU 사이클을 줄이는 것이 큰 최적화 이슈였습니다. )

MS-DOS를 빨리 벗어나려 했던 MS 입장에서는 적지 않은 충격(?)을 받게 됩니다.

물론 이런 문제는 게임뿐만 아니라,

멀티미디어 관련 개발에서도 나타났던 문제였습니다.^^

그렇게 해서 등장한 대한이 바로 DirectX 입니다.

처음 명칭이 GameSDK 였음에서 알 수 있듯이 게임 개발자를 위한 API 였습니다.

이 DirectX는 Windows 95 운영체제부터 추가되어서 활용되기 시작했습니다.

어쩌면, GDI 모델을 완전히 수정할 여유나 계획은 없었을지도 모릅니다.

어찌되었든 현재까지 GDI 와 DirectX는 이렇게 공존하면서 XP 운영체제까지 이르게 되었습니다.

XP 세대까지는 화면에 무엇인가를 그리는 작업을 기준으로 봤을 때는,

애플리케이션은 DirectX를 활용하는 애플리케이션과 GDI를 활용하는 애플리케이션으로 나눌 수 있었습니다.

GDI( Graphics Device Interface ) 라는 용어에서 보듯이,

일반적인 윈도우 애플리케이션에서 모니터 화면에 무엇인가를 출력하기 위해서는

GDI 라는 것을 이용해서 구현합니다.

이는 2D API 라고 볼 수 있습니다.

GDI를 통해서 애플리케이션과 디바이스 드라이버( Device driver ) 사이를
제어할 수 있습니다.

XP 세대에서 화면에 보여지는 대부분의 구성은 바로 이 GDI 를 활용한 것입니다.

GDI는 소프트웨어적으로 처리되기 때문에,

그래픽 하드웨어와 상관없이 처리할 수 있다는 큰 장점이 있습니다.

즉, CPU가 그래픽 처리에 필요한 연산을 수행합니다.

일반적인 윈도우 애플리케이션은 그래픽 하드웨어를 직접적으로 접근( access )할 수 없습니다.

반드시 GDI를 통해서 디바이스 드라이버에 접근해야 합니다.

GDI 의 최대 강점은 바로 디바이스 독립적( device-dependent ) 이라는 것입니다.

세상의 모든 PC가 동일한 사양을 갖추고 있으면 좋겠지만,

PC들은 저마다 다른 성능과 사양을 갖추고 있기 때문에,

이를 모두 제어하는 것은 굉장히 어렵고 힘든 일입니다.

하지만, GDI 코드는 어떠한 장치에 상관없이 화면에 공통된 그래픽을 표현할 수 있습니다.

왜냐하면 CPU가 이들에 대한 처리를 모두 수행하기 때문입니다.

GDI는 Windows 운영체제의 매우 오래된 기술 중 하나이며,

현재까지도 가장 널리 이용되는 윈도우 그래픽 API 라고 할 수 있습니다.

하지만 최근의 멀티코어 환경과 GPU의 발전은 많은 변화들을 가져왔으며,

GDI도 이러한 변화에 예외가 될 수 없었습니다.

급기야 이제는 DirectX가 GDI를 서서히 대체해 나가는 방향으로
가는 길이 정해지고 말았습니다.T.T

Good-bye!! GDI~~

DirectX11의 파이프라인은 앞선 시간에서 우리는 꾸준히 보았습니다.
복습의 의미에서 이번에는 http://www.realtimerendering.com 에 정의된 Direct3D 의 파이프라인입니다.


< Direct3D 10 pipline >


< Direct3D 11 pipline >

우리가 그래픽스에서 사용하는 폴리곤은 굉장히 복잡한 방식으로 처리가 됩니다.
많은 스테이지를 통해서 결국 우리는 화면 픽셀로 변환된 최종 결과를 확인하게 되는 것입니다.
그 과정 속에서 Direct3D 9에서는 Vertex와 Pixel 을 조작할 수 있도록 변화되어 왔습니다.
Direct3D 10 은 여기에 Geometry 까지 조작할 수 있도록 프로그래머들에게 개방되었습니다.
Direct3D 11 은 무려 3개의 스테이지가 추가되었습니다.
Hull Shader, Tessellator, Domain Shader 가 바로 그것들입니다.

이 중에 프로그래머가 제어하는 부분은 Hull / Domain Shader 이며,
Tessellator 의 경우에는 하드웨어가 직접 처리하게 됩니다.

테셀레이션을 언급하면서 가장 많이 나오는 주제는 현재 LOD( Level of Detail ) 처리 이지만,
정확하게 테셀레이션이 필요한 이유는 글인 http://vsts2010.net/331 을 통해서 확인할 수 있습니다.

현재 그래픽 파이프라인에서 테셀레이션 작업은 현재 옵션으로 설정되어 있습니다.
여러분이 이 기능을 사용하기 원하지 않는다면, 이들을 활성화 시키지 않으시면 됩니다.
그렇게 된다면, 기존의 파이프라인과 동일한 방식으로 Vertex 데이터를 처리하게 됩니다.


< Hull Shader >

Hull Shader 는 테셀레이션 작업의 시작입니다.
하지만, 실제로 프로그래머의 시작은 Vertex Shader 입니다.
DirectX9에서 VertexShader 는 World-View-Projection 변환을 수행하는 것이 가장 큰 목적이였습니다.
DirectX11에서 VertexShader 의 목적은 Hull Shader 로의 데이터를 전달하는 것입니다.
즉, 테셀레이션이 목적인 경우에는
DirectX11에서 VertexShader 스테이지에서 World-View-Projection 을 수행해서는 안됩니다.
테셀레이션 작업시 VertexShader 에서 처리되는 Vertex는 실제 우리가 사용하는 데이터가 아닙니다.
우리는 VertexShader 의 입력으로 들어오는 데이터를 모아서,
많은 수의 Vertex를 새롭게 생성시켜야 합니다.
그래서 테셀레이션 작업시 VertexShader 스테이지에서는 Vertex를 월드 변환까지만 수행합니다.

Hull Shader 에서는 '폴리곤을 어떻게 분할할 것인가?' 와 '폴리곤을 얼마나 분할할 것인가?' 를 결정합니다.
가장 단순한 형태로 이 Hul Shader의 기능을 표현하면 다음과 같습니다.



위의 그림은 MSDN 의 그림입니다.

Hull Shader 는 두 가지의 작업을 동시에 수행합니다.
그것은 제어점( Control Point ) 를 생성하는 작업과 Patch Constant Data 를 계산하는 작업입니다.
이들 작업은 병렬적으로 수행되게 됩니다.
HLSL 코드는 실제로 드라이버 수준의 하드웨어 명령어를 생성하게 되는데,
이 때, 병렬처리가 가능한 형태로 변환되게 됩니다.
이는 Hull Shader 가 빠르게 동작할 수 있는 중요한 이유이기도 합니다. 
 
Hull Shader 의 입력으로 들어오는 제어점( Control Point )들은
낮은 차수의 면을 표현하는 정점들입니다.
이를 높은 차수의 면을 표현하는 제어점들로 만들어 내게 됩니다.
이 때 생성된 제어점들은 Tessellator 스테이지에서 사용되는 것이 아니라,
그 다음 스테이지인 Domain Shader 에서 사용됩니다.

    // Insert code to compute Output here.    
    return Output;
}

위의 Hull Shader 는 동작 방식을 설정합니다.
몇몇 정의된 값들을 셋팅해 주면, 이는 테셀레이션 작업을 하는 동안에 사용되게 됩니다.
즉, 위의 셋팅들은 '폴리곤을 어떻게 분할할것인가?' 에 준하는 프로그램 코드라 할 수 있습니다.

이제 남은 것은 '폴리곤을 얼마나 분할할 것인가?' 입니다.
이는 PatchConstantFunc 을 통해서 병렬적으로 처리된다고 앞서 설명을 했습니다.
이곳에서는 Tessellation Factor 를 계산하게 되는데, 그 결과에 따라서 컬링 작업이 실행됩니다.
( 이 값이 0 이하의 경우에는 더 이상 처리가 필요하지 않습니다. )
이 작업을 하는 함수를 우리는 직접 작성해서,
 위의 [patchconstantfunc("SubDToBezierConstantsHS")] 처럼 설정해 주면 자동적으로 동작합니다.
MSDN 에 나와있는 PatchConstantFunc의 기본적인 형태는 다음과 같습니다.

#define MAX_POINTS 32

// Patch Constant Function
HS_CONSTANT_DATA_OUTPUT
SubDToBezierConstantsHS( InputPatch<VS_CONTROL_POINT_OUTPUT, MAX_POINTS> ip,
                                         uint PatchID : SV_PrimitiveID )
{ 
    HS_CONSTANT_DATA_OUTPUT Output;

    // Insert code to compute Output here    
    return Output;
}

이 PatchConstantFunc 의 결과에 바로 '폴리곤을 얼마나 세밀하게 분할할 것인가?' 에 대한 정보들이 있습니다.

// Output patch constant data.
struct HS_CONSTANT_DATA_OUTPUT
{
    float Edges[4]        : SV_TessFactor;
    float Inside[2]       : SV_InsideTessFactor;
    ...
};

위의 경우의 결과 구조체는 사각형을 분할한 경우이며,
우리가 주로 사용하는 삼각형 분할의 경우에는 다음과 같을 것입니다.

// Output patch constant data.
struct HS_CONSTANT_DATA_OUTPUT
{
    float Edges[3]        : SV_TessFactor;
    float Inside       : SV_InsideTessFactor;
    ...
};

지금까지 Hull Shader의 기본적인 개념과 역활에 대해서 언급해 드렸습니다.
이렇게 얻어진 결과는 테셀레이터로 전달되게 됩니다.
세부적인 Hull Shader 의 작성은 이후의 시간들을 통해서 살펴볼 예정입니다.
( 현재 본 글들은, 개념 위주의 설명에 포커스를 두고 있습니다. ^^ )

앞선 시간을 통해서 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];

}