OpenGL의 직접 상태 액세스 메커니즘의 장점은 무엇입니까?

opengl.org 에서 OpenGL 4.5 DSA (Direct State Access)에 대해 읽었 으며 제대로 받고 있는지 확실하지 않습니다.

옛날 방식이 덜 효율적이라는 것을 암시하는 것처럼 보입니다.

glBind(something)
glSetA(..)
glSetB(..)
glSetC(..)

새로운 방식보다

glSetA(something, ..)
glSetB(something, ..)
glSetC(something, ..)

외관상으로는 각각 내부에 glSet포함되어야 glBind(something)하며 OpenGL이 여전히 상태 머신 인 경우 단일에 적용된 스트리밍 변경 사항을 활용할 수 없습니다 something.

새로운 DSA의 이유와 장점을 설명하십시오.

외관상으로 각 glSet에는 그 안에 glBind (something)가 포함되어야합니다

정확히. 아래의 여러 단락에 설명 된 것처럼 다른 방법입니다.

사실이더라도 클라이언트 앱에서 GL 서버 (일명 드라이버) 로의 GL 명령은 일반 함수 호출에 비해 디스패치 오버 헤드가 많다는 것을 기억하십시오. DSA 함수가 기존 함수를 감싸는 래퍼라고 가정하더라도 GL 서버 내부에있는 래퍼이므로 오버 헤드가 적습니다.

OpenGL이 여전히 상태 머신 인 경우 단일 항목에 적용된 스트림 변경 사항을 활용할 수 없습니다.

GPU는 상태 머신이 아닙니다. GL 상태 머신 인터페이스는 DSA와 같은 드라이버 내부를 감싸는 에뮬레이션입니다.

GL 서버에 대한 호출 수가 과도하게 필요한 계층 인 랩핑 계층을 제거하는 것이 작은 경우에도 분명히 승리합니다.

상태 머신 접근 방식은 여러 스레드를 처리 할 때 많은 의미가 없습니다. GL 은이 유스 케이스에서 여전히 끔찍하지만 드라이버는 종종 배후의 스레드를 사용하며 상태 머신은 작업을 안정적으로 수행하기 위해 많은 스레드 동기화 또는 실제로 멋진 병렬 알고리즘 / 구조가 필요합니다.

DSA 확장은 완전히 새로운 API가 아닌 기존의 상태 기반 문서에 대한 확장이기 때문에 상태 변경 측면에서 계속해서 작동하므로 기존 GL 사양에 플러그인 할 수 있어야했습니다. 문서의 언어 및 용어. 기존 언어가 최신 그래픽 하드웨어 API로서의 작업에 매우 적합하더라도.

새로운 DSA의 이유와 장점을 설명하십시오.

가장 큰 추론은 옛날 방식이 고통 이었다는 것입니다. GL 상태를 각각 수정하거나 의존 할 수있는 라이브러리를 함께 구성하는 것은 매우 어려웠습니다. 절차 적 상태 관리 루트가 깊기 때문에 GL API를 객체 지향 또는 기능적 스타일로 효율적으로 감싸기가 어려워졌으며, API를 다양한 비 C 언어로 래핑하는 것이 어려웠으며 효율적인 그래픽 장치 래퍼를 제공하기가 어려웠습니다. Direct3D의 추상 OpenGL.

두 번째는 앞에서 설명한 절차 적 상태 머신 API 오버 헤드였습니다.

셋째, DSA 기능은 효율성을 향상시킬 수있는 기존 API에서 적절한 의미를 변경했습니다. 예를 들어, 이전에 변경 가능한 것은 불변으로 만들어졌으며, 이는 GL 서버에서 많은 장부 코드를 제거합니다. GL 서버가 변경 가능한 객체를 처리 할 필요가없는 경우 응용 프로그램의 호출을 하드웨어로 디스패치하거나 더 빨리 (또는 더 병렬 방식으로) 확인할 수 있습니다.

-

추가 정당화 및 설명은 EXT_direct_state_access 확장 스펙에 제공 됩니다.

-

API 디자인과 관련된 하드웨어 변경은 상당히 많습니다.

