그래픽 API를 너무 세밀하게 추상화하고 있는지 어떻게 알 수 있습니까?

23

여러 그래픽 API를 지원하는 렌더러를 만들 때 일반적으로 OpenGL, Vulkan, D3D11 등과 같은 일부 그래픽 API와 연결된 일종의 저수준 라이브러리에서 코드를 추상화하려고합니다.

그것들은 서로 매우 다르게 작동하므로 좋은 일반 API를 만드는 것이 필수적입니다. 필자는 일반적으로 지원하려는 각 API의 기본 기능을 구현하는 "백엔드"와 프로그래머가 데이터를 그리기 위해 사용하는 "프론트 엔드"를 사용하고 싶다고 읽었습니다. 화면.

내가 너무 빡빡한 추상화를 만들고 있는지 어떻게 알 수 있습니까?

graphics-programming

— 가브리엘 비에르 티
소스

5

래퍼 + Vulkan 또는 D3D11이 항상 OpenGL을 사용하는 것보다 빠르다는 것을 100 % 확신하십니까?

— Mooing Duck

@Mooing Duck이 올바르게 사용된다면, 그렇습니다.

— Gabriele Vierti

4

나는 그것을 심각하게 의심 할 것입니다. Vulkan에서 얻는 대부분의 이익은 매우 낮은 수준이며 매우 독특하고 구체적인 방식으로 일을 수행하는 데 있습니다. OpenGL 또는 D3D에서도 완벽하게 동일하게 수행 할 수있는 일반적인 것은 거의 그렇게 할 수 없습니다. OpenGL과 동일한 기능 (다수의 Vulkan 자습서와 마찬가지로)을 다시 구현하면 동일한 성능으로 99.99 %의 결과를 얻을 수 있으며 작업 시간의 20 배가됩니다.

— 데이먼

@Damon은 맞지만 최신 API는 최신 GPU에서 작동 하도록 특별히 설계되었습니다 ( OpenGL과 같이 조정 되지 않음 ). VULKAN의 말하기, 당신은 할 수 있습니다 거의 반대로 당신이 "임베디드 시스템"버전을 사용할 필요가 OpenGL을,에, 지원되는 모든 플랫폼에서 동일한 API를 사용합니다. 적은 CPU 오버 헤드 및 공상 이외에 우리는 많이없는 기능을하지만, 미래에 우리는 Vk을 또는 D3D12보다는 OGL 또는 D3D11 사용하여 빠르게 실행할 수 있습니다 꽤 놀라운 기술이있을 수 있습니다

— 가브리엘 Vierti

44

우선, 둘 이상의 그래픽 API를 지원하는 것이 실제로 가치가 있는지 고려하십시오. OpenGL을 사용하는 것만으로도 대부분의 플랫폼을 포괄 할 수 있으며 그래픽 적으로 야심 찬 프로젝트를 제외한 모든 프로젝트에 "충분히"적합합니다. 여러 렌더링 백엔드를 구현하고 테스트하는 데 수천 시간의 시간을 허비 할 수있는 매우 큰 게임 스튜디오에서 작업하지 않는 한 실제로 보여주고 싶은 DirectX 또는 Vulcan 특정 기능이 없다면 일반적으로 번거롭지 않습니다. . 특히 다른 사람이 만든 추상화 계층 (타사 라이브러리 또는 게임 엔진)을 사용하여 많은 작업을 절약 할 수 있다는 점을 고려하십시오.

그러나 이미 옵션을 평가했으며 자신의 옵션을 선택할 수있는 시간과 가치가 있다고 결론을 내 렸습니다.

그런 다음 추상화 계층의 소프트웨어 아키텍처의 주요 판사는 프론트 엔드 프로그래머입니다.

저수준의 세부 사항에 대해 궁금하지 않고 구현하려는 게임 시스템을 구현할 수 있습니까?
그래픽 API가 두 개 이상 있다는 것을 완전히 무시할 수 있습니까?
이론적으로 프론트 엔드 코드를 변경하지 않고 다른 렌더링 백엔드를 추가 할 수 있습니까?

그렇다면 성공했습니다.

— 필립
소스

2

