Visual Studio 2010 공식 팀 블로그 @vsts2010

한주만 쉰다는 것이, 죄송스럽게도 긴 휴식을 가지고 다시 등장습니다.
지난 시간까지 DirectX11 의 기본 API 를 간단히 언급했었습니다.
쉬는 사이에 안승근님께서 DirectX11과 관련된 기본적인 API 에 대한 글을 작성하기 시작하셨기 때문에
앞으로 기본적인 API 위주로 내용을 언급하지 않습니다.


< DirectX9 까지의 특징 >

DirectX는 Windows95 운영체제와 함께 처음 공개된 후에, 
어느덧 현세대까지 발전을 거듭했습니다.( 세월 참 빠르죠? ^^ )

너무 오랜 시간 전은 저도 잘 몰라서 DirectX7 버전부터의 가장 큰 변화를 하나씩 언급해 보겠습니다.
DirectX7 버전부터 변환과 라이팅(T&L) 을 위한 GPU가 활용되기 시작했고,
DirectX8 버전부터는 'Shader' 라는 GPU 를 활용한 프로그래밍이 도입되어서
현재 가장 개발자에게 주목받는 영역이 되었습니다.
개인적인 견해차이가 있겠지만, 저는 DirectX9 까지의 발전 과정 중에
가장 큰 변화로 바로 이 'GPU 의 활용'이라고 생각하고 있습니다.

그러면 DirectX9 까지의 발전에서 변심(?)하지 않고,
저희를 언제나 반갑게(?) 맞이해 주었던 부분은 어떤 것이 있을까요? ^^
그것은 바로 API 를 설계할 때 항상 싱글 코어를 고려하고 만들었다는 것입니다.

또 다른 부분은 API 자체가 GPU 의 정점 처리 기능을 규정하고 있다는 것입니다.
언제나 '정점입력-->래스터라이즈-->픽셀처리-->디스플레이' 라는 큰 단계를
API 레벨에서 정의하고 있었습니다.
그 동안 우리는 이것은 Fixed pipeline 이라고 불렀습니다.
아래 이미지는 DirectX8 & 9 의 파이프라인입니다.

이미지 출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html

사실 DirectX8 & 9 는 크게 차이가 없습니다.
파이프라인상에서 굳이 찾아야 한다면, 텍스쳐 메모리를 버텍스 쉐이더 단계에서도
참조할 수 있다는 정도일 뿐입니다.

간단히 제가 하고 싶은 말을 정리해 보자면,
'싱글코어 기반의 DirectX 의 시대는 이제 역사의 뒤로 사라지게 될 것이며,
GPU 는 더욱 복잡한 기능을 요구하게 될 것이다' 정도로 정리하겠습니다.
( 예언은 아니고, 이미 이렇게 되고 있는 상황이죠..^^ )


< 새로운 시대를 여는 DirectX11 >

아래는 DirectX11 의 파이프라인입니다.
잘 보시라고 그냥 크게 띄웁니다..^^

이미지 출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html


DirectX11 의 가장 큰 특징을 저는 크게 3가지로 나누어 보았습니다.

• GPU Tessellation.
• Compute Shader.
• Multi-threaded rendering.

사실 DirectX11 의 많은 부분은 X-Box360 에서 이미 사용되고 있습니다.
X-Box360 의 ComputeShader 지원은 모르겠으나, 나머지 두가지는 지원하고 있습니다.
X-360을 언급한 이유는 이들 기능이 이미 어느 정도 검증을 받은 기능이라는 점을 강조하고 싶어서 입니다.
( 물론 최신 버전이기 때문에 더 빨라지고, 더 좋아진 부분이 많습니다.^^ )

DirectX11 의 큰 패러다임은 '놀지마' 입니다.
이제는 멀티코어(CPU)와 GPU에게 최대한 많은 일을 시킬 수 있는 구조로
하드웨어를 구성했고, 그것을 기반으로 해서 런타임과 API 를 설계하고 만들었습니다.

DirectX9 까지는 API 가 변화를 주도했다면,
이제는 DirectX API 변화를 하드웨어가 주도하고 있다고 볼 수 있습니다.
그러다보니 자연스럽게 API 도 더욱 하드웨어에 가깝게 설계되었습니다.
대표적으로 OutputMerge 를 지칭하는 OMxxxx 계열과
InputAssembler 를 지칭하는 IAxxxx 계열 등이 있습니다.

혹시 DirectX8-->9 로 포팅 작업을 하셨던 분들이 이 글을 읽으시는지 모르겠습니다만,
8-->9 의 변화는 API 차원에서 변화가 컸기 때문에 매우 단순했습니다.
하지만 이제는 하드웨어가 크게 변했기 때문에,
단순 포팅 작업 정도로 생각하시면 큰 오산입니다.
물론 단순히 API 만 교체해도 성능 향상을 얻을 수 있습니다.
DirectX11 은 하드웨어 오버헤드를 줄이기 위해 많은 최적화 작업을 수행했다고 합니다.

새로운 DirectX 의 시대가 왔다는 느낌이 드시나요? ^^

PPL에서 제공하는 알고리즘을 사용하여 병렬로 작업을 실행할 때 각 작업에서 접근하는 공유 리소스는 스레드 세이프 하지 않기 때문에 lock을 걸어서 공유 리소스를 보호해야 합니다.

그러나 lock을 건다는 것은 번거롭기도 하며 성능에 좋지 않은 영향을 미칩니다.

가장 좋은 방법은 공유 리소스에 lock을 걸지 않아도 스레드 세이프한 것이 가장 좋습니다.

combinable은 바로 위에 언급한 문제를 해결해 주는 것입니다. 모든 상황에 다 사용할 수 있는 것은 아니지만 특정 상황에서는 combinable을 사용하면 lock을 걸지 않아도 공유 리소스를 스레드 세이프하게 접근 할 수 있습니다.

