그래픽 API를 사용해야합니까?

3D 게임에서 하드웨어 가속을 얻으려면 그래픽 API를 사용해야합니까? OpenGL, DirectX , CUDA, OpenCL 등과 같은 그래픽 카드 API에 대한 종속성을 어느 정도까지 해제 할 수 있습니까?

게임용 그래픽 API 또는 라이브러리를 만들 수 있습니까? 어려운 경우에도 이론적 으로 내 3D 응용 프로그램이 그래픽 드라이버에 독립적으로 연락하여 GPU에서 모든 것을 렌더링 할 수 있습니까?

많은 답변이 중요한 점을 놓치고 있다고 생각합니다. 하드웨어에 직접 액세스 하지만 최신 운영 체제 에서는 액세스 하지 않는 앱을 작성할 수 있습니다 . 그것은 단지 시간 문제가 아니라 "선택할 수없는"문제입니다.

Windows, Linux, OSX 등은 모두 임의의 응용 프로그램에 대한 직접적인 하드웨어 액세스를 금지합니다. 이것은 보안상의 이유로 중요합니다. 임의의 앱이 시스템 메모리를 읽을 수없는 것과 같은 이유로 임의의 앱이 임의의 GPU 메모리를 읽을 수 없도록하려는 경우. 은행 계좌의 프레임 버퍼 또는 GPU 메모리에없는 것들. 당신은 당신의 OS에 의해 격리되고 보호되고 액세스 제어되는 것들을 원합니다.

드라이버 만이 대부분의 하드웨어와 직접 대화 할 수 있으며 드라이버와 대화하는 유일한 방법은 OS의 노출 된 HAL과 각 드라이버의 독점적이고 호환되지 않는 인터페이스를 통하는 것입니다. 해당 드라이버 인터페이스는 공급 업체마다 다를뿐 아니라 드라이버 버전마다 다를 수 있으므로 소비자 응용 프로그램의 인터페이스와 직접 통신하는 것이 거의 불가능합니다. 이러한 계층은 종종 응용 프로그램이 해당 계층에 액세스하는 기능을 더욱 제한하는 액세스 제어로 덮여 있습니다.

따라서 아닙니다. 물론 DOS와 같은 안전하지 않은 운영 체제만을 대상으로하지 않는 한 게임에서 하드웨어를 직접 사용할 수 없으며 최신 소비자 운영 체제의 게임에 적합한 유일한 옵션은 DirectX, OpenGL 또는 불칸.

실제로 필요한 것입니다. 여러 다른 하드웨어 구성을 위해 본질적으로 드라이버 코드를 작성하는 데 몇 년을 소비하지 않으려면 널리 사용되는 모든 운영 체제 및 하드웨어에 대해 GPU 공급 업체가 작성한 기존 드라이버와 통합하는 API를 사용해야합니다.

유일한 현실적인 대안은 3D 가속을 사용하지 않고 C와 같은 휴대용으로 작성하면 거의 모든 시스템 / 장치에서 실행할 수있는 소프트웨어 렌더링을 수행하는 것입니다. 작은 게임 에는 좋습니다. SDL 과 같은 것이이 목적에 적합합니다. 다른 게임 도 있습니다. 그러나 여기에는 고유 한 3D 기능이 없으므로 직접 빌드해야합니다. 사소한 작업이 아닙니다.

또한 CPU 렌더링은 비효율적이며 GPU에 비해 ​​성능이 저하됩니다.

OpenGL 또는 DirectX와 같은 API는 운영 체제에서 부분적으로 구현되고 그래픽 드라이버 자체에서 부분적으로 구현됩니다.

즉, 최신 GPU의 기능을 사용하는 자체 저수준 API를 만들려면 기본적으로 자체 그래픽 드라이버를 작성해야합니다. 드라이버가 모든 일반 그래픽 카드와 작동하는지 확인하는 것은 특히 어려운 일입니다. 특히 공급 업체가 사양을 공개하지 않기 때문입니다.

PC를 MS-DOS로 부팅하십시오. 그런 다음 PC 게임 프로그래머 백과 사전 을 사용하여 카드의 VESA 레지스터와 비디오 메모리에 직접 쓸 수 있습니다 . 나는 20 년 전에 이것을 작성하고 소프트웨어에서 기초 3D를 렌더링하기 위해 작성한 코드를 여전히 가지고 있습니다.

