DirectX 8.0의 질문과 답

 최근 DirectX 8.0의 출시와 함께 기존의 DirectX 7.0과의 차이라던지 추가된 기능의 구체적인 사례, 앞으로의 가능성에 대해서 많은 궁금증들이 있어 왔다. 물론 이미 많은 게이머들이 DirectX 8.0을 설치해서 사용하고 있지만, DX8이 어떠한 장점을 준다거나, 줄 것인지에 대해서는 정보가 부족했던 것이 사실이다. 물론 개발자 수준에서야 이미 다 알고 있어야 하는 정보겠지만, 게이머의 입장에서나 3D 기술에 관심이 많은 일반 사용자들도 관심을 가질 만한 부분임에는 틀림없다.

 본지는 최근 디지틀-라이프에 게재된 DirectX 8.0에 대한 FAQ를 기반으로 DX 8.0에 대해서 좀더 자세히 접근하는 시간을 갖기로 했다. 기술적인 부분이나 다소 난해한 부분의 번역이 좀 미숙해 보이는 부분도 있고 특별히 필요한 부분은 역주를 다는 등의 첨삭을 가했다. 게이머의 입장에서, 또한 DX8과 가장 많이 접하는 입장에서 그 동안 DX 8.0에 대해서 가져왔던 궁금증을 이번 기사를 통해서 다소나마 해소시키는 계기가 마련되었으면 한다.

------------------------------------------------------------------------------------질문 : 다이렉트X 8.0이 정말로 프로그램 루틴으로부터 프로그래머를 구해줍니까? 무지막지한 코드를 쓰지 않아도 된다는 말이 진실인가요?

답변 : 예, 소스코드의 양이 많이 줄었습니다. 우선 D3D 초기화의 구현이 무척 쉬워졌습니다. 이전에는 정해진 순서대로 약 20~30여가지의 함수를 부르는 난리를 쳐야했고 그와함께 고정된 많은 수의 파라미터가 필요했었습니다. 하지만 이제는 대략 10여가지의 파라미터들과 오직 두가지의 함수 콜만으로도 그 일이 가능해 졌습니다. 가령 텍스처를 생성하는 프로세서나 이미지 압축을 할때도 조악하게 만들어진 파라미터를 이용한 정리되지 못한 함수콜 구조를 사용하지 않아도 됩니다. 6개의 파라미터를 가진 단 하나의 함수 콜만으로도 그 일이 가능합니다. 그게 전부죠.

질문 : 어떻게 DX8의 퍼포먼스를 측정해 볼 수 있습니까? 이전의 프로그램과 DX8을 사용한 프로그램과의 차이가 명백합니까?

답변 : DX8을 고려하지 않은 프로그램(역주 - 가령, DX7으로 작성된 프로그램)의 경우 DX8안에 포함된 개선된 DX7 라이브러리 때문에 5~10% 정도의 성능 향상 말고는 개선점이 없습니다. 이것은 DX8이 DX7의 수퍼셋이기 때문입니다.

하지만 만약 DX8 코드로 쓰여진 프로그램이라면 DX8의 순수기능 사용 비율에 따라 5%~50%의 성능 향상을 기대할 수 있습니다. 가령 vertex shaders 기능을 사용하고 DX8의 하드웨어 가속을 지원하는 그래픽 카드가 있다면 말입니다.(역주 - 당연한 것 아닌가?)

질문 : DX7과의 비교에서 눈에 띄일 만한 성능 향상을 위해 어플리케이션 차원에서 DX8을 고려한 최적화가 필요합니까?

답변 : 그것은 경우에 따라서 달라집니다. DX8에 포함된 pixel shader나 vertex shader 기능은 개발자들로 하여금 효과에 대한 상상력의 제한을 두지 않습니다. DX8에 포함된 다양한 기능들을 사용하고자 한다면(가령 T-buffer 같은 기능) 그러한 기능에 대한 별도의 코드를 고려해서 프로그램을 작성해야 합니다.

질문 : DX8을 사용한다고 가정할때 이미 DX7으로 작성된 어플리케이션이 스피드나 퀄리티 측면에서 어떠한 개선도 없다고 하는데, 과연 사실인가요?

답변 : 퀄리티의 경우라면 사실 제가 보기에도 그렇습니다. 속도 문제라면 아래의 퍼포먼스와 관련된 부분을 좀더 참고해 주시기 바랍니다.

질문 : 코드를 작성하는 부분이나 가독성 문제에 대해서는 어떻게 생각하십니까?

답변 : DX7과 비교한다면 정말 많이 개선되었습니다!