combinable

combinable은 병렬로 처리하는 작업에서 각 작업마다 계산을 실행한 후 그 계산 결과를 통합할 때 사용하는 재 사용 가능한 스레드 로컬 스트레지를 제공합니다.

combinable은 복수의 스레드 또는 태스크 간에 공유 리소스가 있는 경우에 사용하면 편리합니다. combinable는 공유 리소스의 접근을 각 스레드 별로 제공하여 공유 상태를 제거할 수 있습니다.

스레드 로컬 스트리지

스레드 프로그래밍을 공부하시면 스레드 고유의 로컬 스트리지를 만들어서 해당 스레드는 자신의 로컬 스트리지에 읽기,쓰기를 하여 다른 스레드와의 경합을 피하는 방법을 배울 수 있습니다.

combinable은 이 스레드 로컬 스트리지와 비슷한 방법입니다.

combinable의 메소드 설명

combinable::local : 현재 스레드 컨텍스트와 관련된 로컬 변수의 참조를 얻는다.

combinable::clear : 오브젝트로부터 모든 스레드 로컬 변수를 삭제한다.

combinable::combine : 제공하고 있는 있는 조합 함수를 사용하여 모드 스레드 로컬 계산의 set으로부터 최종적인 값을 만든다.

combinable::combinable_each ; 제공하고 있는 조합 함수를 사용하여 모든 스레드 로컬 계산의 set으로부터 최종적인 값을 만든다.

combinable은 최종 결합 결과 타입의 파라미터를 가지고 있는 템플릿 클래스입니다. 기본 생성자를 호출하면 기본 생성자와 복사 생성자 _Ty 템플릿 파라미터 형이 꼭 있어야합니다. _Ty 템플릿 파라미터 형이 기본 생성자를 가지지 않는 경우 파라미터로 초기화 함수를 사용하는 생성자로 오버로드 되어 있는 것을 호출합니다.

combinable을 사용하여 모든 작업에서 처리한 계산 결과 값을 얻을 때는 combine()을 사용하여 합계를 구하던가, combine_each를 사용하여 각 작업에서 계산한 값을 하나씩 호출하여 계산합니다.

< 예제 1. Combinable을 사용하지 않고 lock을 사용할 때 >

<예제 1>은 critical_section을 사용하여 TotalItemPrice 변수를 보호하고 있습니다.

그럼 <예제 1>을 combunable을 사용하여 구현해 보겠습니다.

< 예제 2. Combinable 사용 >

combinable을 사용하면 <예제 1>과 다르게 lock을 걸지 않아도 되기 때문에 훨씬 성능이 더 좋습니다. 다만 모든 곳에서 사용할 수는 없기 때문에 <예제 2>와 같이 어떤 계산의 최종 결과를 구할 때 등 사용할 수 있는 곳을 잘 찾아서 사용해야 합니다.

<예제 2>는 각 태스크에서 계산된 결과를 더하기 위해서 conbinable의 combine 멤버를 사용했지만 각 태스크의 결과를 하나씩 순회할 때는 conbinable의 combine _each 멤버를 사용합니다.

그리고 저는 <예제 2>에서 int를 combinable에 사용했지만 int 이외에 유저 정의형이나 STL의 list와 같은 컨테이너도 사용할 수 있습니다.

combinable에서 combine_each() 멤버나 combinable에서 STL의 list 컨테이너를 사용한 MSDN에 있는 예제는 아래와 같습니다.

 DirectX SDK(August 2009)에 포함된 'EmptyProject11'을 기준으로 기본 적인 DirectX세팅에 대해서 설명 하겠습니다.

 아래와 같이 DXUT의 일반적인 설정을 하면 상황에 이벤트에 따라 해당 함수를 호출합니다.
키보드가 눌리면 Onkeyboard가 호출되고, DXUTCreateDevice로 디바이스를 생성하면 'ModifyDeviceSettings'함수가 호출되는 등 기본적으로 필요한 골격을 제공하고 있습니다.

DXUTSetCallbackFrameMove( OnFrameMove );
DXUTSetCallbackKeyboard( OnKeyboard );
DXUTSetCallbackMouse( OnMouse );
DXUTSetCallbackMsgProc( MsgProc );
DXUTSetCallbackDeviceChanging( ModifyDeviceSettings );
DXUTSetCallbackDeviceRemoved( OnDeviceRemoved );

 DX9까지는 DX에 디파인된 버젼으로 어플리케이션에서 실행이 가능한 버젼인지 체크 후 버젼이 맞지 않으면 프로그램을 종료해 버렸습니다.
if( NULL == ( g_pD3D = Direct3DCreate9( D3D_SDK_VERSION ) ) )
     return E_FAIL;

 그러나 아래와 같이 초기화를 하면 어렵지 않게 각 버젼에 대해 깔끔하게 처리가 가능합니다.
여러개의 버젼을 세팅하는 것에 대해 저처럼 의아하게 생각하시는 분도 계실 것 입니다.
그러나 그저 DX9과 DX11을 같이 소스에 위치를 시키면, 하위 버젼에 대한 것들은 모두 알아서 삭제되고,
DX11의 콜백은 정상적으로 설정이 됩니다.(위 아래 순서를 바꿔도 상관 없이 이와 같이 동작 합니다.)

DXUTSetCallbackD3D9DeviceAcceptable( IsD3D9DeviceAcceptable );
DXUTSetCallbackD3D9DeviceCreated( OnD3D9CreateDevice );
DXUTSetCallbackD3D9DeviceReset( OnD3D9ResetDevice );
DXUTSetCallbackD3D9FrameRender( OnD3D9FrameRender );
DXUTSetCallbackD3D9DeviceLost( OnD3D9LostDevice );
DXUTSetCallbackD3D9DeviceDestroyed( OnD3D9DestroyDevice );

