엉망 진창인 내용입니다. PPT 내용이 많아 날로먹었습니다. (__)

Hull Shader = 외피 쉐이더
Domain Shader = 주력 쉐이더
super set = 초집합/ 포함집합
patch = 작은 지역
compute shader = 연산쉐이더
ray tracing = 빛 추적
Immediate Context = 즉각적 상황
Deferred Context = 지연적 상황

DirectX 11 : 어떤 것이 다가오는지를 봐라.

1페이지

DirectX 11 : 어떤 것이 다가오는지를 봐라.

Microsoft가 DirectX 10을 게임 개발로 가져다 놓겠다는 이야기를 시작한지 얼마 되지 않았을 듯 싶다. 사실, 우리가 새로운 파이프라인에 대해 기술한지 2년도 되지 않았으며, 이때부터 우리는 AMD와 Nvidia 모두에게서 몇몇 세대를 거치는 것을 보았다.

Windows Vista SP1의 배포와 함께, Microsoft는 DirectX 10.1의 소개를 같이 하게 되었다. - 이것은 우리의 RV670 설계적 분석에서 다루었었으며 오로지 AMD만이 API 갱신을 도입한 것이다. Nvidia는 개발자들이 - GPU 가속 게임 내 물리 같은 - 다른것을 원한다고 주장하며 이로 인해 GT200 설계에서는 이것을 중점적으로 선택하게 된다.

몇몇은 그래픽 분야가 거북한 진보라 말하는 반면, 나머지 다른 사람들 몇몇은 게임 내의 그래픽 상에서만 초점이 맞추어 졌던 추세에서 첫번째 큰 변화를 나타내었다고 믿기도 한다. 당신이 본 것이 무엇이든 간에, Assasin's Creed 에서의 일은 약간 논란의 여지가 있긴 하다.

그리고 이제 우리는, Microsoft가 그래픽 API로 언급하고 있는 다음 큰 업데이트인 DirectX 11로 오게 되었다.Microsoft의 DirectX 설계자는 DirectX 10의 배포 후에 그들의 명예를 붙잡고 쉬고 있지 않았다. - 사실, 심지어 Vista SP1에 탑재된 DirectX 10.1 이전에도, 회사는 이미 DirectX 11이라고 알려진 것에 대해 작업을 시작하였었지만, 확실히 이것으로도 끝이 아닌데 왜냐면 우리들과 대담을 나누었던 개발자들은 DirectX 12에 대해 그들이 바라는 것을 언급하고 있기 때문이다!

Microsoft 는 Seattle에서의 GameFest 2008에서 새로운 API를 발표 하였지만 여전히 이것은 개발중이다. 이 때 우리는 Nvision 2008에서 Microsoft의 Kevin Gee에게 API의 대략적인 것을 들을 기회를 잡았었으며, 이에 따라서 우리는 새로운 API와 그들의 목표에 대해 논의할 ㅁ쳐몇 개발자들을 잡을 수 있었다. 게다가, 우리는 또한 GameFest에서 어떤 것이 논의되고 있는지 들을 수 있었는데, Microsoft는 편리하게도 공개 가능한 그들의 - 음성까지 적용된 - 프리젠테이션을 모두 만들어 갖고 있었다.

아래 나오는 것들은 모두 내가 수집한 모든 정보에 대한 결과인데 원본 발표는 7월에 완료 되었었다. 그러나, 이것은 여전히 개발중이기 때문에, 현재와 DirectX 11의 RTM 날 사이에는 어떠한 변조도 있을 수 있다.

우리가 현재 있는 곳은

DirectX 10이 배포 되었을 당시, Microsoft는 찌꺼기들을 없애버리고 다시 한번 재도약을 하기로 결정 했었다. 이에 따라 완벽히 새로운 드라이버 모델, 그러니까, 예를들면 엄청나게 유명한 Windows XP 같은, 오래된 Windows OS와의 호환성까지 의미하는 것이었는데, 이런것들까지 논란의 여지에도 불구하고 단절되게 되었다.

DirectX 팀의 최근 산물은 Vista로 오게 되었으며, Vista에서만 구동가능하다. 이것은 아주 과감한 결단임에 의심할 여지가 없지만, DirectX가 처음 도래한 1995년부터 가졌었던 문제들을 최종적으로 없애버리기 위해 불가피한 것이었다.