OpenGL은 1991 년으로 거슬러 올라갑니다. 대상 하드웨어는 소비자 급 그래픽 카드 (존재하지 않았 음)가 아니라 큰 CAD 워크 스테이션 등이었습니다. 그 시대의 하드웨어는 오늘날과는 매우 다른 성능 한계를 가지고있었습니다. 멀티 스레딩은 더 드물었 고, 메모리 버스와 CPU는 속도 차이가 적었고 GPU는 고정 기능 삼각형 렌더링 이상의 기능을 수행했습니다.

점점 더 많은 고정 기능 기능이 추가되었습니다. 다양한 조명 모델, 텍스처 모드 등이 모두 추가되었으며 각각 고유 한 상태가 필요합니다. 간단한 상태 기반 접근 방식은 소수의 상태 일 때 효과적이었습니다. 점점 더 많은 상태가 추가됨에 따라 API가 이음새에서 터지기 시작했습니다. API는 더 어색해졌지만 실제로 많은 상태 스위치를 기반으로했기 때문에 하드웨어 모드와 크게 다르지 않았습니다.

그런 다음 프로그래밍 가능한 하드웨어가 함께 제공되었습니다. 하드웨어는 점점 더 프로그래밍이 가능해졌으며, 현재 하드웨어는 약간의 상태, 일부 사용자 제공 프로그램 및 많은 버퍼를 지원합니다. 그 시대의 모든 고정 기능 기능이 운전자에 의해 에뮬레이션 된 것처럼 이전 시대의 모든 상태를 에뮬레이션해야했습니다.

하드웨어도 점점 더 병렬로 바뀌 었습니다. 이를 위해서는 그래픽 상태 변경을 매우 비싸게하는 다른 하드웨어 재 설계가 필요했습니다. 하드웨어는 불변 상태의 큰 블록에서 작동합니다. 이러한 변경으로 인해 드라이버는 사용자가 즉시 설정 한 상태의 각 작은 비트를 간단히 적용 할 수 없었지만 변경 사항을 자동으로 일괄 처리하고 필요할 때 암시 적으로 적용해야했습니다.

최신 하드웨어는 기존 OpenGL 모델에서 더 멀리 작동합니다. DSA는 D3D10과 비슷한 10 년 전 (OpenGL 3.0의 일부로 약속 된) 작은 변경 사항입니다. 위의 많은 하드웨어 변경은 OpenGL의 관련성을 유지하기 위해 DSA보다 훨씬 더 많은 것이 필요 하므로 OpenGL 모델을 크게 변경하는 더 큰 확장 기능을 사용할 수 있습니다 . 그런 다음 완전히 새로 워진 GLnext API와 D3D12, Mantle, Metal 등이 단일 상태가 아니므로 오래된 상태 머신 추상화를 유지합니다.

개요는 다음을 통해이를 정당화합니다.

이 확장의 목적은 라이브러리가 선택기 및 래치 된 상태를 방해하지 않도록 라이브러리를보다 효율적으로 만드는 것입니다. 또한이 확장 기능은 선택기 업데이트 명령이 필요 없으므로보다 효율적인 명령 사용이 가능합니다.

여기에서 "보다 효율적"이라고 생각하는 것은 도서관 저자에게 적은 부기 오버 헤드와 결과적으로 더 높은 성능을 의미한다고 생각합니다. 현재 API를 사용하여 "잘 동작"하려면 상태를 쿼리하고 숨기고 상태를 변경하여 필요한 작업을 수행 한 다음 원래 상태를 복원해야합니다.

처럼

oldState = glGet()
glBind()
glDoThings...
glSet(oldState)  // restore, in case anyone needs it just as they left it

아마도 오래된 하드웨어는 명시적인 상태 변경 API를 사용하여 성능을 향상시킬 수 있습니다. 그렇지 않으면 꽤 이상한 의식입니다. 이 확장은 가져 오기, 설정, 복원 댄스를 피하는 것이 각 호출에서 추가 매개 변수를 사용하더라도 현재 하드웨어에서 더 많은 성능의 승리를 의미 함을 의미합니다 (저작권 목록 만 살펴보십시오!).