DXUTSetCallbackD3D11DeviceAcceptable( IsD3D11DeviceAcceptable );
DXUTSetCallbackD3D11DeviceCreated( OnD3D11CreateDevice );
DXUTSetCallbackD3D11SwapChainResized( OnD3D11ResizedSwapChain );
DXUTSetCallbackD3D11FrameRender( OnD3D11FrameRender );
DXUTSetCallbackD3D11SwapChainReleasing( OnD3D11ReleasingSwapChain );
DXUTSetCallbackD3D11DeviceDestroyed( OnD3D11DestroyDevice );

 첫번째 인자를 true로 설정하면 커맨드를 설정해 아래와 같은 기능을 사용 할 수 있습니다.
(각 버젼에 특화된 커맨드도 몇 가지 있습니다.)
'-fullscreen'=> 전체화면으로 설정
'-width:800 -height:600' => AppWindow의 넓이, 높이를 800x600으로 설정
(이 커맨드를 설정하면 DXUTCreateDevice의 화면 사이즈는 무시됩니다.)
 두번째 인자는 에러 메세지 박스 출력
 세번째 인자는 여분의 커맨드라인 파라메타세팅(default:NULL)
DXUTInit( true, true, NULL );

첫번째 인자가 true이면 전체 화면 모드에서 커서가 보이도록 설정.
두번째 인자가 true이면 전체 화면 모드에서 커서가 화면을 벗어나지 못하도록 설정.
(테스트 했을때 두개의 인자 모두 true와 false일때의 차이점을 느끼지 못했습니다.)
DXUTSetCursorSettings( true, true );

설정한 타이틀로 윈도우 생성
DXUTCreateWindow( L"EmptyProject11" );

 '하드웨어 레벨10'으로 디바이스를 생성
(Feature level관련은 조진현님의 글을 참고하시기 바랍니다.)
두번째 인자가 true이면 윈도우모드, false이면 풀스크린모드 입니다.
(테스트 했을때 false일때도 풀스크린 모드로 변경이 되지 않았습니다.)
세번째, 네번째 인자로 화면의 넓이 높이를 설정할 수 있습니다.
DXUTCreateDevice( D3D_FEATURE_LEVEL_10_0, true, 640, 480 );

DXUT 메인루프 실행
DXUTMainLoop();

 리턴되는 값으로 D3D초기화, 디바이스 상태 등을 알 수 있습니다.
'0'이면 정상이고, 그 이외의 값일경우 DX help파일에서 에러 내용을 확인하시기 바랍니다.
DXUTGetExitCode();

샘플을 실행하면, 예상대로 그저 윈도우안에 세팅된 타이틀과, 파란 화면만 덩그라니 출력됩니다.

첫 샘플 분석이기 때문에 최대한 간단한 함수까지 설명을 적었습니다.
다음 글 부터는 특이사항이 없는한 이번에 설명했던 함수에 대해서는 넘어가도록 하겠습니다.

 DXUTSetCursorSettings, DXUTCreateDevice함수의 설명과 테스트 결과가 다른 이유는 DirectX Help의 설명을 적었으나 테스트 결과 문서대로 동작하지 않았던 것 입니다.
 문제가 있는 것이 맞다면 다음 버젼에는 수정될 것으로 예상됩니다.

다음 글은 좀 더 화면에 보이는 것이 많은 것으로 올리도록 하겠습니다.

한국 마이크로소프트에서 주최하는 TECH DAY 2009 행사가 오픈하였습니다. 지난 Dev Days 2008 에 이어 새롭게 개최하는 행사입니다. TECH DAY 는 온라인으로 진행되며 다양한 주제로 동영상 세미나가 준비되어 있습니다.

http://www.techdays.co.kr/

이번 TECH DAY 는 새로운 플랫폼 시대를 대비하기 위한 개발자와 IT 전문가를 위한 컨퍼런스 입니다. 특히 온라인 컨퍼런스의 장점이라면 시간과 장소에 구애 받지 않고 언제나 오픈되어 있는 컨퍼런스라는 점입니다.

트랙은 키노트와 개발 트랙, IT 전문가 트랙으로 구성되어 있으며, 특히 개발 트랙과 IT 전문가 트랙은 굉장히 많은 동영상 콘텐트가 준비되어 있습니다. 그리고 개발 플랫폼 트랙은 제가 몸담고 있는 VSTS 2010 팀에서 전체 세션을 맡았습니다.    

이번 TECH DAY 2009 행사에 많은 참여를 부탁드립니다. 경품도 많이 준비가 되어있으니 경품 이벤트에도 도전해 보세요.

우선 설치해서 잠깐 둘러본 결과, 가장 우려했던 IDE 의 성능 문제는 의외로 빨랐습니다. 어떤 부분은 Visual Studio 2008 보다 더 빨랐고, 기본적인 대부분의 동작의 실행 속도는 굉장히 만족스럽습니다.

마이크로소프트 Visual Studio 개발팀도 이 점을 인지하고 개선하려고 상당히 노력한 흔적이 엿보입니다. 기존 CTP 와 Beta 1 에서 기어가는 듯한 IDE 가 느렸던 문제는, Beta 2 버전에서는 걱정하지 않으셔도 될 것 같습니다. 체감적으로 Visual Studio 2008 보다 느리지 않네요.  

Visual Studio CTP 와 Beta 버전에 익숙해졌는지 외관상 크게 거부감도 없습니다. 

설치된 구성 요소 검색하는 화면

라이선스 동의 화면

설치 패키지 선택 화면

설치 시작 화면

설치되는 구성 요소 목록

