참고 Windows 10, 버전 1703(Creators’ Update)에서 도입된 이 구조체는 D3D12_FEATURE_DATA_ARCHITECTURE 구조체를 대체합니다. 애플리케이션이 Windows 10, 버전 1703(Creators’ Update) 이상을 대상으로 하는 경우 D3D12_FEATURE_DATA_ARCHITECTURE1(및 D3D12_FEATURE_ARCHITECTURE1)을 사용하세요.
구문
멤버
NodeIndex형식: UINT 다중 어댑터 작업에서, 이는 장치의 어느 물리적 어댑터가 관련되어 있는지를 나타냅니다. 다중 어댑터 시스템을 참조하세요. 애플리케이션이 각 어댑터의 아키텍처에 대한 세부 정보를 검색할 수 있으므로, NodeIndex는 CheckFeatureSupport를 호출하기 전에 애플리케이션이 채웁니다. TileBasedRenderer
형식: BOOL 하드웨어와 드라이버가 타일 기반 렌더러를 지원하는지 여부를 지정합니다. 하드웨어와 드라이버가 타일 기반 렌더러를 지원하면 런타임이 이 멤버를 TRUE로 설정합니다. UMA
형식: BOOL 하드웨어와 드라이버가 UMA를 지원하는지 여부를 지정합니다. 하드웨어와 드라이버가 UMA를 지원하면 런타임이 이 멤버를 TRUE로 설정합니다. CacheCoherentUMA
형식: BOOL 하드웨어와 드라이버가 캐시 일관성(cache-coherent) UMA를 지원하는지 여부를 지정합니다. 하드웨어와 드라이버가 캐시 일관성 UMA를 지원하면 런타임이 이 멤버를 TRUE로 설정합니다. IsolatedMMU
형식: BOOL SAL:
Out
하드웨어와 드라이버가 격리된 메모리 관리 장치(MMU)를 지원하는지 여부를 지정합니다.
GPU가 MEM_WRITE_WATCH(VirtualAlloc 참조) 및 PAGE_READONLY(Memory Protection Constants 참조)와 같은 CPU 페이지 테이블 속성을 존중하면 런타임이 이 멤버를 TRUE로 설정합니다.
TRUE인 경우, GPU가 이러한 페이지 테이블 속성을 예기치 못한 방식으로 트리거할 수 있으므로 애플리케이션은 이러한 페이지 테이블 속성을 가진 메모리를 GPU와 함께 사용하지 않도록 주의해야 합니다. 예를 들어, GPU 쓰기 작업은 애플리케이션이 예상하는 것보다 더 거칠 수 있으며, 특히 셰이더 내부의 쓰기가 그렇습니다. 특정 쓰기 감시(write-watch) 페이지는 GPU 쓰기가 어떻게 영향을 미쳤는지 명확하지 않을 때에도 더러워진 것처럼 보일 수 있습니다. 업로드 및 리드백 힙 사용 시나리오와 관련된 GPU 작업은 쓰기 감시 페이지와 잘 작동하지만, 안전하게 무시할 수 있는 오탐(false positive)을 가끔 생성할 수 있습니다.
설명
UMA 및 CacheCoherentUMA 사용 방법
D3D12 앱은 메모리 상주(residency) 관리와 최적의 힙 속성 제공에 신경 써야 합니다. D3D12 앱은 D3D12_HEAP_TYPE_DEFAULT 힙의 리소스에 대한 상주만 관리함으로써 단순하게 유지하면서도 많은 GPU 아키텍처에서 합리적으로 잘 실행될 수 있습니다. 그런 앱은 DXGI_MEMORY_SEGMENT_GROUP_LOCAL에 대해 IDXGIAdapter3::QueryVideoMemoryInfo만 호출하면 되며, D3D12_HEAP_TYPE_UPLOAD와 D3D12_HEAP_TYPE_READBACK이 동일한 메모리 세그먼트 그룹에서 온다는 점을 감안해야 합니다. 그러나 이러한 단순한 설계는 한계를 밀어붙이는 애플리케이션에는 지나치게 제한적입니다. 따라서 D3D12_FEATURE_DATA_ARCHITECTURE는 애플리케이션이 기반 어댑터 속성에 맞게 더 잘 최적화하도록 돕습니다. 일부 애플리케이션은 개별(discrete) 어댑터에 대해 더 잘 최적화하고 시스템 메모리와 비디오 메모리 예산을 모두 관리하는 추가적인 복잡성을 감수할 수 있습니다. 업로드 힙의 크기가 기본 텍스처의 크기와 비슷하다면 메모리 사용량이 거의 두 배가 될 수 있습니다. 이러한 최적화를 지원할 때, 애플리케이션은 두 개의 상주 예산을 감지하거나 UMA가 false임을 인식할 수 있습니다. 일부 애플리케이션은 통합/UMA 어댑터에 대해 더 잘 최적화하기를 원할 수 있으며, 특히 모바일 장치에서 배터리 수명을 연장하는 데 관심이 있는 애플리케이션은 더욱 그렇습니다. 단순한 D3D12 애플리케이션은 UMA에서 항상 필요하지 않을 때도 서로 다른 속성의 힙 간에 데이터를 복사하도록 강제됩니다. 그러나 UMA 속성 자체는 GPU 설계의 상당히 모호한 회색 영역을 포함합니다. UMA가 모든 GPU 액세스 가능 메모리를 자유롭게 CPU 액세스 가능하게 만들 수 있다는 의미로 가정하지 마세요. 그렇지 않기 때문입니다. 이러한 사고 방식에 더 가깝게 부합하는 속성이 있습니다: CacheCoherentUMA. CacheCoherentUMA가 false인 경우, 단일 상주 예산을 사용할 수 있지만 UMA 설계는 일반적으로 세 가지 힙 속성으로부터 이점을 얻습니다. 메모리에 대한 CPU 액세스를 제공하는 업로드 및 리드백 리소스와 힙의 현명한 사용을 통해 리소스 복사를 제거할 기회는 존재합니다. 그러나 이러한 기회는 명확하지 않습니다. 따라서 애플리케이션은 신중해야 하며, 다양한 “UMA” 시스템에서의 실험이 권장됩니다. 특정 장치 ID를 활성화하거나 배제하는 것도 정당화될 수 있습니다. GPU 메모리 아키텍처와 힙 형식이 어떻게 캐시 속성으로 변환되는지에 대한 이해가 권장됩니다. 성공 가능성은 각 프로세서가 데이터를 읽거나 쓰는 빈도, 데이터 액세스의 크기와 지역성 등에 따라 다를 수 있습니다. 고급 개발자를 위한 참고: UMA가 true이고 CacheCoherentUMA가 false인 경우, 이러한 어댑터의 가장 독특한 특성은 업로드 힙이 여전히 쓰기 결합(write-combined)이라는 것입니다. 그러나 일부 UMA 어댑터는 기본 및 업로드 힙의 CPU 액세스 없음 및 쓰기 결합 속성 모두에서 이점을 얻습니다. 자세한 내용은 GetCustomHeapProperties를 참조하세요. CacheCoherentUMA가 true인 경우, 애플리케이션은 힙의 속성을 포기하고 어디에서나 업로드 힙에 해당하는 사용자 지정 힙을 사용하는 것을 더 강하게 고려할 수 있습니다. WriteToSubresource에서 제공하는 것과 같은 Zero-copy UMA 최적화는 더 많은 시나리오가 공유 사용의 혜택을 받게 될 것이므로 더 일반적으로 권장됩니다. 메모리 모델은 더 많은 시나리오와 더 넓은 채택에 매우 유리합니다. 이점을 쉽게 얻을 수 없는 일부 극단적인 경우가 여전히 존재할 수 있지만, 다른 옵션보다 훨씬 드물고 덜 유해합니다. 고급 개발자를 위한 참고: CacheCoherentUMA는 메모리 계층 구조에서 상당한 양의 캐시가 CPU와 GPU 간에도 통합되거나 통합되어 있음을 의미합니다. 가장 독특하게 관찰 가능한 특성은 업로드 힙이 CacheCoherentUMA에서 실제로 라이트백(write-back)이라는 것입니다. 이러한 아키텍처의 경우, 업로드 힙에서 쓰기 결합의 사용은 일반적으로 손해입니다. 저수준 세부 정보는 대부분의 단일 어댑터 애플리케이션에서 무시되어야 합니다. 평소와 마찬가지로, 단일 어댑터 애플리케이션은 상황을 단순화하고 업로드 힙에 대한 CPU 쓰기가 쓰기 결합 친화적인 패턴을 사용하도록 할 수 있습니다. 저수준 세부 정보는 다중 어댑터 애플리케이션의 개념을 강화하는 데 도움이 됩니다. 다중 어댑터 애플리케이션은 어댑터 간에 데이터를 효율적으로 이동하기 위한 최적의 사용자 지정 힙 속성을 선택할 수 있을 만큼 어댑터 아키텍처 속성을 잘 이해해야 할 가능성이 큽니다.요구 사항
헤더: d3d12_xs.h 또는 d3d12_x.h라이브러리: d3d12_xs.lib 또는 d3d12_x.lib
지원 플랫폼: XBOX Series 콘솔 및 XBOX One 제품군