한 가지 추가 제안 : 목표는 목표를 명중하고 더 이상 가지 않기 위해 최소한의 노력으로 총알 점에서 목표를 달성하는 것임을 강조 할 가치가 있습니까? 그렇지 않으면 이것들 각각은 종종 혼자서 떠나야 할 때를 종종 모르는 전형적인 개발자를 위해 토끼 구멍으로 바뀔 수 있습니다. :) 또한 성공을 판단하는 신뢰할 수있는 유일한 방법은 실제 사용자 와 API를 반복적으로 개발하고 테스트하는 것입니다. 정확하게 추측하는 것은 불가능하며 오버 엔지니어링의 토끼 구멍 시나리오로 이어집니다.

— bob

5

당신이 정말로 않는 경우 내가 그것을 추가 할 수 있는 여러 그래픽 라이브러리를 지원하기 때문에 그렇다하더라도 당신은 거의 확실 기성 당신이 필요한 모든 작업을 수행 한 거기에 정말 자신의 롤 안된다. (물론 예외가 있지만, "추상화를 얼마나 엄격하게해야하는지"를 물을 수있는 경험이 없다면 아마도 그것을 요구하는 프로젝트를 진행하고 있지는 않을 것입니다)

— Fund Monica 's Lawsuit

나는 그래픽 개발자는 아니지만 데이터베이스와 OS의 역사에서 호환성 프레임 워크를 살펴보면 자신의 일반적인 프레임 워크 를 만드는 것이 거의 가치가 없다고 덧붙 입니다. 프레임 워크는 거의 확실하게 호환성을 위해 성능을 희생해야 할 것입니다. 어쨌든 이러한 특수 기능으로 많은 것을 할 수 없을 것입니다. 기존 프레임 워크는 사용량이 많기 때문에 이러한 문제를 더 잘 처리 할 수 있습니다. 이제 예산이 엄청나고 특정 프레임 워크 (예 : 한 게임 또는 시리즈)를 작성 하고 싶은 경우에는 더 많은 이점이 있습니다.

— jpmc26

6

API의 "래퍼"부분에서 실제로 필요한 것을 식별하여 시작하십시오. 일반적으로 매우 간단합니다. 기본 리소스 (버퍼, 셰이더, 텍스처, 파이프 라인 상태)와 이러한 리소스를 사용하여 그리기 호출을 제출하여 프레임을 구성하는 방법이 필요합니다.

어떤 높은 수준의 논리를 유지하려고 에서 의 API 래퍼 부분. API 의이 부분에서 영리한 장면 컬링 기술을 구현하면 모든 백엔드 구현에서 해당 논리를 복제 할 수 있습니다. 많은 노력이 필요하므로 간단하게 유지하십시오. 장면 관리는 랩퍼 자체의 일부가 아닌 랩퍼 를 사용 하는 API의 상위 레벨 부분의 일부 여야 합니다.

지원할 대상을 선택하고 이해하십시오. "모든 것"에 대해 적절한 래퍼를 작성하는 것은 어렵고 필연적으로 필요하지 않을 수도 있습니다 ( 필립스의 답변에서 언급 한 것처럼 단일 래퍼를 작성할 필요 도 없습니다 ). 랩핑 할 API를 모르면 괜찮은 래퍼를 작성하는 것은 거의 불가능합니다.

API 상태를 정기적으로 평가하십시오. 일반적으로 래핑 된 API보다 표면적이 더 작아야합니다. 모든 D3D 구조 또는 모든 OpenGL 함수 호출에 대해 일대일 랩퍼 유형을 작성하는 경우 당연히 도움이 될 것입니다.

무슨 일이 있었는지보세요. Sokol 및 BGFX는 사용자에게 유용하고 이해하기 쉬운 (특히 전자) 수준의 불가지론을 제공하는 API입니다.

— 조롱
소스

3

아직 언급하지 않은 또 다른 요점은 성능 목표입니다. 저렴한 하드웨어 플랫폼에서 우수한 성능을 제공하지만 훨씬 더 강력하지만 다른 API를 사용하는 다양한 플랫폼에서도 사용할 수있는 그래픽 라이브러리를 목표로하는 경우 API를 설계하는 것이 합리적 일 수 있습니다 성능이 문제가되는 플랫폼에서 기본적으로 사용되는 추상화 이것이 더 강력한 플랫폼에서 50 %의 속도 저하를 야기하더라도 성능이 가장 중요한 플랫폼에서 20 %의 속도 향상을 가능하게하는 것이 좋습니다.

— 슈퍼 캣
소스