.NET Framework Beta 2 가 설치 된 후 시스템 재시작이 필요합니다.

Visual Studio 2010 Beta 2 의 Splash 화면

Visual Studio 시작 페이지 화면

미국 시간으로 2009년 10월 19일, Visual Studio 2010 Beta 2 버전이 공개가 되었습니다. MSDN 을 통해 Beta 2 버전을 다운로드 받으실 수 있습니다.

다운로드
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

그간 Visual Studio 2010 CTP/Beta 버전에서 보여주었던 약간의 성능적인 문제는 이번 Beta 2 버전에서 상당히 많이 개선이 되었다고 합니다.

특히 이번 Beta 2 버전부터는 제품 라인이 전체적으로 변경되었습니다. 기존의 Professional 제품을 제외한 모든 제품의 라인이 변경이 됩니다. 다운로드 받으실 때 혼란이 없으시길 ^_^

더불어 Expression 제품 군도 두 개의 제품으로 나뉘어지게 될 것입니다.

아래는 변경된 MSDN 로고 입니다. ^_^

parallel_invoke는 일련의 태스크를 병렬로 실행할 때 사용합니다. 그리고 모든 태스크가 끝날 때까지 대기합니다. 이 알고리즘은 복수의 독립된 태스크를 실행할 때 유용합니다.

‘일련의 태스크를 병렬로 실행할 때 사용’이라는 것을 들었을 때 생각나는 것이 없는가요? 지금까지 제가 올렸던 글을 보셨던 분이라면 parallel task라는 말이 나와야 합니다. ^^

네 parallel_invoke는 parallel task와 비슷합니다.

parallel_invoke와 parallel task의 다른 점

복수 개의 태스크를 병렬로 실행한다는 것은 둘 다 같지만 아래와 같은 차이점이 있습니다.

parallel_invoke를 사용할 때

병렬로 실행할 태스크의 개수가 10개 이하이고, 모든 태스크가 종료 할 때까지 대기해도 상관 없는 경우에는 간단하게 사용할 수 있는 parallel_invoke를 사용하는 것이 좋습니다. 하지만 반대로 병렬로 실행할 태스크가 10개를 넘고 모든 태스크의 종료를 대기하지 않아야 할 때는 parallel task를 사용해야 합니다.

parallel_invoke 사용 방법

parallel_invoke는 병렬로 태스크를 두 개만 실행하는 것에서 10개까지 실행하는 9개의 버전이 있으며 파라미터를 두 개만 사용하는 것에서 10개의 파라미터를 사용하는 것으로 오버로드 되어 있습니다.

각 오버로드된 버전의 파라미터에는 태스크를 정의한 작업 함수를 넘겨야 합니다.

parallel_invoke 사용 예

아래 예제는 아주 간단한 것으로 게임 프로그램이 처음 실행할 때 각종 파일을 로딩하는 것을 아주 간략화 하여 parallel_invoke를 사용한 예입니다.

< 실행 결과 >

위 예제를 parallel_invoke를 사용하지 않고 전통적인 방법으로 순서대로 실행했다면 각 작업 함수에서 1초씩 소비하므로 3초가 걸리지만 parallel_invoke를 사용하여 1초만에 끝납니다.

그리고 이전에 parallel_for에서도 이야기 했듯이 병렬로 실행할 때는 순서가 지켜지지 않는다는 것을 꼭 유의하시기 바랍니다. 위의 예의 경우도 LoadUIImage()을 첫 번째 파라미터로 넘겼지만 실행 결과를 보면 LoadFont()가 먼저 완료 되었습니다.

마지막으로 위의 예제코드에서 parallel_invoke와 관계 있는 부분만 추려볼 테니 확실하게 사용 방법을 외우시기를 바랍니다.^^

지난 10월 7일에서 9일까지 서울 코엑스에서 ‘KGC 2009’ 라는 게임 개발 컨퍼런스가 열렸습니다.

저는 여기서 ‘Visual C++ 10’에 대해서 강연을 했습니다.

이번 버전 10은 이전에 비해서 변화한 부분이 많아서 가장 큰 핵심인 ‘C++0x’와 ‘Parallel’부분만 주제를 잡았는데도 시간 부족상 다 하지는 못했습니다.

아직 VSTS 2010 Beta1을 설치하지 않은 분들도 많으실 것 같아서 Demo까지 하려니 도저히 시간이 남지 않더군요.

이번에 제대로 하지 못한 ‘Parallel’ 부분은 꼭 다음에 기회가 되는대로 강연을 하도록 하겠습니다.^^

ps : 근래 바빠서 블로그에 포스팅을 하지 못했는데 곧 새로운 글을 올리겠습니다.

3) Constant Buffer

Dx10에서 생긴 ‘Constant Buffer’는 ‘Shader’를 사용할 때 비효율적이고 지속적인 업데이트로 인해 성능을 떨어트리는 현상을 극복하기 위해 도입 되었습니다. 이를 이용해 API와 하드웨어가 상수를 효율적으로 조작해, 귀중한 GPU의 bandwidth와 CPU의 사용량을 최소화 할 수 있습니다.

Shader Constant들을 일괄적으로 관리해 shader constant data 를 관리하기 위해서 발생하는 bandwidth overhead 를 줄여 줍니다.

예전에는 constant 를 등록할 때 4개의 component 를 가진 상수를 등록하는게 기본이었습니다. 즉 float4 가 costanat 설정의 최소 단위였습니다. 하지만 이제는 float 하나만 등록하는 것이 가능합니다.

Shader-constant buffer의 생성은 이전 글에서 언급 했던 것처럼 ‘D3D11_BUFFER_DESC’의 BindFlags를 ‘D3D11_BIND_CONSTANT_BUFFER’로 설정하면 됩니다.