질문 : 오픈지엘 표준 1.2 스펙과 관련하여 DX8의 지원 정도는 어떻습니까?

답변 : 오픈지엘 혹은 앞으로의 오픈지엘 스펙은 새로운 기능의 추가에 대한 일종의 공통적인 확장스펙 규격입니다. 오픈지엘을 통해서 우리들은 새로운 스펙을 만들고 또한 하드웨어의 새로운 기능에 액서스를 할 수 있습니다. 하지만 거기에는 한가지 문제점이 있습니다. 올해 DX8 스펙 규격에 호환되는 다양한 카드들이 존재하고 있습니다. 가령 ATI나 nVIDIA사의 제품들이죠. 이러한 새로운 제품들은 오픈지엘 1.2 스펙의 새로운 확장 기능들을 지원할 것입니다. 하지만 이런 부분들이 앞서 얘기한 제품들 모두에게 동일한 기능을 가진 공통된 확장 스펙의 지원을 완벽히 보장한다는 말은 아닙니다. 그리고 프로그래머가 다양한 하드웨어에 대한 코드를 별도로 일일이 작성한다는 것도 엄청난 삽질입니다

 오픈지엘은 pixel shader나 vertex shader를 가지고 있지 않습니다. 하지만 편리성이나 API의 통합을 위해 많은 개선을 이루고 있습니다. 그래서 쉐이딩 기능은 별도의 오픈지엘 확장 시스템(역주 : 가령, 별도의 드라이버)을 통해서 지원이 될 것입니다. 그것은 데이터를 다루는 것이 아닌 펑션콜의 집합들로 가능할 것입니다. 많은 하드웨어 벤더들은 그들만의 별도의 오픈지엘 지원 드라이버를 갖추게 될 것이란 말입니다.

 pixel shader나 vertex shader에 대해서는 몇가지 이야기가 더 있습니다. 하드웨어가 특화되면서 필드에서 굴러가는 제품들의 유연성이 점점 줄고 있습니다. 이 말은 곧 2D 이미지 프로세싱이나 멀티 텍스처 최적화에 대한 부분이 다양한 하드웨어들 사이에서 전혀 따로 놀고 있다는 뜻이죠. 이러한 연산들은 이제 거의 하드웨어 나름대로의 특화된 부분에 남겨지게 되었습니다. 가령 T&L의 경우도 그렇습니다. 특화된 그래픽 하드웨어의 발달이 곧 좌표변환 시스템과 라이팅 요소들에 대한 유연성을 떨어뜨리는 결과를 가져왔습니다. 쉐이딩 기능의 주요 목적은 프로그래머로 하여금 좌표변환 시스템(vertex shaders)이나 레스터 프로세싱(pixel shaders)에 있어서 유연성을 주고자 하는 것이거든요.

[Q]DX 8.0의 완전히 새로운 개념은 무엇입니까?

[A] 많은 것이 있습니다. 아래에 그것들을 차례대로 나열해 보았습니다.

Direct3D: 위에서 설명한 대로의 픽셀과 버텍스 쉐이더들이 있습니다.

DirectPlayVoice : 게임중에 네트워크를 이용한 실제 음성 통신을 할 수 있습니다. 이 기능은 다른 음향효과를 만들기 위해 DirectSound 와 조합하여 사용되고, 인터넷을 통한 전송을 위해 DirectPlay 와 함께 사용됩니다. (역주 - DirectPlay의 일반적인 성능이 얼마나 나올까 하는 것은 아무도 모르는 일입니다.)

DirectInput 도 주목할 만한 변화를 하였습니다. 커맨드 정의 기능이 존재하기 때문에 자신의 고유한 맵을 텍스트 파일로 만들어서 여러분의 만의 독특한 커맨드로 로드 할 수 있고, 또한 DirectInput 입력과도(가령 키보드 입력이나 마우스) 바로 대응 됩니다. 그런한 대응은 곧 당신이 원하는 커맨드 명령과 바로 대응 됩니다. (역주 - 이미 M$는 게임보이스 라는 장난감 같은 헤드셋을 통해서 이것을 선보였었다.) resister는 여러분들의 그런 명령어 셋을 저장해 놓았다가, 원하는 다양한 장비들과 결합시켜 줍니다.

[Q]: DX 가 다른 플랫폼으로 이식될 전망이 있습니까?