DirectX 10이 도래하기 전, Microsoft의 API는 선택적인 기능으로 인해 코드를 짜기에 더욱 어려움이 가중되어가고 있었다. - 해결책으로는, API의 능력을 노출하는 수밖에 없었다.

능력을 노출하지만 모든 기능을 다 사용할 수는 없어 그림의 떡이나 다름없다. - DirectX 10에서의 장점이라면, Microsoft는 모든것을 의무적으로 사양화 시켰다. 이것은 없는것 빼고 다 있게 만들었으며, 이것은 개발자들에게는 희소식이었는데, 어떤 하드웨어가 어떻게 개발되고 있는가를 걱정할 필요가 없어졌으며 벤더 제한적인 코드의 필요성도 없어졌기 때문이다.

그래도 DirectX 10은 그들의 문제를 제거하지 못했으며 DirectX 10.1은 몇몇 단점들을 고치기 위해 몇가지 방법을 썼었다. - 사실, 이것은 Microsoft에 의한 '완벽한 D3D10'의 미끼였다. DirectX 10에서는 어떠한 선택적 기능도 없다는 말을 위에서 내가 했었다는 것을 알고 있지만, 실제적으로 여기에는 아주 극소수의 - FP32 필터링과 4xMSAA 가 DirectX 10.1 호환에 요구되는 기능인데, 그렇지만 대부분의 DIrectX 10 하드웨어가 이들 기능 모두를 이미 지원하기 때문에, 10.1은 사실상 그렇게 큰 매력을 느끼지 못하는게 현실이다.

대신, D3D 10.1의 가장 매력적인 요소는, 우리가 대화를 나눈 개발자들에 따르면 (Unreal Ungine3 기반 모두와 다른 몇몇 게임에서라도 다 쓰이는) 텍스쳐의 깊이를 그리기 위한 필요성이 없는 지연 렌더링에 관련한 MSAA의 사용 가능성이라고 한다. 대신, DirectX 10.1에서는, 멀티 렌더 목표가 있을 때 멀티-샘플 깊이 버퍼에서 읽어올 수 있다. - 이것은 확연하게 성능을 향상시키는데, (20~30% 정도) 왜냐면 작동이 1개 패스에서 완료되기 때문이다.

2페이지

우리가 지향하는 것

Microsoft가 DirectX 11 착수에서 말한 것은 DirectX 10.1의 확장판이 될 것인데, 여기에서 새로운 기능과 특징을 추가하는 반면, 또한 가용성을 향상시키는데 초점을 맞추고 개발자와 하드웨어에 대한 효율을 높이는 것도 추가할 것이다.

여기에서 내가 단어 선택에 있어 아주 조심하고 있는데, 왜냐면 Microsoft는 하드웨어가 더욱 효율적이고 기본적으로 한번에 더 많은 량을 처리할 수 있게 될 때 DirectX 10에서는 엄청난 속도 향상이 있을 것이라고 약속하였기 때문이다. 순수 초당 프레임이라는 면에서 성능을 본다면, DX10에서 향상하진 않았지만 DX9 내에서의 작동 상에서 도입했던 것들과 비효율적이어서 이전에는 불가능 했었던 것들의 가능성을 열어 주었다.

나는 DirectX 11의 프레임 레이트의 순수 성능 향상을 예상하고 있지 않는 반면, 추가된 기능과 DirectX 고문 게시판 상에서 내가 대화를 나누었던 몇몇 개발자들이 충고 하기를 개발자들은 현재 API에서 가능한 것 보다 더 많은 가용성과 효율성 때문에 새로운 API는 개발자로 하여금 더욱 많은 것을 할 수 있게 만들어줄 것이라 하였다. 이것의 이치는, DirectX 10에서도 맞아 떨어진다. - 그다지 많은 부하를 주지 않고도 더 많은 일을 하여 같은 성능이 나온다.

이 새로운 API는 (2009년 말/ 2010초에 출시 예정인) Windows 7과 같이 선적될 것으로 예상되지만, 희소식은 DirectX 11은 또한 Windows Vista에서도 구동될 것이라는 것이다. 이 것으로 미루어 보아, 우리는 하위 호환성이 있기 때문에 DirectX 11이 DX10 같은 해결책으로 주어지지 않을 것이라는 것을 희망할 수 있으며, 다음에 나올 페이지에서 보면 알겠지만, 현재의 DX 9와 10/10.1 하드웨어에서의 이득까지도 볼 수 있는 몇몇 기능들이 있기도 하다.