// Define the constant data used to communicate with shaders.





struct VS_CONSTANT_BUFFER





{





    D3DXMATRIX mWorldViewProj;                              

    D3DXVECTOR4 vSomeVectorThatMayBeNeededByASpecificShader;

    float fSomeFloatThatMayBeNeededByASpecificShader;

    float fTime;                                           

    float fSomeFloatThatMayBeNeededByASpecificShader2;

    float fSomeFloatThatMayBeNeededByASpecificShader3;

};

D3D11_BUFFER_DESC BufDesc;

BufDesc.ByteWidth = sizeof( VS_CONSTANT_BUFFER );

BufDesc.BindFlags = D3D10_BIND_CONSTANT_BUFFER

그러나 Index, Vertex Buffer는 다른 ‘D3D11_BIND_CONSTANT_BUFFER’의 열거형 변수들과 함께 ‘or연산’으로 사용할 수 있으나 ‘D3D11_BIND_CONSTANT_BUFFER’는 다른 flag와 함께 사용 할 수 없습니다.

Shader-constant buffer 파이프라인에 bind할 때 아래 중 한 개를 사용합니다.

ID3D11DeviceContext::GSSetConstantBuffers,

ð  ‘Geometry shader pipeline state’ 설정.

ID3D11DeviceContext::PSSetConstantBuffers,

ð  ‘Pixel shader pipeline state’ 설정.

ID3D11DeviceContext::VSSetConstantBuffers

ð  ‘Vertex shader pipeline state’ 설정.

쉐이더가 Shader-constant buffer를 읽게 하기 위해, 고유의 HLSL함수를 사용합니다.

 실질적으로 DX10에서 DX11로 넘어오며 바뀐 점을 딱히 찾지는 못하고, Dx Help파일을 번역하고 검색한 내용을 약간 첨부한 정도가 되었습니다.

 추후에 더 알게 되는 것이 있으면 추가하도록 하겠습니다.

이전에 MousePresentationTracker 를 예제로 만들어서 공개한 적이 있습니다. 몇 번 사용해 보면서 Visual Studio 2010 의 새로운 확장 모델인 VSIX 에서는 좀 사소한 버그가 있었습니다. 이 문제 때문에 심히 불편했습니다만, 정식 버전에서는 반드시 고쳐지길 바랄 뿐입니다. ^_^;

문제는 VSIX 의 어셈블리명(DLL) 이 Umc.Core.Tools.MousePresentationTracker.dll 처럼 '.' 이 들어가면 Visual Studio 2010 이 제대로 로드하지 못합니다. 그렇기 때문에 아래와 같이 Assembly Name 은 반드시 "파일명.확장자" 와 같은 이름을 주어야 합니다.

기타 확장 기능 참고 

안녕하세요. VSTS 2010 공식 팀에서 Twitter 를 시작했습니다. Twitter 를 통해 차마 시간이 없어 정리하지 못한 정보나 알아두면 좋은 팁과 정보 등을 단문 메시지로 여러분들에게 전달해 드릴 예정입니다.

차세대 플랫폼인 Visual Studio / Team System 2010 등 관심 있는 분들의 많은 Following 을 부탁 드립니다.

http://twitter.com/vsts2010

- 이번엔 웹디자이너와 배포에 대해서

부족한 번역이지만, 이번엔 웹 디자이너와 배포에 대해서 적어볼까 합니다.


- Visual Studio 2010 Web Designer Improvement

Visual Studio 2010의 웹페이지 디자이너는 더 뛰어난 CSS 호환성, HTML과 ASP.NET 마크업의 코드조각에 대한 추가적인 지원과 Jscript를 위해서 다시 디자인된 인텔리센스등으로 더 향상된 기능을 제공합니다.

- Improved CSS Compatibility

Visual Studio 2010의 Visual Web Developer 디자이너는 CSS 2.1 표준과 호환되는데요. 이 디자이너는 HTML 소스와의 통합성을 높이면서 기존의 버전의 Visual Studio보다 전체적으로 더 견고한 기능을 제공합니다. 내부적으로는 앞으로 추가될 렌더링, 레이아웃, 사용성 및 유지보수를 위한 설계적인 측면에서의 향상도 있었습니다.

- HTML and Jscript Snippets

HTML에디터는 인텔리센스를 이용해서 태크이름을 자동완성합니다. 그리고 인텔리센스의 코드조각 기능이 전체 태그와 기타 부분을 완성합니다. VisualStudio 2010에서는 인텔리센스의 코드조각 가능이 C#과 Visual Basic에 적용되었던 것 처럼 Jscript에 대해서도 지원될 것입니다.

VisualStudio 2010에는 200개 이상의 코드조각이 ASP.NET과 HTML의 일반적인 태그와 필요한 속성(runat=”server” 같은)과 특정 태그들에 공통적인 속성들(ID, DataSourceID, ControlToValidate, Text같은)의 자동완성을 도와줍니다.

추가적인 코드조각들을 다운받을 수 있으며, 팀의 공동작업이나 개인작업에 공통으로 쓰이는 마크업의 블록을 코드조각으로 뽑아내서 사용할 수도 있습니다.

- Jscript IntelliSense Enhancements

VisualStudio 2010에선 더 풍부한 편집을 위해서 Jscript의 인텔리센스가 다시 디자인 되었습니다. 이젠 인텔리센스가 registerNamespace같은 메서드나 기타 비슷한 자바스크립트 프레임워크의 기술을 이용해서 동적으로 생성되는 객체를 인식할 수 있습니다. 그리고 방대한 스크립트 라이브러리를 분석하고 화면에 인텔리센스를 표시하는데 걸리는 시간을 사용자가 거의 못 느낄 정도로 향상시켰습니다. 호환성 역시 대단히 향상되어서 외부 라이브러리나 다양한 코딩 스타일도 지원할 수 있게 되었습니다. 문서화를 위한 주석은 타이핑하는 즉시 파싱되어서 인텔리센스에서 바로 활용할 수 있습니다.

