타일 리소스
타일 리소스의 경우 디바이스 페이징 큐에서 실행되는 비동기 비디오 메모리 관리자 서비스로는 충분하지 않습니다. 특히 타일 리소스의 경우 렌더링과 함께 페이지 테이블 업데이트를 큐에 대기시키고 그리기 작업 간에 업데이트가 동기적으로 적용되도록 합니다.
예를 들어 애플리케이션에서 다음 API 호출 시퀀스를 지정합니다.
- 그리기 #42
- 타일 매핑 업데이트
- 그리기 #43
그리기 #42는 이전 상태의 페이지 테이블과 함께 실행되는 반면 그리기 #43은 새 상태의 페이지 테이블과 함께 실행되도록 합니다. 덮어쓰지 않음 플래그를 지정하는 업데이트 타일 매핑 작업의 경우 이 동기화를 약간 완화할 수 있지만 고성능 동기 업데이트를 지원해야 합니다. 고성능 지연 업데이트를 지원하려면 페이징 작업을 미리 생성하고 컨텍스트에 큐에 대기하고 종속 렌더링 컨텍스트가 특정 지점에 도달하면 실행될 때까지 기다리는 기능이 필요합니다(예: 위의 그리기 #42 이후).
즉, 페이징 작업은 특정 렌더링 컨텍스트에서 신호를 받을 GPU(그래픽 처리 장치) 대기 뒤에 대기해야 합니다. 따라서 하나의 애플리케이션이 시스템의 다른 모든 사용자에 대한 페이징 작업의 실행을 차단할 수 있음을 의미하므로 공유 시스템 컨텍스트에 직접 큐에 대기할 수 없습니다.
이론적으로 오늘날의 패킷 기반 일정에서 디바이스 페이징 큐에서 작업의 대기 부분을 구현하고, 대기를 모니터링하고, 대기 조건이 충족된 후 페이징 작업을 공유 시스템 컨텍스트에 제출할 수 있습니다. 그러나 패킷 기반 일정 예약을 넘어 하드웨어 예약으로 이동하면서 GPU를 사용하여 연동 작업에 GPU 동기화 기본 형식을 사용하여 최상의 성능을 보장하려고 합니다.
이 문제를 해결하기 위해 컨텍스트별 페이징 도우미 컨텍스트의 개념을 소개합니다. 페이징 도우미 컨텍스트는 UpdateGpuVirtualAddress 에 대한 첫 번째 호출에서 지연적으로 생성되며, 상호 잠긴 동기화가 필요한 모든 페이지 테이블 업데이트에 사용됩니다. UpdateGpuVirtualAddress 는 GPU 모니터링 펜스 개체 및 특정 펜스 값을 매개 변수로 사용합니다. 이 모니터링된 펜스에서 도우미 컨텍스트가 페이지 테이블 업데이트를 기다린 다음 모니터링된 펜스 개체를 증가시키고 신호를 전송합니다. 이렇게 하면 렌더링 컨텍스트가 도우미 컨텍스트와 긴밀하게 동기화됩니다.
도우미 컨텍스트를 사용한 페이지 테이블 업데이트는 다음과 같습니다.
DXGKARG_CREATECONTEXT(컨텍스트를 만드는 동안 커널 모드 드라이버가 선택한 엔진에 대해 비디오 메모리 관리자가 도우미 컨텍스트를 지연적으로 만듭니다. PagingCompanionNodeId).
도우미 컨텍스트는 프로세스별 권한 있는 주소 공간에서 실행됩니다. 주소 공간은 커널에 의해 제어되고 커널에서 생성된 DMA(직접 메모리 액세스) 버퍼만 내에서 실행할 수 있기 때문에 권한이 있습니다. 이 외에는 일반 GPU 가상 주소 공간이며 특별한 하드웨어 가상 주소 공간 권한이 필요하지 않습니다.
간단히 하기 위해 시스템 페이징 프로세스 GPU 가상 주소 공간을 다시 사용하는 대신 프로세스별 권한 있는 GPU 가상 주소 공간을 선택했습니다. 타일 리소스의 매핑 및 매핑 해제가 일반적이므로 자주 매핑/매핑을 해제하지 않으려면 애플리케이션 페이지 테이블을 주소 공간에 영구적으로 매핑해야 합니다. 또한 곧 자세히 설명하겠습니다. 모든 타일 풀을 영구적으로 매핑해야 합니다. 시스템 주소 공간에서 이러한 영구 매핑을 수행하면 불필요한 추가 복잡성이 발생합니다.
프로세스당 권한 있는 GPU 가상 주소 공간이 초기화되어 프로세스 GPU 페이지 테이블이 주소 공간을 통해 표시되므로 업데이트 명령이 GPU를 사용하여 다양한 페이지 테이블 항목을 업데이트할 수 있습니다. 또한 프로세스에서 만든 모든 타일 풀도 주소 공간에 매핑됩니다.
페이지 테이블 항목이 도우미 컨텍스트에 의해 업데이트되는 방식은 약간 특별하며 몇 가지 설명이 필요합니다. 공유 시스템 컨텍스트에서 실행을 위해 맵 작업이 대기 중인 경우 비디오 메모리 관리자는 매핑되는 실제 주소를 알고 있으며 이러한 실제 주소는 연결된 페이징 버퍼에 직접 표시될 수 있습니다. 이 경우 UpdatePageTable 페이징 작업이 사용되며 비디오 메모리 관리자는 일부 특정 페이지의 페이징 작업이 완료된 후에 해당 페이지를 다른 용도로 다시 사용할 수 있습니다.
그러나 도우미 컨텍스트에서 페이지 테이블의 동기 업데이트의 경우 상황이 더 어렵습니다. 비디오 메모리 관리자는 업데이트 작업이 빌드될 때 참조되는 타일 풀의 실제 페이지를 알고 있지만, 이러한 작업이 임의로 긴 GPU 대기 뒤에 큐에 대기하는 경우(앱이 교착 상태일 수도 있고 신호를 보내지 않을 수도 있음), 비디오 메모리 관리자는 페이징 작업이 실제로 실행될 때 타일 풀의 실제 페이지가 무엇인지 알지 못하며 비디오 메모리 관리자는 유지할 수 없습니다. 임의의 오랜 시간 동안 해당 위치에 있는 타일 풀입니다.
이 문제를 해결하려면 기본적으로 페이징 작업을 큐에 대기하고 물리적 주소가 변경될 때 나중에 패치하거나 업데이트에 사용된 실제 주소를 늦게 바인딩해야 합니다. 비디오 메모리 관리자는 후자를 수행합니다.
이 문제를 해결하기 위해 비디오 메모리 관리자는 두 가지 작업을 수행합니다. 먼저 GPU 가상 주소를 프로세스 권한 있는 주소 공간 내의 프로세스에 속하는 모든 타일 풀 요소에 매핑합니다. 타일 풀이 메모리에서 이동함에 따라 비디오 메모리 관리자는 다른 할당 유형에 대해 수행하는 것과 동일한 간단한 메커니즘을 사용하여 타일 풀의 올바른 위치를 가리키는 GPU 가상 주소를 자동으로 유지합니다.
타일 리소스 페이지 테이블 항목을 업데이트하기 위해 비디오 메모리 관리자는 타일 풀 가상 주소에서 타일 리소스 가상 주소로 페이지 테이블 항목을 복사하는 새 CopyPageTableEntry 페이징 작업을 도입합니다. 비디오 메모리 관리자는 타일 풀이 메모리에서 이동할 때 타일 풀 가상 주소를 최신 상태로 유지하므로 명령이 생성된 시간과 실제로 실행되는 명령 사이에 경과된 시간에 관계없이 타일 풀에 대해 현재 유효한 실제 위치로 복사 작업이 실행되도록 보장됩니다.
특정 타일 풀을 참조하는 큐에 대기 중인 페이지 테이블 업데이트가 있는 한, 비디오 메모리 관리자는 업데이트 작업을 실행할 때 타일 풀 가상 주소가 유효하도록 보장하기 위해 사용자 모드 드라이버 또는 애플리케이션에 관계없이 애플리케이션에 대한 상주 요구 사항에 해당 타일 풀을 유지합니다.
이 메커니즘은 다음과 같습니다.
**
CPU_VIRTUAL 페이지 테이블 업데이트 모드를 사용하여 GPU의 GPU 가상 주소 업데이트
DXGK_PAGETABLEUPDATE_CPU_VIRTUAL 페이지 테이블 업데이트 모드를 지원하는 GPU에서는 CopyPageTableEntries 작업이 사용되지 않습니다. 이러한 GPU는 페이징 버퍼를 사용하지 않는 통합 GPU입니다. 비디오 메모리 관리자는 적절한 시간까지 업데이트 작업을 연기하고 UpdatePageTable 작업을 사용하여 페이지 테이블을 설치합니다.
이 메서드의 단점은 UpdatePageTable 작업이 렌더링 작업과 병렬이 아니라는 것입니다. 이점은 드라이버가 페이징 버퍼에 대한 지원을 구현하고 즉시 작업으로 UpdatePageTable 을 구현할 필요가 없다는 것입니다.