DirectX 11 파이프라인

이 새로운 API에서의 강조점은 컨텐츠 저작에 맞추어져 있었는데, 개발자로 하여금 더 복잡하고 현실적인 캐릭터를 만들 수 있게 하는 것이다. 이것은 Microsoft의 가용성과 효율성 향상에 딱 알맞는데 현재의 추세는 개발자로 하여금 캐릭터를 엄청나게 복잡한 메쉬나 삼각형으로 만들도록 하게 하며, 이로 인해 특정 시스템에서는 능력에 따라 삼각형의 수를 줄여야 한다.

이런 특정 문제를 풀기 위해, Microsoft는 DirectX 11 그래픽 파이프라인 내에서 3개의 새로운 스테이지를 소개하였다. : 외피 쉐이더, 테셀레이터와 주요 쉐이더이다. - 외피와 주요 쉐이더는 기본적으로 테셀레이터의 포함을 촉진하게 된다. 만약 이 새 스테이지들을 없애버린다면, 현존하는 DirectX 10 파이프라인과 아주 비슷한 것을 볼 수 있게 된다. - 그렇다 하더라도 기본적으로 여기에는 그들을 기술적으로 차이가 나게 약간의 트윅이 가해져있다.

이 추가된 세개 새로운 스테이지들은, 파이프라인 내의 픽셀 쉐이더 스테이지에서 더욱 범용 연산 작업을 쉐이더에서 연산하게 하기 위한 약간의 변화가 이루어진 것이다. 한가지는 여러 게임과 범용 어플리케이션 개발자들과의 논의에서 충분히 밝혀졌다. - 쉐이더가 연산에 쓰일 수 있는 방법은 거의 무궁무진하다는 것이다. 엄청난 스레드의 어플리케이션을 위한 방법이 있는 한, 쉐이더를 연산에 계속적으로 사용할 것이다.

OpenCL이나 이와 비슷한 쉐이더 연산을 생각해보자. - 이것은 DirectX에서 연산 작업을 엄청난 수의 병렬 범용 방식을 기업 표준으로 사용 가능케 할 것인데, 다른 면으로 게임 개발자들에게는 그래픽 작업이 아닌 다른 작업에서 엄청난 양의 연산력을 사용할 수 있는 자유를 부여할 것이다. 현재, AMD나 Nvidia는 그들의 GPU나 스트림 컴퓨팅을 표방하는데 이것으로 하여금 개발자들에게 그래픽 작업이 아닌 문제들을 풀 수 있도록 하게 하지만, 그들은 각기 호환되지 않는다는 것이 중요하다. Intel은 Larrabee로 하여금 대량의 병렬 연산에서 나타난 프로그래밍적 문제에 대한 그들 고유의 해답에 대해 이미 말하였었으며 이질적으로 AMD의 스트림 SDK가 Nvidia의 CUDA 플랫폼과 호환될 것이다.

이것은 어플리케이션 개발자에게 문제를 안겨주는데, 왜냐면 그들이 - 어쩌면 각기 다른 하드웨어를 위해 3개의 '다른' 어플리케이션을 만들어야 할 필요가 있을 수 있는 - 교차 플랫폼 호환성에 초점을 맞추는 방향으로 갈 것인지, 특정 플랫폼에서 최대 성능을 내는 방향으로 쏠 것인지를 결정해야 하기 때문이다. 우리는 게임 개발자가 그들의 게임 내에서 2개 GPU 가속기 중 1개를 물리 API용으로 사용함에 있어 나타난 잠재적 문제 몇가지에 대해 이야기를 나눈 적이 있다. - 결국엔 게이머는 어떤 그래픽 카드를 구매했느냐에 따라 더 뛰어난 경험을 할 수 있을 것이라는 것으로 귀결되었다.

추가적으로, 개발자들은 GPU 가속 물리로 실현할 수 있는 것들이 제한되어 있는데, 왜냐하면 최저 사양의 공통 분모 또한 찾아야하는 의무가 있기 때문이다. 다시 말해, 진정한 주목할만한 게임 내 물리는 대부분에서 이루어질 수 없는데 왜냐면 심지어 쿼드코어 CPU조차 뻗어버릴 수 있기 때문이다.

3페이지