- Web Application Deployment with Visual Studio 2010

현재 웹 어플리케이션을 배포하는 작업은 우리가 꿈꾸었던 것만큼 쉽지 않았죠. ASP.NET 개발자는 종종 아래와 같은 문제에 직면하곤 합니다.

*   FTP같은 기술을 사용해야 하는 공동 호스팅 사이트에 배포하는 경우. 게다가 데이터베이스를 세팅하기 위한 SQL스크립트를 직접 실행해야 하거나 가상 디렉토리같은 IIS세팅도 바꿔야 한다.

*   엔터프라이즈 환경에서는 웹 어플리케이션을 배포하는 것으로 끝나지 않고, ASP.NET 설정파일이나 IIS세팅도 수정해야 한다. 데이터베이스 관리자는 데이터베이스를 돌리기 위해 필요한 SQL스크립트를 돌려야 한다. 그런 설치작업은 종종 몇 시간을 잡아먹으며 노동에 가까운 일이 되며, 세세하게 문서화 되어야 한다.

VisualStudio 2010은 웹 어플리케이션을 중단없이 배포할 수 있게 도와주는 새로운 기술을 통해서 이런문제들을 해결합니다. 이런 기술들중의 하나가 IIS Web Deployment Tool(MsDeploy.exe)이죠.

VisualStudio 2010에서 웹배포에 관련된 요소들은 아래와 같이 크게 분류할 수 있습니다.

*   Web packaging

*   Web.config Transformation

*   Database deployment

*  One-Click Publish for Web applications

아래의 섹션들에서 하나씩 자세하게 설명을 해보겠습니다.

- Web Packaging

VisualStudio 2010에서는 MSDeploy 툴을 사용해서 어플리케이션을 압축해서 압축파일(.zip)을 생성하는데, 그 파일을 웹 패키지라고 부릅니다. 패키지파일은 어플리케이션에 대한 메타데이터와 아래의 내용들을 포함합니다.

*   어플리케이션 풀 세팅과 에러페이지 세팅, 등등을 포함하는 IIS세팅

*   웹페이지와 사용자 정의 컨트롤, 정적인 컨텐츠(이미지와 HTML파일), 등등을 포함하는 실제 웹 컨텐츠

*   SQL 서버의 데이터베이스 스카마와 데이터

*   보안 인증서, GAC에 설치할 컴포넌트, 레지스트리 세팅, 등등

웹 패키지는 아무 서버에나 복사할 수 있고, IIS 매니저를 사용해서 수동으로 설치할 수 있습니다. 또는, 커맨드라인 명령어나 배포API를 사용해서 자동으로 배포할 수도 있습니다.

VS2010에서는 웹패키지를 만들기 위해서 사용가능한 MSBuild의 task와 target을 제공합니다. 더 많은 정보는 Vishal Joshi의 블로그에 있는 10 + 20 reasons why you should create a Web Package를 참조하시길 바랍니다.

- Web.config Transformation

웹 어플리케이션의 배포를 위해서 VisualStudio 2010에서는 XML Document Transform (XDT)가 도입되었는데, 이 요소는 개발설정에서 Web.config를 읽어와서 제품설정(production setting)으로 변환하게 도와줍니다. 변환에 관련된 세팅은 변환파일인 web.debug.config, web.release.config, 그리고 기타파일(이 파일들의 이름은 MSBuild 설정과 매치된다)등에 명시되어 있습니다. 변환파일에는 Web.config파일을 배포하기 위해 필요한 수정사항들만 포함되어 있습니다. 이런 수정사항들을 간단한 문법으로 명시해주면 되는거죠.

아래의 예제는 배포의 릴리즈설정에 의해 생성가능한 web.release.config파일의 일부분인데요. 예제의 내용중에서 Replace키워드를 보면, 배포과정에서 Web.config파일의 connectionString 노드의 값이 어떻게 바뀌어야 하는지 명시해주고 있습니다.

<connectionStrings xdt:Transform="Replace">

  <add name="BlogDB" connectionString="connection string detail]" />

</connectionStrings>

더 자세한 정보는, Vishal Joshi의 블로그의 Web Deployment: Web.Config Transformation를 보시면 됩니다.

- Database Deployment

VisualStudio 2010의 배포 패키지에는 SQL 서버 데이터베이스에 대한 의존성 역시 포함될 수 있습니다. 패키지 정의의 일부분으로 원본 데이터베이스의 연결문자열을 명시해줄 수 있습니다. 웹 패키지를 만들때 VisualStudio2010에 의해서 데이터베이스 스키마와 선택적으로 데이터에 대해서 SQL 스크립트가 만들어지고 패키지에 포함됩니다. 사용자 정의 SQL 스크립트를 만들어서 서버에서 순차적으로 실행되어야 할 순서를 지정해줄 수도 있습니다. 배포할때, 타겟 서버에 대한 연결문자열을 제공하고, 배포 프로세스에서 이 연결문자열을 이용해서 해당 데이터베이스에 SQL 스크립트를 실행해서 데이터베이스 스키마를 만들고 데이터를 추가합니다.

추가적으로, One-Click Publish를 이용하면 어플리케이션이 원격의 공용 호스트에 게시된 후에 데이터베이스를 직접적으로 게시할 수 있도록 배포를 설정할 수 있습니다. 자세한 내용은 Vishal Joshi의 블로그의 Database Deployment with VS 2010를 참조하시면 됩니다.

- One-Click Publish for Web Application

