Barrier 란? - 5

더 많은 대역폭 압박

GPU는 시간이 지남에 따라 컴퓨팅에 점점 더 집중하고 있지만 삼각형을 픽셀 격자로 래스터 화하기 위해 여전히 많이 최적화되어 있습니다. 이 작업을 수행하면 ROP의 터치 가진 끝낼 수 있다는 것을 의미한다 t 메모리마다 프레임. 게임은 이제 최대 4k 해상도로 렌더링해야하며, 오버 드로우없이 모든 것을 작성하는 경우 8294400 픽셀로 작동합니다. 16 비트 부동 소수점 텍스처 형식의 경우 픽셀 당 8 바이트를 곱하거나 G 버퍼의 경우 픽셀 당 최대 30 또는 40 바이트를 곱하면 그 모든 것을 제어하기 위해 많은 대역폭을 소비하게됩니다 한 번 메모리 (그리고 일반적으로 많은 텍셀들이 한번 이상 터치 될 것입니다!)! MSAA를 믹스에 추가하면 순진한 경우 메모리 및 대역폭 요구 사항이 두 배 또는 네 배가됩니다.

GPU 디자이너는 대역폭 사용이 병목 현상을 일으키는 것을 막기 위해 하드웨어에 무손실 압축 기술을 구축하는 데 많은 노력을 기울였습니다. 일반적으로이 종류의 것은 ROP의 일부로 구현되므로 대상 및 깊이 버퍼를 렌더링하기 위해 작성할 때 사용됩니다. 지난 몇 년 동안 사용 된 많은 특수 기술이 있었으며 정확한 세부 정보는 대중에게 공개되지 않았습니다. 그러나 AMD 와 엔비디아최신 아키텍처에서 델타 컬러 압축의 특정 구현에 관한 정보를 최소한 제공했습니다. 두 기법의 기본 요점은 렌더링 타겟의 모든 텍셀에 대해 고유 한 값을 저장하는 것을 피하기 위해 인접 픽셀의 유사성을 활용하는 것입니다. 대신 하드웨어는 픽셀 블록의 패턴을 인식하고 각 픽셀의 차이 (또는 델타)를 앵커 값과 비교하여 저장합니다. Nvidia의 블록 모드는 2 : 1에서 8 : 1 압축 비율까지 제공하므로 대역폭을 크게 절약 할 수 있습니다.

그러면 이것이 장벽과 정확히 어떤 관련이 있습니까? 이러한 멋진 압축 모드의 문제점은 ROP가 압축 된 데이터를 처리하는 방법을 이해할 수 있지만 셰이더가 텍스처 단위를 통해 무작위로 데이터에 액세스해야 할 때 반드시 동일하지는 않습니다. 즉, 하드웨어 및 텍스처 사용 방법에 따라 텍스처 내용을 종속 작업에서 읽을 수 없거나 ROP 이외의 방법으로 쓸 수 있기 전에 압축 해제 단계가 필요할 수 있습니다. 다시 한번 말하지만, 이것은 GPU에 대해 이야기 할 때 "장벽"에 속하는 것이며, GPU와 대화하기위한 새로운 명시적인 API입니다.

그러나 D3D는 어떻습니까?

스레드 동기화, 캐시 일관성 및 GPU 압축에 대한 내용을 읽은 후 일반적인 GPU가 우리가 기대하는 정상적인 작업을 수행하는 데 필요한 3 가지 잠재적 인 이유를 최소한 기본적으로 파악할 수 있습니다. 그러나 D3D12 또는 Vulkan 에서 실제 장벽 API를 보면, 당신은 아마 우리가 방금 말한 것과 직접적으로 대응하는 것 같지 않음을 알 수있을 것입니다. 결국, ID3D12GraphicsCommandList에는 "WaitForDispatchedThreadsToFinish"또는 "FlushTextureCaches"함수가있는 것과는 다릅니다. 그리고 당신이 그것에 대해 생각한다면, 그들은 이것을하지 않는 것이 합리적입니다. 대부분의 GPU에는 작업이 겹칠 수있는 많은 쉐이더 코어가 있다는 사실은 매우 구체적인 구현 세부 사항이며 이상한 비 일관적인 캐시 계층을 가진 GPU에 대해서도 마찬가지입니다. D3D12와 같은 명시적인 API의 경우에도 D3D12를 사용하여 방금 설명한 방식으로 동작하지 않는 GPU와 대화하는 것이 가능할 수 있기 때문에 추상화를 통해 그런 종류의 세부 사항이 누설되는 것은 당연합니다. (그것은 벌써 일어 났을지도 모른다!).