Tessellation

테셀레이션은 2005년 말 Microsoft의 Xbox 360의 출시때부터 우리 주위를 맴돌았다. - ATi가 설계한 Xenos GPU는 별도의 하드웨어 테셀레이션을 내장하였다.

이 추가에 대한 비화는 그 당시에는 상당히 단순했다. : 컨텐츠 저작 과정의 향상과 개발자와 디자이너들로 하여금 더욱 현실적이고 복잡한 캐릭터를 엄청난 그래픽 메모리 중복 없이 생성가능하게 하기 위한 것이었다.

기본적으로, 물체가 멀리 갈 수록 덜 세세해지며 적은 삼각형을 갖게 되는데, 신경써서 보지 않기 때문이지만, 관측자에게 가까이 오며 스크린을 채울수록 특정 물체의 삼각형 갯수는 지수함수처럼 늘어나 세세함을 증가시키며 좀 더 현실적으로 보이게 만든다. 미녀를 전부 그린 이미지를 고려할 때, 평균 삼각형 렌더 갯수는 훨씬 불변적이므로 플레이어들에게는 더 적은 속도 저하를 가져오게 된다.

전통적으로, Sub-D 모델에서 옮겨진 캐릭터 생성은, 폴리곤 메쉬가 적용되기 전에 animated 과정과 displacement-mapped 모델을 거치게 된다. 메시가 한번 적용 되면, GPU로 보내지기 전에 다양한 LOD들로 크기가 변환되게 된다. 다양한 LOD들은 하드웨어의 각기 다른 클래스로 쓰이거나, 캐릭터나 플레이어로부터 멀리 떨어진 물체일 때 쓰일 수 있다. - 가능한한 적은 성능 하락으로 화면에서 더욱 세세하게 표현하게 한다.

이런 성능은 콘솔 개발에서 더욱 현실적일 것이라는 것을 암시하는데 왜냐면 하드웨어는 아주 한정되어 있기 때문이다. 이렇게 말하더라도, PC 플랫폼에서 또한 테셀레이션에 대한 엄청난 이득도 역시 있게 된다. 그리고 이 부분이 왜 AMD가 Radeon HD 2900XT에서 테셀레이터 하드웨어를 소개 했는지에 대한 이유가 된다. - 그리고 차후 배포된 모든 후속 GPU들도 이것을 내장하게 되었다. 아직까지 실제로 쓰이기엔 많은 시간이 걸리겠지만, 그럼에도 불구하고 하드웨어 기반 테셀레이션이 제공하는 이득에 대한 잠재력을 업계쪽에서 유심히 지켜보게 하는 계기가 되었다.

Microsoft의 Kevin Gee와 AMD의 Richard Huddy 둘 모두와 대담을 나누고 난 후, 우리는 (Radeon HD 2000, 3000 그리고 4000 시리즈까지) Xbox 360의 테셀레이터가 DirectX 11과 호환되지 않는다는 것을 알아 냈지만, DX11 테셀레이터는 이미 시장에 나와있는 것의 포함집합(초집합) 이다. 또다른 장점은 Radeon HD 4000 시리즈 테셀레이터가 약간의 변화를 거쳐서, 개발자로 하여금 DirectX 10 어플리케이션 내의 기능에 접근할 수 있게 만들었다는 것이다. - 이것은 HD 2000과 3000 시리즈 GPU에 내장된 테셀레이션 유닛에서는 가능하지 않았다.

더욱이, 비록 개발자들이 오늘날 나오는 어플리케이션에 사용하는 것이 이질적 임에도 불구하고, RV7xx의 테셀레이터는 디딤돌이 되기에 충분한데 왜냐면 이것은 개발자와 디자이너들로 하여금 오늘날 확실히 DirectX 11에 비슷해져 가고 있는 프로그래밍 환경에서 테셀레이션을 실험할 수 있게 하기 때문이다. 결국, DirectX 11의 그래픽 파이프라인은 DirectX 10의 초집합이다. - 주된 추가사항은 테셀레이터이다.

Nvision에서 그의 프리젠테이션 중에, Gee는 얼마나 DirectX 11 테셀레이션 유닛이 AMD의 (Xenos를 포함한) 현재 GPU들 내의 테셀레이션 유닛보다 훨씬 강력하고 유연한지를 말했었다. 그러나 흥미롭게도, 이것은 여전히 프로그래밍이 가능하지 않다. - 이것은 외피 쉐이더에서 정확한 정보를 제공하는 것에 의존하며 이때 주력 쉐이더로 하여금 파이프라인으로 내려가기 전에 테셀레이터에서 나온 점 내의 데이터와 출력을 취하게 된다.