VisualStudio 2010에서는 IIS 원격 관리 서비스를 이용해서 원격의 서버에 웹 어플리케이션을 게시할 수 있도록 도와줍니다. 게시를 위해서 호스팅 계정이나 테스트 서버나 스테이징 서버를 위한 게시 프로파일(publish profile)을 생성할 수 있습니다. 각각의 프로파일은 안전하게 계정정보를 저장할 수 있구요. 그러면 Web One Click Publish 툴바를 이용해서 한번의 클릭으로 타겟서버에 배포할 수 있게 됩니다. VisualStudio2010에서는 MSBuild 커맨드 라인을 통해서도 배포할 수 있는데요. 이 기능을 통해서 지속적인 통합 모델을 이용하는 팀 빌드 환경에 게시작업을 포함할 수 있습니다.

더 자세한 정보는, Vishal Joshi의 블로그의 Web 1-Click Publish with VS 2010를 보시면 되구요, VisualStudio 2010에서의 웹 어플리케이션 배포에 대한 비디오 영상을 보려면, Vishal Joshi의 블로그의  VS 2010 for Web Developer Previews를 보시면 됩니다.

안녕하세요. Q3에 합류한 안승근입니다.
앞으로 DX11에 와서 변경된 내용 중 기초적인 부분을 담당하여 글을 올리도록 하겠습니다.
  대부분의 내용은 DX9와 비교해 변경된 사항에 대해 언급 하도록 하겠습니다.

글을 읽으시다 틀린 내용에 대해서는 코멘트를 주시면 감사하겠습니다.

 
 첫 주제는 D3D11의 Buffer입니다.
D3D11에는 아래와 같이 총 3개의 버퍼 타입이 있습니다.

Buffer Type: Vertex Buffer, Index Buffer, Constant Buffer

1) Vertex Buffer

각 정점의 정보를 직접적으로 저장해놓고 사용하는 방식.

간단히 사용할 수 있으나 중복된 정점의 위치를 여러개 저장하고 사용하는 등 능률은 높지 않다.

2) Index Buffer

Index로 Vertex Buffer의 정점 정보를 얻어 사용할 수 있다.

 Vertex Buffer와 Index Buffer는 같은 정점에 대해서는 Index로 위치 정보를 공유해서 사용하기 때문에 능률이 높아진다.

* DX9와 DX11의 버퍼 생성시 차이점

IDirect3DDevice9::CreateVertexBuffer

ð  ID3D11Device::CreateBuffer

DX9에서는 아래와 같이 각각의 버퍼를 생성하는 함수가 따로 존재하였습니다.

if( FAILED( g_pd3dDevice->CreateVertexBuffer( 50*2*sizeof(CUSTOMVERTEX),

                                           0, D3DFVF_CUSTOMVERTEX,

                                           D3DPOOL_DEFAULT, &g_pVB, NULL ) ) )

{

    return E_FAIL;

}

if( FAILED( g_pd3dDevice->CreateIndexBuffer( 12 * sizeof(MYINDEX),

 0, D3DFMT_INDEX16,
 D3DPOOL_DEFAULT, &g_pIB, NULL ) ) )

{

    return E_FAIL;

}

정점을 생성하는 방법이 DX11에 와서는 한개의 함수로 통합해서 사용하고 아래와 같이 D3D11_BUFFER_DESC에 버퍼 생성에 필요한 옵션을 넣었고, 특히 멤버변수인 BindFlags를 변경해 어떤 버퍼를 생성할지 정할 수 있도록 하였습니다.
 위의 함수들을 다시 보면 왜 굳이 나눠 놓았을까 싶을 정도로 함수 이름만 다를뿐 파라미터가 거의 동일합니다.

   // Define the data-type that
   // describes a vertex.
   struct SimpleVertexCombined
   {
       D3DXVECTOR3 Pos; 
       D3DXVECTOR3 Col; 
   };

   // Supply the actual vertex data.
   SimpleVertexCombined verticesCombo[] =
   {
       D3DXVECTOR3( 0.0f, 0.5f, 0.5f ),
       D3DXVECTOR3( 0.0f, 0.0f, 0.5f ),
       D3DXVECTOR3( 0.5f, -0.5f, 0.5f ),
       D3DXVECTOR3( 0.5f, 0.0f, 0.0f ),
       D3DXVECTOR3( -0.5f, -0.5f, 0.5f ),
       D3DXVECTOR3( 0.0f, 0.5f, 0.0f ),
   };

   // Create indices.
   unsigned int indices[] = { 0, 1, 2 };

    // Setup constant buffers
    D3D11_BUFFER_DESC BufDesc;
    // Vertex Buffer Size
    BufDesc.ByteWidth        = sizeof( SimpleVertexCombined ) * 3;
    // Index Buffer Size

    // BufDesc.ByteWidth       = sizeof( unsigned int ) * 3;

    BufDesc.Usage = D3D11_USAGE_DYNAMIC;

    BufDesc.BindFlags = D3D11_BIND_VERTEX_BUFFER; // D3D11_BIND_INDEX_BUFFER

// , D3D10_BIND_CONSTANT_BUFFER...

    BufDesc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;

    BufDesc.MiscFlags = 0;

    pd3dDevice->CreateBuffer( &BufDesc, NULL, &g_pMirrorVertexBuffer );

 정점을 저장하는 버퍼역시 DX9에서는 VertexBuffer, Index Buffer가 각각 나누어져 있었던 것이 DX11에서는 한개로 통합되었습니다.
LPDIRECT3DVERTEXBUFFER9 g_pVB        = NULL; // 정점버퍼
LPDIRECT3DINDEXBUFFER9 g_pIB        = NULL; /// 인덱스버퍼

ID3D11Buffer*               g_pVertexBuffer = NULL;
 

