Direct3D 11 바인딩 모델과의 차이점
DirectX12 바인딩에 사용된 기본 설계 결정 중 하나는 다른 관리 작업과 분리하는 것입니다. 이 결정에 따라 특정 잠재적인 위험을 관리하기 위한 요구 사항이 앱에 적용됩니다.
D3D12 바인딩 모델의 주요 장점은 막대한 CPU 성능 비용 없이 앱이 질감 바인딩을 자주 변경할 수 있다는 점입니다. 다른 이점은 셰이더가 매우 많은 리소스에 액세스할 수 있고, 셰이더가 바인딩될 리소스 수를 미리 알 필요가 없고, 하드웨어 또는 앱 콘텐츠 흐름과 관계없이 통합된 리소스 바인딩 모델을 사용할 수 있다는 점입니다.
성능을 개선하기 위해 바인딩 모델의 경우 앱이 GPU에서 사용하도록 요청한 바인딩을 시스템이 추적할 필요가 없으며, 바인딩 및 다중 스레드 명령 목록이 완전히 통합됩니다.
다음 섹션에는 D3D11 이후 리소스 바인딩 모델의 일부 변경 내용이 나와 있습니다.
바인딩에서 분리된 메모리 상주 관리
애플리케이션은 GPU에서 직접 사용(“상주”된다고 함)하도록 제공해야 하는 표면을 명시적으로 제어합니다. 반대로, 리소스가 상주하지 않도록 명시적으로 설정하거나 OS에서 최소 메모리 공간이 필요한 특정 클래스의 애플리케이션에 대해 선택하도록 하는 것과 같이 리소스에서 다른 상태를 적용할 수 있습니다. 여기서 중요한 사항은 상주 항목에 대한 애플리케이션의 관리가 리소스에 대한 액세스 권한을 셰이더에 제공하는 방법에서 완전히 분리된다는 점입니다.
리소스에 대한 액세스 권한을 셰이더에 제공하기 위해 메커니즘에서 상주 관리를 분리하면 OS에서는 상주되도록 설정된 항목을 알기 위해 로컬 바인딩 상태를 지속적으로 검사할 필요가 없으므로 렌더링을 위한 시스템/하드웨어 비용이 감소합니다. 또한 액세스할 수 있는 리소스의 전체 세트가 미리 상주되도록 설정된 경우가 아니면 셰이더는 참조해야 할 수 있는 정확한 표면을 더 이상 알 필요가 없습니다.
바인딩에서 분리된 개체 수명 관리
이전 API와 달리 시스템은 더 이상 파이프라인에 대한 리소스의 바인딩을 추적하지 않습니다. 이 기능을 사용하면 처리 중인 GPU 작업이 리소스를 계속 참조하기 때문에 애플리케이션이 릴리스한 활성 리소스를 시스템에서 유지할 수 있습니다.
질감과 같은 리소스를 해제하기 전에 애플리케이션은 GPU에서 리소스 참조를 완료했는지 확인해야 합니다. 이는 애플리케이션이 리소스를 안전하게 해제하려면 먼저 GPU가 리소스를 참조하는 명령 목록 실행을 완료했어야 함을 의미합니다.
바인딩에서 분리된 드라이버 리소스 상태 추적
시스템에서 추가 드라이버 또는 GPU 작업이 필요한 리소스 전환이 발생한 시점을 알기 위해 더 이상 리소스를 검사할 필요가 없습니다. 많은 GPU 및 드라이버에 대한 일반적인 예제에서는 RTV(렌더링 대상 뷰)로 사용되는 표면이 SRV(셰이더 리소스 뷰)로 전환되는 시점을 알 필요가 없습니다. 이제 애플리케이션 자체에서는 전용 API를 통해 시스템에서 고려하는 리소스 전환이 발생하는 시점을 파악해야 합니다.
바인딩에서 분리된 CPU/GPU 매핑된 메모리 동기화
시스템에서 더 이상 CPU 액세스를 위해 매핑되었으나 아직 매핑 해제되지 않은 리소스를 사용하기 때문에 렌더링이 지연되어야 하는지 알기 위해 리소스 바인딩을 검사하지 않습니다. 이제 애플리케이션에서 CPU 및 GPU 메모리 액세스를 동기화해야 합니다. 이 작업을 지원하기 위해 시스템에서는 애플리케이션이 작업이 완료될 때까지 CPU 스레드의 절전 상태를 요청하는 메커니즘을 제공합니다. 폴링을 수행할 수도 있지만 덜 효율적일 수 있습니다.
관련 항목