4페이지

테셀레이션에 관해 계속

외피 쉐이더는 테셀레이션의 물체가 설정되는 곳의 연산을 한다. - 이것은 작은 지면을 제어 지점으로 취하며 요구되는 테셀레이션의 레벨을 계산하게 된다. 기본적인 변환 후, 제어지점들은 주력 쉐이더 상으로 들어가게 된다. - 테셀레이터는 제어지점을 신경쓰지 않는다.

대신, 테셀레이터는 몇몇 TessFactor들에게 정보를 제공하는데 특히 특정 지면 상에서 요구하는 테셀레이션의 레벨을 테셀레이터에게 말해준다. 외피 쉐이더는 또한 테셀레이터에게 어떤 방식으로 수행해야 하는지도 말해준다. - 개발자는 테셀레이터 연산이 완료되는 방법을 한정시킬 수 있을 것인데, 비록 테셀레이션 유닛이 고정된 기능만 수행하더라도, 여기에는 약간의 구동 방식이 있기 때문이다.

이 테셀레이터는 외피 쉐이더에서 제공된 정보를 취하게 되며 작은 지역에 대해 추가적인 지오메트리 요구 사항을 생성하는 작업을 하게 된다. 이것이 완료되면, 이것은 주요 지점과 토폴로지 데이터로 출력된다.

이 주요 지점은 주력 쉐이더를 지나게 되는데, 이것은 지점 당 기반으로 작업하는데, 주력 지점을 취하여 나머지 파이프라인에서 이해가 가능하도록 점을 생성하게 된다. 한편, 토폴로지 데이터는 파이프라인의 초기 조립 스테이지로 바로 내려가게 된다. - 이것의 이유는 이 데이터는 쉐이더에서 필요로 하지 않지만, 래스터라이져에서 필요로 하기 때문이다.

여기서 중요한 것은 파이프라인의 모든 테셀레이션 스테이지는 삼각형으로 작업하지 않는다. ; 대신, 이것은 패치와 점들로 작업하게 된다. 패치들은 표면의 영역이나 곡면을 나타내며 보통 4개 묶음으로 표시된다. 물론, 패치들은 삼각형으로도 표시될 수 있지만, 이것은 드문 일이데 대부분의 3D 저작 어플리케이션은 4개 묶음으로 작동한다. 이것은 DirectX 가 최초로 삼각형으로 작업하지 않는 것이며, 엄청난 단계가 앞에 아직 펼쳐져 있다.

위에 기술한 모든 것은 DX11 파이프라인을 거친 1번의 패스를 완료시킨 것으로, 차후 나올 게임 내에서는 추가적으로 훨씬 세밀함을 엄청나게 효율적인 방법으로 실행할 잠재력을 갖고 있는 것이다. 물론, 개발자들은 원하지도 않는데 파이프라인의 이들 스테이지를 꼭 사용해야 하는 것은 아니다. - 테셀레이션은 필요치 않으면 완벽히 우회할 수 있다.

5페이지

계산 쉐이더

테셀레이션을 접어두면, DirectX 11에서의 또다른 주된 추가점은 계산 쉐이더이다. 이것은 특별히 새로운 것도 아니다.; 이것은 AMD와 Nvidia가 몇년동안 말해왔던 것을 더욱 형상화 시킨것이다.

Nvidia는 특히 그들의 CUDA 플랫폼을 2006년 11월 Geforce 8800GTX 출시에 맞추어 더욱 중점적으로 밀어부쳤다. - 이것은 지금까진 엄청난 병렬 연산에 가장 가깝게 우리가 접근할 수 있는 것이었다. 이와 더불어, 현재의 플랫폼 교차 호환성에 대한 부족은 CUDA가 넓은 시장에 진출하는 것을 용납하지 못하게 하는 역병과도 같았다. 이것은, 최소한 완벽한 프로그램성의 왕좌로 들어가기 위한 과도기라고 볼 수 있다.