* DX10과 DX11의 버퍼 생성시 차이점
 DX10과 DX11은 사실상 함수 이름외에는 변한 것이 없습니다.
 아래와 같이 사용하는 함수의 이름 중 DX의 버젼을 나타내는 숫자가 '10'에서 '11'이 된 것 외에는 사용되는 모든 함수가 ‘파라미터’와 ‘리턴타입’까지 동일하므로 DX11이라고 해서 따로 알아야 할 내용은 없습니다.

ID3D10Device::CreateBuffer

ð  ID3D11Device::CreateBuffer

버퍼에 관련된 내용 뿐만 아니라 대부분의 함수들이 DX10과 DX11은 거의 비슷한 형태를 지니고 있습니다. 따라서 특별한 경우가 아니면 DX9와 비교해 변경된 것만을 적도록 하겠습니다.

다음 번의 글에는 Constant Buffer에 대해서 올리도록 하겠습니다.

- 아아... 이거슨 Love Story.

오늘 말씀드릴 내용은 DLR이 왜 Expression Tree(이하 표현나무)를 처음에는 박대하다가 나중에 가서는 "역시 난 니가 아니면 안되나봐 ㅠ_ㅠ"같은 대사를 날리게 되는지 Jim Hugunin의 증언을 통해서 알려드리고자 합니다. 그럼 지금부터 달콤 쌉싸름하고 무슨말인지도 잘 모르겠는 러브스토리를 한번 감상해보시져.


- 누군가가 필요하긴 했어. 하지만 너 아닌 다른 나무라도 괜찮을 거 같았어.

 지난 시간에 말씀드렸듯이 C# 3.0에 표현나무가 추가된 이유는 쿼리가 실행되는 곳이 어디냐에 따라서 최적화를 하기 위해서 컴파일된 IL코드의 형태보다는 자료구조의 형태가 훨씬 수월하기 때문이었습니다. 그리고 DLR은 닷넷 프레임워크에서 실행되는 동적 언어들이 공동으로 사용할 수 있는 기반을 제공해주고, 각 언어들끼리 그리고 정적언어들과도 서로 대화를 주고 받을 수 있도록 해주기 위한 장치인데요. 그렇다면, 언어별로 내부적인 구현의 차이점이 있을 수 있겠고 한 언어에서 작성한 코드를 다른 언어에서도 사용가능하려면, 둘 사이에 변환과정이 있어야 하겠고 그 변환과정을 수월하게 해줄 수 있는 도구가 필요하겠죠. 어떤 가요? DLR과 표현나무의 러브스토리의 윤곽이 좀 잡히시나요?

Jim Hugunin에 따르면 애초에 DLR을 설계할때 코드를 표현할 공통자료구조로 트리형태를 생각하고 있었다고 합니다. 그리고 타입이 없으면서 런타임에 late-bound되는 노드들로 구성된 트리로 구현을 시작했다고 합니다.  그래서 그 당시에 IronPython에 맞게 구현된 트리에는 타입이 있는 노드가 ConstantExpression딱 하나였다고 합니다. 상수 값이면 뭐든지 가지고 있는 노드 말이죠. 그리고 자신들이 생각하고 있는 트리와 표현나무 사이에는 공통점이 없다고 생각했었다고 합니다. 왜냐면 정적언어에서 쓰는 게 동적언어에는 안 맞을거라고 생각했기 때문이라는 군요. 그래서 독립적으로 트리를 구성해 나갔다고 하네요.


- 하지만, 다른 나무들을 만날 수록 니가 그립더라.

하지만, 다른 언어의 구현을 추가하면서, 기존의 DLR트리에 각 언어의 특징을 제대로 표현하기 힘들어졌다고 하는군요. 각 언어의 특징을 지원하기 위한 방법이 필요한데, 그렇다고 해서 직접적으로 그 언어의 특징을 위한 노드를 추가할 수 는 없었다네요. 아마도 DLR트리는 DLR에서 도는 언어들이 공통적으로 공유하게되는 자료구조인데, 특정언어에만 있는 노드를 추가하면, 점점 지저분해 지기 때문이겠죠.

예를 들면, Python의 print문을 보면, 내부적으로 print문은 Python에서 출력에 대한 걸 어떻게 처리할지에 대해 알고 있는 static 메서드를 호출한다고 하는군요. 그래서 DLR트리에 static 메서드 호출노드를 추가했다고 합니다. 그러면 print호출은 static 메서드를 호출하는 걸로 연결할 수 있으니까요.

그리고 이런 작업을 하다보니깐, 그동안 개발팀이 추가해오던 노드들이 정적인 타입이 적용되는 표현나무의 각 노드랑 딱 들어맞는 다는 걸 깨달았다고 합니다. 그래서 처음부터 다시 만드는 대신에 기존에 잘 쓰고 있는 걸 확장하자고 마음을 먹었고, 기존의 표현나무에 동적인 연산이나 변수, 이름 바인딩, 흐름제어등을 위한 노드를 추가했다고 합니다.

그리고 DLR에서 동작하는 언어가 이런 트리형태를 만들어 내게 되면서 각각의 언어에 맞는 최적화를 수행하는게 수월해졌습니다. 지난 포스트에서 설명드렸던 표현나무를 사용하면서 얻는 장점과 매우 동일한 점입니다. 그래서 각 언어의 컴파일러는 코드를 표현나무의 형태로 만들어서 그 표현나무를 DLR에게 전해준다고 하는 군요.


- 그들은 현재 잘 살고 있답니다.

Jim Hugunin의 PDC2008의 "Dynamic Languages In Microsoft .NET"의 슬라이드를 통해서 각 언어별로 나타나는 표현나무의 모양을 보도록 하겠습니다.

C#에서 구현한 팩토리얼을 표현나무로 옮긴다면 아래와 같다고 하는군요.