[A]: (역주 - 바봅니까? 빌게이츠는 자선사업가가 아닙니다.) 오로지 Windows 와 XBox 에서만 사용될 것입니다. 다른 곳에는 필요가 없습니다. 그리고 제가 생각하기에 XBox 는 곧 주된 플랫폼이 될 것입니다. 왜 다른 플랫폼에 DX가 필요할까요? 아무도 리눅스 서버에서 게임을 하지 않을 것이며, 모두가 XBox 를 이용해서 집에서 게임을 즐기게 될 것입니다. 이것은 저의 의견입니다. (역주 - 지금의 FAQ 문장으로 볼 때 이 답변자는 M$의 첩자 같습니다.)

[Q]: DX8 은 오로지 게임만을 위한 것입니까?

[A] : 예 그렇습니다. M$ 는 안정성이 속도보다 더 중요한 강력한 어플리케이션에 OpenGL을 사용할 것과 DX 는 속도가 가장 중요한 게임에 사용할 것이라고 발표하였습니다. (역주 - 책임의 전가라는 것은 이런 것을 말합니다.)

[Q]: 아직 시장에는 하드웨적으로 모든 shader를 지원하는 가속기를 공급하지 않고 있습니다. 에뮬레이션을 이용한다면 일반적인 가속기(TNT Class)를 사용하였을 때 어느 정도의 퍼포먼스 저하가 있는지, 그리고 곧 출시할 가속기들은 부분적으로 shader를 지원하게 될 것인지 말씀해 주시기 바랍니다. (역주 - 아래의 두 문장은 거짓말이 많이 섞여 있습니다.)

[A]: pixel shader를 고려한다면, 우리는 아무런 하드웨어적 지원이 없고 또 없을 것이라고 말할 수 있습니다. 이것은 pixel shader 가 모든 픽셀을 처리해야 한다는 것으로 설명할 수 있고, 이러한 에뮬레이션을 위해서는 전체 이미지를 소프트웨어적으로 다시 뿌려 줄 필요가 있습니다.

Vertex Shader 같은 경우는 조금 상황이 나아 보입니다. 보통의 하드웨어 T&L 이 없는 카드도 분명히 퍼포먼스 저하를 일으키지는 않을 것입니다. 우리는 최적화된 vertex buffer를 사용함으로써 퍼포먼스를 얻을 것입니다. 반면에 vertex shader 의 interpreter 는 다른면에서 퍼포먼스의 저하를 야기할 것입니다. 하지만 이 두 가지는 서로 상호보완적이 될 것입니다.

M$ 는 부분적인 Shader 지원에 반대합니다. 사실상 이것은 OGL 확장에 대한 호환성이 없어 결국엔 실패하게 될 것입니다. 여러분이 N-shader 의 모든 커맨드를 지원하던 않하던 간에 말입니다. 이러한 관점에서 GeForce 와 GeForce2 는 DX7에서 DX8 로 변화하는 과도기적인 카드이며 DX8 의 shader를 지원하지 않을 것입니다. (역주 - 그럼 XBOX는 도대체 무슨 괴물이란 말야? --;)

[Q]Texture 처리 시스템에 주목할 만한 차이점이 있습니까?

[A]: DX8 의 resource 관리는 일반화되어 있습니다. 이제 resource의 의미는 텍스처뿐만 아니라 vertex buffer 와 index buffer를 포함하고 있습니다. 외면적 관리는 같습니다. - 각자의 리소스는 각각의 우선권(priority)을 갖게되며, 드라이버(혹은 D3D)는 이런 리소스들을 우선권과 요구에 의해 하나 혹은 다른 메모리에 전송합니다. M$ 는 DX8 의 리소스 관리자의 알고리즘에 상당한 향상이 있다고 발표하였습니다.

[Q]: 프로그램 측면에서의 문맥전환과 관련하여 그 부분의 코드를 저장하는 편리한 방법이 있습니까? 또한, 순차적 작업중에 저장 할 수 있거나 다음 요구(list)에 대해 네이밍을 해놓을 수 있습니까?

[A]: 그러한 가능성들은 DX7의 상태블록에도 이미 나타나 있습니다. 기능적인 측면으로 볼 때 OGL 의 display lists 보다는 조금 못합니다. - 여기에 여러분은 오로지 상태(State)을 기록할 수만 있고 (역주 가령 - render state / texture stage state / transform / viewport / clipplane / texture / light / material) vertex 나 index 의 데이터는 비록 쓰기가 가능하더라도 쓸 수 없습니다.

Shader 는 상태블록의 일반화된 개념입니다. - 여기에 여러분은 직접 필요한 작업의 순차를 만들 수 있고 유일한 식별자로 이것을 저장할 수도 있습니다.