또는 DirectX를 사용할 수도 있습니다. 정말 얇은 추상화 계층이며 비디오 버퍼에 직접 쓰고 화면으로 바꿀 수 있습니다.

자신 만의 비디오 하드웨어 를 구축 하는 극단적 인 방법도 있습니다 .

다른 답변은 주요 질문에 아주 잘 대답합니다. 기술적으로는 가능하지만 실제로 목표가 고객 기반을 넓히는 것이 실제로 반대 일 경우입니다. 수천 개의 서로 다른 하드웨어 및 OS 구성을 지원하는 데 많은 양의 작업을 낭비하면서 지원해야합니다.

그러나 이것이 하나의 특정 API에 100 % 의존해야한다는 의미는 아닙니다. 항상 자신 만의 추상화 계층을 코딩 한 다음보다 구체적인 구현 (예 : DirectX 구현, OpenGL 구현 등)을주고받을 수 있습니다.

그렇더라도 가치가 없을 것입니다. 당신의 목적을 위해 충분히 잘 작동하는 것을 고르십시오. 당신은 인디 게임 제작자입니다-당신은 미누 타가 아닌 게임을 만드는 것에 집중해야합니다. 그냥 게임을하세요!

요약하면 : 이론적으로는 가능하지만 실행할 수 없으며 이점이 없습니다. CUDA와 OpenCL 및 셰이더는 오늘날 API의 한계가 날로 줄어들고 있습니다. 따라서 모든 권한을 갖는 것은 더 이상 문제가되지 않습니다.

자세한 설명 :

이것에 대답하는 것은 지루한 예 입니다. 진짜 질문은 왜 ?

왜 학습 목적 이외의 다른 일을하고자하는지 거의 상상할 수 없습니다. 어느 시점에서 개발자는 자신의 CPU 렌더링 구현으로 무엇이든 할 수있는 자유가 있고, 모든 사람이 자신의 API를 가지고 있으며, "파이프 라인"의 모든 것을 제어 할 수 있다는 것을 알아야합니다. 고정 파이프 라인 및 GPU의 도입으로 모든 사람들이 전환했습니다.

GPU를 사용하면 "더 나은"성능을 얻을 수 있지만 많은 자유를 잃게됩니다. 그래픽 개발자는 자유를 되 찾으려고 추진하고 있습니다. 따라서 매일 더 많은 사용자 정의 파이프 라인이 필요합니다. 드라이버를 건드리지 않고 CUDA / OpenCL 및 심지어 쉐이더를 사용하여 거의 모든 작업을 수행 할 수 있습니다.

하드웨어와 대화하고 싶습니다. 하드웨어와 대화하는 방법을 사용해야합니다. 그렇게하면 하드웨어에 대한 인터페이스가됩니다. 이것이 OpenGL, DirectX, CUDA, OpenCL 및 기타입니다.

낮은 수준에 도달하면 낮은 수준의 인터페이스를 사용하고 있지만 여전히 높은 수준의 카드와 다른 카드로는 작동하지 않는 인터페이스 만 사용하고 있습니다.

기존 API를 사용하지 않고 3D 하드웨어 가속 을 얻으려면 기본적으로 그래픽 드라이버의 기능을 복제하는 고유 한 코드를 작성해야합니다. 따라서이를 수행하는 가장 좋은 방법은 그래픽 드라이버의 코드를 보는 것입니다.

NVIDIA 카드의 경우 오픈 소스 누보 프로젝트를 살펴보십시오 . 여기에는 훌륭한 자료가 있습니다 .

다른 브랜드의 그래픽 카드의 경우 유사한 프로젝트 및 문서를 찾을 수 있습니다.

다른 답변에서 언급했듯이 대부분의 최신 운영 체제는 사용자 공간 프로그램이 하드웨어에 직접 액세스하지 못하게하므로 코드를 작성하고 운영 체제 드라이버로 설치해야합니다. 또는 그러한 제한이없는 FreeDOS 운영 체제를 사용할 수 있으며 이론적으로 하드웨어에 직접 액세스하여 3D 하드웨어 가속 그래픽을 렌더링하는 일반 프로그램을 작성할 수 있습니다. 기존의 오픈 소스 그래픽 드라이버의 코드를 활용하더라도 엄청난 양의 비공식 작업이 될 것입니다. 기술적으로 가능합니다).