CUDA에서 명백한 것은 Nvidia의 설계자가 실리콘의 조각에서 나온 아무 짓도 안하는 GPU를 그래픽 문제를 푸는 엄청난 병렬 범용 어플리케이션에서 가속시킬 수 있는 능력을 가진 것으로 변형시켰다는 것이다. CUDA를 사용해서 가속된 어플리케이션의 대부분은 시장에 모습을 나타내기 시작하였으며 Intel 또한 자리를 잡으려고 자세를 잡고 있다.

AMD는 그들의 Stream Computing 를 표방하며 같은 작업을 하여 왔으며 여기에 ATi Radeon 그래픽 카드 기반의 몇몇 소비자 지향 어플리케이션이 곧 도래할 것이다. 그렇지만 흥미롭게도, Microsoft의 DirectX 11 내의 연산 쉐이더 포함은 범용 GPU 연산보다는 게이밍 관점을 더 중점적으로 잡아 도입한 것처럼 보인다. 그러나, 몇몇 업체들과의 대담 후에, 연산 쉐이더는 게임 개발자에게 직면한 특정 문제를 푸는 것 이상의 역할을 할 것이라는 것을 알게 되었다.

Nvision에서 프리젠테이션 중에 한 Gee 와의 대담은 상당량 새로운것은 없었지만, DirectX 측면에서는 새로운 것이 많았다. 삼각형을 사용하지 않고, 스레드간 데이터를 공유하는 것이나 분산된 쓰기 명령을 제어하지 않으면서 범용 코드를 작성하는 것이 AMD의 Stream SDK나 Nvidia의 CUDA 컴파일러 모두에게서 가능하지만, 현재로써는 모든 중요한 하드웨어의 호환성을 유지하는 것이 불가능하다는 것이 중론이다. Microsoft는 이런 새로운 코딩 확장자와 문법을 HLSL(고레벨 쉐이딩 언어) 의 갱신된 버젼에서 사용 가능케 할 것이다.

이런것을 주지하면, 그래픽 파이프라인은 전통적으로 CPU에 의해 조정되는 범용 연산 작업과 연관되는 데이터 구조를 생성할 수 있을 것이다. 연산 쉐이더를 이용함으로써, 이들 작업들은 다수개의 코어 상을 지나면서 어플리케이션 자체를 병렬적으로 들여다 보게 될 것이다. Microsoft에 따르면, 연산 쉐이더에 대한 주된 목표 어플리케이션은 후처리, 물리, 그리고 인공지능 등을 포함하게 될 것이라 한다. Gee가 언급한 다른것들 중 하나는, 빛 추적이었다.

가장 중점적으로 언급한 것은 게임 내 물리이다. 현재, 개발자들은 3개 선택사항 사이의 갈림길에 놓여있게 되었다. : PhysX, Havok과 그들 고유의 물리 엔진을 제작하는 것이 그것이다. 내 의견으로는 이들 중 최상의 선택은 없는데, 왜냐면 개발자들의 세가지 선택사항 모두 한가지 방향으로만 제한되어 있기 때문이다.

PhysX는 Nvidia 의 CUDA가 적용되는 GPU에 의해서만 가속되지만, CPU 상에서 작동하는 반면 Havok은 곧 AMD GPU에 의해 가속이 되며 CPU에서 손을 떼게 될 것이다. 마지막으로, 당신 고유의 물리 엔진을 코딩하는 것은 아주 큰 노력이 필요하며 개발자로써는, CPU에 대한 작동을 대부분 선택할 것인데 왜냐면 당신이 게임을 구동시킬 모든 시스템은 비슷비슷한 기능 세트를 갖고 있기 때문이다. 현재로써는 GPU를 표준화 시키는 것은 그렇게 쉬운 일이 아닌데 그들의 유사성은 API 호환성에서 끝나기 때문이다. 연산 쉐이더 - 아니면 이런 경우 OpenCL - 로 이런 골치 아픔은 없어지며 개발자는 게임 중 물리를 집적하는 것에 집중할 수 있다.

이렇게 말하지만, 게임 상의 물리가 게임에 중점적으로 집적되는 것은 약간 시간이 걸릴 것이다. - 물리 가속 엔진이 없는 누군가가 게임을 한다는 것으로 인해 그들은 물리엔진을 무조건 집어넣지 않을 것이다. 이런것 때문에, DirectX 11이 게임 개발자에게 있어 최소 사양이 되기 전 까지는 게임 상의 물리에 있어 "아주 엄청난 무언가"를 볼 순 없다고 생각한다.