이러한 관점에서 생각할 때, D3D12 / 불칸 장벽은 더 높은 수준이며, 대신 한 파이프 라인 단계에서 다른 단계로의 데이터 흐름을 설명하는 것이 대부분 목적입니다. 그 (것)들을 기술하는 다른 방법은 방벽이 운전사에게 시정의 변화에 대해 말한다라고 말하는 것 우리가 이전에 지적한 바와 같이 다양한 작업 및 / 또는 기능 단위에 관한 데이터는 실제로 장벽의 본질입니다. 따라서 D3D12에서는 "이 draw 호출이이 다른 디스패치가 읽기 전에 완료되었는지 확인하지 마십시오."라고 말하면 "이 텍스처는 '렌더 대상'상태에서 '쉐이더 읽기 가능'상태로 전환되므로 쉐이더 프로그램 그것을 읽을 수 있습니다. " 본질적으로 드라이버는 리소스의 과거와 미래에 대해 약간의 정보를 제공합니다. 이는 플러시 할 캐시와 텍스처 압축 풀기 여부를 결정하는 데 필요할 수 있습니다. 스레드 동기화는 드로잉 또는 디스패치 간의 명시적인 종속성이 아닌 상태 전이에 의해 암시되며 완벽한 시스템은 아니지만 작업이 완료됩니다.

왜 우리가 D3D11에서 수동으로 장벽을 일으킬 필요가 없는지 궁금하다면, 그 질문에 대한 대답은 "운전자가 우리를 위해했기 때문에!"입니다. 컴파일러가 코드를 분석하여 종속성을 판별하고 적절한 어셈블리를 자동으로 생성 할 수 있다고 말한 것을 기억하십시오. 이것은 기본적으로 D3D11에서 런타임에 수행하는 것을 제외하고는 어떤 드라이버입니까? 드라이버는 입력 및 출력으로 바인딩하는 모든 리소스를 살펴보고 가시성이 변경 될 때 (예 : 렌더링 대상에서 쉐이더 입력으로 이동) 알아 내고 필요한 동기화 지점, 캐시 플러시 및 압축 풀기를 삽입해야합니다 단계. 자동으로 올바른 결과를 얻는 것이 좋지만 다음과 같은 이유로 나쁘다 :

• 리소스를 자동으로 추적하고 호출을 그리거나 호출하는 작업은 비용이 많이 들며 렌더링 코드를 프레임 당 몇 밀리 초로 압축하려고 할 때 좋지 않습니다.

• 병렬로 명령 버퍼를 생성하는 것은 정말 나쁩니다. 한 스레드에서 렌더 대상으로 텍스처를 설정 한 다음 다른 스레드의 입력으로 바인드 할 수있는 경우 드라이버는 두 스레드의 결과를 직렬화하지 않고 전체 리소스 수명을 계산할 수 없습니다.

• 컨텍스트는 항상 모든 그리기 또는 디스패치에 대한 입력 및 출력의 전체 집합을 알고있는 명시 적 리소스 바인딩 모델을 사용합니다. 이렇게하면 바인드리스 리소스 액세스로 멋진 일을 할 수 없게됩니다.

• 경우에 따라 쉐이더가 데이터에 액세스하는 방법에 대한 지식이 없기 때문에 드라이버가 불필요한 장애물을 낼 수 있습니다. 예를 들어 동일한 원자 카운터를 증분하는 두 개의 디스패치는 동일한 리소스에 액세스하더라도 배제 할 필요가 없습니다.

D3D12와 Vulkan의 사고 방식은 앱이 드라이버에 필요한 가시성을 제공하도록함으로써 이러한 단점을 제거 할 수 있다는 것입니다. 이렇게하면 드라이버가 더 간단하게 유지되고 앱이 원하는 방식으로 장벽을 파악할 수 있습니다. 렌더링 설정이 상당히 고쳐 졌다면 장벽을 하드 코딩하고 기본적으로 CPU 비용을 0으로 줄일 수 있습니다. 또는 자체 종속성 그래프 를 작성하도록 엔진을 설정할 수 있으며이를 사용하여 필요한 장벽을 결정할 수 있습니다 .