DirectX 또는 OpenGl을 제거해도 종속성이 제거되지 않고 더 많은 종속성이 발생합니다. 다른 답변에는 이미 그래픽 하드웨어와 직접 대화 할 수없는 몇 가지 좋은 점이 포함되어 있지만 (적어도 실현 가능하지는 않습니다) 첫 번째 대답은 다음과 같습니다. 사실 실제로 모든 일반적인 3D를 추상화하는 라이브러리를 작성하면 그래픽 하드웨어를 단일 API로 통합하면 DirectX / OpenGl을 효과적으로 다시 작성할 수 있습니다. 코드를 사용하여 게임을 작성한다면 DirectX / OpenGl을 종속성으로 사용하는 것처럼 새 라이브러리를 새로운 종속성으로 추가했을 것입니다.

DirectX 또는 OpenGl을 사용하여 종속성은 기본적으로 "이 코드는 라이브러리에 따라 다른 그래픽 카드에서 특정 명령을 실행하는 방법을 설명하는 코드를 제공합니다"라고 말합니다. 그러한 라이브러리가 없다면 "이 코드는 게임을 만들 때 존재했던 하드웨어와 정확히 같은 방식으로 동작하는 그래픽 하드웨어에 의존합니다."

OpenGl 또는 DirectX와 같은 추상화를 통해 하드웨어 제조업체는 공통 코드 기반으로 이끄는 자체 드라이버 (드라이버)를 제공 할 수 있으므로 게임 작성시 존재하지 않았던 하드웨어에서 게임을 실행할 가능성이 높습니다.

우선, CUDA와 OpenCL은 그래픽 API가 아닙니다. 그들은 계산 API입니다.

자신 만의 그래픽 API를 작성하는 데있어 문제는 매우 복잡하다는 것입니다. 하드웨어와 직접 인터페이스 할 수 있지만 X CPU, X GPU, X 램 양 및 X 운영 체제가있는 시스템에서 작동하는 경우 Y CPU, Y GPU 등이있는 시스템에서 작동한다는 보장은 없습니다. 한 가지 좋은 점은 DirectX가 커널 모드 드라이버와 함께 작동한다는 것입니다. 커널에 뿌리를두고 있습니다. 또한 그래픽 API는 GPU를 지원하도록 제작되지 않았습니다. GPU (및 해당 드라이버)는이를 지원하도록 제작되었습니다. 따라서 자체 OS를 빌드하고 x86 제공 VGA 인터럽트를 사용하지 않으면 그래픽 API를 거의 작성할 수 없습니다. 그러나 여전히 GPU와 올바르게 인터페이스 할 수 없으며 저해상도에 처할 수 있습니다.

나는 당신이 모든 것을 스스로 만들고 엔진이나 그와 같은 것을 사용하고 싶지 않다는 것을 이해합니다. 그러나 자신 만의 그래픽 API를 만드는 것은 사용자에게 불편을 줄뿐입니다.

당신은 당신 자신의 드라이버와 API를 작성할 수 있으며, 당신의 능력과 지식 수준을 막을 수있는 것은 없습니다. 좋은 학습 경험이 될 수있는 다른 것이 없다면, 실제 문제는 이전의 그래픽 경험이 많지 않으면 훌륭한 프로그래머라도 당신이해야 할 일을 잃어 버릴 수 있다는 것입니다. 시작합니다.

그러나 당신이 만드는 인터페이스는 끊임없이 뒤에서 업데이트되는 것보다 사용하기 쉽고 안정적입니다. 그래서 더 많은 사람들이이 길을 가지 않는다는 것은 조금 놀라운 일이지만, 현실적으로 기술적 인 통찰력을 가진 사람은 거의 없으며 아무도이 모든 일을하는 방법을 배우기 위해 몇 년 동안 누군가에게 돈을 지불하고 싶어하지 않을 것입니다. 그들은 회사를 떠나서 자작 나무에 남겨 둡니다. 표준화에있어 좋은 점은 직원을 훨씬 더 많이 소비하고 위험을 줄이는 것입니다.