6페이지

멀티 스레딩

그래픽 파이프라인에서 멀티 스레딩이 새로운 부분이 아니더라도, 그 자체로는, DirectX 11에게는 엄청나게 중요한 기능이다. 이것은 드라이버 업데이트를 통해 DX10 등급의 하드웨어에서 이런 성능 향상을 이룰 때 엄청나게 중요성이 증대되게 되었다.

듀얼코어 CPU들은 오늘날 주력이며 쿼드코어는 게이머나 매니악들에게 비교적 저렴한 선택사항이 되었다. - 미래에는, 쿼드코어는 듀얼코어를 실권에서 끌어내릴 것이다. 이런것을 생각 할 때, DirectX 가 멀티 스레딩을 여전히 지원하지 않는다는 것은 실질적으로 엄청나게 놀랄만한 일이다. 거두절미하고, AMD와 Nvidia는 멀티스레드 드라이버에 대한 작업중이지만, API가 절대적으로 싱글스레드 중심이라 이것의 성공에 대한 여부는 극히 제한적이게 된다.

우리는 멀티 스레딩에 관해 몇몇의 개발자와 이야기를 나누어 보았었다. - 그 중 몇명은 코어 갯수를 늘려 그들의 사용률을 늘리는 방법을 선택하는 반면, 다른 사람들은 성능을 더욱 뽑아내기 위해 노력하며 추가되는 코어들을 놀도록 냅두게 하기도 한다. 개발자들이 오늘날에는 스레딩에 관해 생각하기 시작했기 때문에 이 문제는 점차 잦아들고 있지만, 어플리케이션이 엄청나게 CPU 제한적이라는 시나리오에서는 여전히 똑같다.

고맙게도, 이것은 DirectX 11과 Microsoft로 하여금 이런 이득을  DirectX 10 등급의 하드웨어에서도 사용할 수 있게 만들 것이다. AMD와 Nvidia의 드라이버 팀들은 이들의 드라이버에 이것을 내장하는 작업을 해야 하지만, 그들은 이미 DX 11 하드웨어에 대한 작업을 하고 있기 때문에, DX 10 GPU들에 지원 추가를 세밀하게 할 것같지는 않다.

Microsoft는 Direct3D 기기를 3개의 분리된 인터페이스로 성공적으로 나누었다. : 기기, 즉각적인 상황과 지연된 상황이 그것이다. 각각 이것들은 스레드에 할당 되어있으며 기기와 지연 정황 인터페이스는, 즉각적 정황이나 렌더 스레드를 위해 1개 이상의 스레드가 순차 작업으로 할당될 수 있다.

스레드간 전환은 정교하다 하는데, 그러므로 개발자들은 수동으로 얼마나 그리고 어떤 명령이 즉각적 상황 인터페이스에 등록이 되는지를 수동으로 정할 수 있게 된다. 각기 기기 인터페이스는 스레드 자원을 원할 때마다 불러올 수 있는 반면, 지연적 상황 인터페이스는 차후 렌더링 수행을 위해 스레드 당 기기 상황으로 행동하게 된다. - 이것은 즉각 상황 인터페이스에 준비되었을 때 이것들을 지나가기 전의 그리기 주문을 정렬시키게 된다.

DirectX 10 등급의 하드웨어에는, 지연 상황 인터페이스는 멀티스레드를 위한 새로운 하드웨어 기반 최적화가 있어야 하기 때문에 하드웨어 대신 소프트웨어적인 도입이 필요하게 된다. 이것 때문에, 지연 상황 인터페이스는 DX 10 하드웨어 상에서는 자유로운 스레드를 하지 못하며 분리된 스레드는 API 레벨에서 지연 정황에 발이 묶일 것이다.

7페이지

동적 쉐이더 연합

오늘날 게임 개발자가 직면한 문제 중 하나는 쉐이더의 유연성과 수용성인데 이것들은 점점 갈수록 복잡해지고 있다. 예를들어, 다수개의 쉐이더들이 특정 시나리오를 필요로 한다면, 하나의 엄청난 쉐이더가 쓰이기도 하는데, 모든 쉐이더를 모아서 처리하여 1개의 코드로 처리하는 것이 이 시나리오에 필요할 때가 있기 때문이다.

그러나, 이런 접근에서의 단점은 엄청나게 복잡한 쉐이더가 나오게 되어 이것들이 각개 쉐이더보다 (성능 면에서) 비효율적일 뿐만 아니라, 디버그 하기에도 어렵다는 결과를 낳게 된다.  다른 해결책은 모든 시나리오만을 커버하는 특정 쉐이더를 많이 제작하면서, 하드웨어 또한 각기 다른 등급을 지정하는 방법이 있다.

성능적인 이유로 인해, 그렇게 작업을 빠르게 처리 하지도 못하는 하드웨어 상의 엄청나게 복잡한 쉐이더를 사용하기는 싫어질 것이다. 가장 최고의 방법은 저렴한 하드웨어를 위해 더욱 간단하게 사용하는 것이다. - 이것은 결국엔 너무 복잡해지며 쉐이더 전환에 관련된 중복을 만들게 된다. 이해 할 수 없겠지만, 이것은 엄청난 추가 작업을 초래하게 된다. - 이 엄청난 쉐이더는 코드를 작성할 때 개발자에게는 가장 쉬운 선택사항이지만, 위에 기술한 것들 때문에 이상적인 해결책은 절대 아니다.

Microsoft는 이 문제에 대한 답변을 서브루틴에서 찾을 수 있다고 믿는데, 개발자로 하여금 쉐이더를 같이 연계 하는 것을 가능하게 하는 것이다. - 이것은 개발자로 하여금 목표가 되는 하드웨어의 각기 다른 등급에 대한 간단하고, 더욱 특화된 쉐이더를 생성시킬 수 있게 하도록 하는 것을 뜻하는데, 또한 이것은 모든것을 지배하는 한개의 쉐이더에 비해 레지스터 사용량 또한 줄어드는 효과가 있다. 희망적이게도, 이것은 개발자가 쉐이더를 프로그래밍할 때 좀 더 자신만의 쉐이더를 만들 수 있겠지만 게이머에게는 그렇게 직접적인 영향을 주지는 못한다는 점에서 이질적이다.

향상된 텍스쳐 압축

Microsoft가 DirectX 의 텍스쳐 압축 알고리즘을 갱신한지 오랜 시간이 흘렀고, 이후 개발자의 피드백을 경청하여, 회사는 기능의 향상이 늦었다는 것을 느끼게 된다. 개발 커뮤니티에서의 불만들이 정리되어, Microsoft는 HDR 텍스쳐 포맷의 지원 부족을 알게 되었으며, 또한 멀티 텍스쳐링에서, 원본 텍스쳐의 해상도에 상관 없이 결과가 엄청난 깍두기가 나온다는 것을 알게 되었다.

이런 요구들을 충족 시키기 위해, D3D11은 2개의 새로운 텍스쳐 포맷을 소개하게 된다. - BC6(BC6H) 와 BC7이 그것이다. 이것은 고해상 텍스쳐 포맷으로 불행하게도 무손실은 아니다.; 대신, 이것은 16bpc(bit per channel, 채널 당 비트) 로 6:1 압축을 제공한다. - 이것으로 하여금 효율적이지만 수긍할 정도의 고품질 텍스쳐를 화면에서 볼 수 있으며 HDR 광원의 확장된 사용이 가능해졌지만, 원본과 똑같지는 않을 것이다.

반면 BC7은, LDR(Low Dynamic Range) 텍스쳐 포맷으로 RGB의 3:1 압축비를 제공하게 된다, 게다가, BC7은 품질 면에서 적은 손실을 주고 알파 채널에 관련하여 쓰일 수 있다. - 4:1 비율인데 앞서 언급한 3:1 압축비율과 비교된다. - 그러나 이것은 여전히 고품질이 유지된다.

이것에 첨언하자면, Microsoft는 DirectX 11에서의 텍스쳐 압축 풀기는 API의 사양에 완벽하게 맞춘 방법으로 완료해야 한다고 말하였다. 이것에 대한 이유는, 계속적으로 압축 해제 품질을 증가시키기 때문이며, DirectX 11이 도래하기 전까지는, 하드웨어 벤더들이 DirectX 10 이전 하드웨어들의 텍스쳐 압축 해제를 제어할 트윅을 할 방법에 대한 시간적 여유가 있을 것이다.

출처 : http://www.bit-tech.net/bits/2008/09/17/directx-11-a-look-at-what-s-coming/1