KR20160148594A - 그래픽스 프로세싱에 있어서 렌더 타깃에 기초한 플렉스 렌더링 - Google Patents

Abstract

그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스는 메모리 및 적어도 하나의 프로세서를 포함한다. 적어도 하나의 프로세서는 GPU 가 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 수신하고, 수신된 커맨드 패킷에서의 정보 또는 GPU 의 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하고, 그리고 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하도록 구성될 수도 있다.

Description

그래픽스 프로세싱에 있어서 렌더 타깃에 기초한 플렉스 렌더링{FLEX RENDERING BASED ON A RENDER TARGET IN GRAPHICS PROCESSING}

본 출원은 2014년 4월 21일자로 출원된 미국 가출원 제61/982,147호를 우선권 주장하고, 그 전체 내용들은 본 명세서에 참조로 통합된다.

본 개시는 그래픽스 프로세싱을 위한 기법들에 관한 것이다.

그래픽 사용자 인터페이스들 및 비디오 게임들을 위한 콘텐츠와 같은 디스플레이용 시각적 콘텐츠는 그래픽스 프로세싱 유닛 (GPU) 에 의해 생성될 수도 있다. GPU 는 2차원 또는 3차원 (3D) 오브젝트들을, 디스플레이될 수도 있는 2차원 (2D) 픽셀 표현으로 변환할 수도 있다. 3D 오브젝트들에 관한 정보를 디스플레이될 수 있는 비트 맵으로 변환하는 것은 픽셀 렌더링으로서 공지되며, 상당한 메모리 및 프로세싱 전력을 요구한다. 과거, 3D 그래픽스 능력은 오직 강력한 워크스테이션들 상에서만 이용가능하였다. 하지만, 이제, 3D 그래픽스 가속기는 개인용 컴퓨터들 (PC) 에서 뿐 아니라 스마트폰들, 태블릿 컴퓨터들, 휴대용 미디어 플레이어들, 휴대용 비디오 게이밍 콘솔들 등과 같은 임베디드 디바이스들에서 일반적으로 발견된다. 통상적으로, 임베디드 디바이스는 종래의 PC들에 비하여 더 적은 계산상 전력 및 메모리 용량을 갖는다. 그에 따라, 3D 그래픽스 렌더링 기법들에서의 증가된 복잡도는 그러한 기법들을 임베디드 시스템 상에서 구현할 경우에 어려움들을 제시한다.

일반적으로, 본 개시는, GPU 로 하여금 그래픽스 프로세싱에 있어서 직접 렌더링과 비닝 (binning) 사이에서 스위칭할 수 있게 하는 기법들, GPU 로 하여금 렌더링 모드를 결정할 수 있게 하기 위한 기법들, 및 GPU 와의 렌더링 루프를 실행하는 것을 수행하기 위한 기법들을 설명한다.

본 개시의 일 예에 있어서, 그래픽스 프로세싱의 방법은 그래픽스 프로세싱 유닛 (GPU) 에 의해, GPU 가 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 수신하는 단계, GPU 에 의해, 수신된 커맨드 패킷에서의 정보 또는 GPU 의 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하는 단계, 및 GPU 에 의해, 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하는 단계를 포함한다.

본 개시의 기법들에 따른 다른 예는 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스를 설명한다. GPU 는 메모리 및 적어도 하나의 프로세서를 포함한다. 적어도 하나의 프로세서는 GPU 가 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 수신하고, 수신된 커맨드 패킷에서의 정보 또는 GPU 의 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하고, 그리고 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하도록 구성될 수도 있다.

본 개시의 기법들에 따른 다른 예는 디바이스를 설명한다. 그 디바이스는 GPU 가 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 수신하는 수단, 수신된 커맨드 패킷에서의 정보 또는 GPU 의 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하는 수단, 및 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하는 수단을 포함한다.

본 개시의 기법들에 따른 다른 예는 저장된 명령들을 포함하는 비-일시적인 컴퓨터 판독가능 저장 매체를 설명한다. 그 명령들은, 실행될 경우, 적어도 하나의 프로세서로 하여금 GPU 가 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 수신하게 하고, 수신된 커맨드 패킷에서의 정보 또는 GPU 의 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하게 하고, 그리고 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하게 할 수도 있다.

도 1 은 본 개시의 기법들에 따른 특정 렌더링 모드를 사용할지 여부를 결정하기 위해 사용될 수도 있는 예시적인 컴퓨팅 디바이스를 도시한 블록 다이어그램이다.
도 2 는 도 1 의 CPU (6), GPU (12), 및 시스템 메모리 (10) 의 예시적인 구현들을 더 상세히 도시한 블록 다이어그램이다.
도 3 은 비닝 렌더링 모드에서 사용된 바와 같은 프레임의 빈들을 도시한 개념 다이어그램이다.
도 4 는 비닝 렌더링 모드에서 사용된 바와 같은 프레임의 빈들을 더 상세하게 도시한 개념 다이어그램이다.
도 5 는 "소프트웨어" 비닝을 사용한 비닝 렌더링 모드에 대한 커맨드 버퍼들을 도시한 개념 다이어그램이다.
도 6 은 "하드웨어" 비닝을 사용한 비닝 렌더링 모드에 대한 커맨드 버퍼들을 도시한 개념 다이어그램이다.
도 7 은 직접 렌더링 모드에 대한 커맨드 버퍼들을 도시한 개념 다이어그램이다.
도 8 은 상이한 렌더링 모드들에 대한 커맨드 버퍼들의 개념 다이어그램이다.
도 9 는 본 개시의 기법들에 따른 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 장면을 렌더링하기 위한 예시적인 커맨드 구조를 도시한 개념 다이어그램이다.
도 10 은 본 개시의 일 예에 따른 방법을 도시한 플로우차트이다.

본 개시는 그래픽스 프로세싱을 위한 기법들에 관한 것으로서, 더 상세하게는, GPU 로 하여금 그래픽스 프로세싱 시스템에 있어서 렌더링 모드를 결정할 수 있게 하고 렌더링 모드들 사이에서 스위칭할 수 있게 하는 기법들에 관한 것이다.

현재 그래픽스 렌더링 시스템들은 통상적으로, 장면을 렌더링하기 위하여 비닝 렌더링 모드 (종종, 타일 기반 렌더링으로 지칭됨) 또는 직접 렌더링 모드를 활용한다. 비닝 렌더링에 있어서, 2D 또는 3D 장면의 일 프레임은 프레임을 더 작은 부분들 (예를 들어, 직사각형 빈들 또는 타일들) 로 분할하고 이들 빈들 각각을 별도로 렌더링함으로써 렌더링된다. 비닝 렌더링은, 예컨대 모바일 어플리케이션들에 대해, 전용 고속 그래픽스 메모리 (GMEM) 가 거의 이용가능하지 않는 어플리케이션들에 대해 뿐 아니라 메모리 대역폭이 제한되는 경우들에서 유용하다. 타일들의 사이즈는 GMEM 에서 이용가능한 데이터의 양을 나타내도록 구성될 수 있다. 예를 들어, GMEM 이 512kB 를 저장할 수 있으면, 타일의 사이즈는 그 타일에 포함된 픽셀 데이터가 512kB 이하이도록 구성될 수도 있다.

한편, 직접 렌더링 모드에서의 그래픽스 프로세싱은 프레임을 더 작은 빈들로 분할하지 않는다. 대신, 프레임 전체가 한번에 렌더링된다. 일부 그래픽스 프로세싱 시스템들 (예를 들어, 모바일 디바이스 상의 그래픽스 프로세싱 시스템) 에 있어서, 픽셀 데이터의 전체 프레임을 유지하기 위해 충분한 GMEM 이 존재하지 않는다. 대신, 직접 렌더링 모드에 대해, 동적 랜덤 액세스 메모리 (DRAM) 와 같은 더 저속의 시스템 메모리가 프레임을 렌더링하기 위해 사용될 수도 있다.

이전의 GPU 커맨드 패킷들은 각각 오직 단일의 간접 버퍼 (IB) 만을 포함하였다. 장면을 렌더링하기 위하여, GPU 구동기는 다중의 커맨드 패킷들을 생성하였으며, 각각의 간접 버퍼에 대한 하나의 커맨드 패킷이 장면을 렌더링하기 위해 요구되었다. "소형 배치" 문제로서 지칭되는, 렌더링될 소수의 삼각형들을 각각 포함하는 다중의 커맨드 패킷들을 생성하는 CPU 및 메모리 오버헤드는 매우 클 수 있다. 일 예로서, GPU 구동기는, 어플리케이션이 오직 묘화 호출들 사이의 최소량의 상태만을 변경하고 있을 경우에 불균형적으로 다량의 작업을 수행할 수도 있다. 본 개시의 기법들은, 다수의 소형 패킷들에서 보다는 단일의 커맨드 패킷에서 장면을 렌더링하는데 필요한 IB들 모두를 포함함으로써, 그리고 렌더링 부하의 일부를, CPU 상에서 실행하는 GPU 구동기로부터 GPU 자체로 이동시킴으로써, CPU 및 메모리 오버헤드를 감소시킬 수도 있다.

부가적으로, CPU 기반 GPU 구동기는 CPU 및 GPU 로 하여금 장면을 렌더링하는데 필요한 커맨드 패킷들 모두를 생성하고 그 장면을 렌더링하기 위하여 렌더링 루프에 걸쳐 다수회 루핑 (loop) 해야만 하게 할 수도 있다. 렌더링 루프는, GPU 구동기가 렌더링될 프레임에 대하여 각각의 개별 빈을 렌더링하도록 실행하는 루프이다. 본 개시의 기법들은, 커맨드 패킷으로 통합되는 부가적인 렌더링 정보, 예를 들어, 빈(bin)들 때문에 그리고 렌더링 로직을 GPU 구동기로부터 GPU 로 이동시킴으로써 렌더링 루프들을 감소 또는 제거할 수도 있다.

본 개시의 기법들은 또한, GPU 가 장면에 대한 렌더링 모드를 결정하기 위해 사용될 수도 있는 더 세부적인 실시간 GPU 상태 정보 (예를 들어, 휴리스틱들) 를 허용한다. CPU 기반 GPU 구동기가 GPU 로부터 GPU 프로세싱 부하와 같은 GPU 상태를 요청할 수 있지만, CPU 상에서 실행하는 구동기는 오직 GPU 로부터 폴링 요청들 및/또는 통계들의 누적만을 사용하여 그렇게 수행할 수 있다. 따라서, CPU 구동기가 액세스할 수 있는 임의의 GPU 상태는 정확하지 않을 수도 있고, 최신이 아닐 수도 있다. 따라서, GPU 상태를 결정하는 것과 관련된 본 개시의 기법들은 더 정확하고 최신의 GPU 상태에 기초하여 렌더 모드의 더 정확한 결정을 허용한다.

부가적으로, 본 개시의 기법들은 커맨드 패킷에 있어서 렌더링될 장면의 해상도와 같은 렌더 타깃 정보 및/또는 CPU 누적된 휴리스틱들을 포함한다. GPU 가 렌더 타깃 정보에 액세스하기 때문에, GPU 자체는, CPU 로 하여금 GPU 상태의 고려없이 GPU 가 사용할 렌더링 모드를 결정하게 하는 것보다는, 커맨드 패킷 뿐 아니라 GPU 부하 및 전력 소비와 같은 다른 GPU 상태 휴리스틱들에 적어도 부분적으로 기초하여 직접 모드 또는 비닝 모드를 사용하여 장면을 렌더링할지 여부를 결정할 수도 있다. 직접 렌더링 모드를 사용하는 것은 렌더링될 지오메트리의 양이 적을 경우에 렌더링 성능을 개선시킬 수도 있지만, 비닝 렌더링 모드는 직접 렌더링에 비해 전력을 절약할 수도 있다. 따라서, GPU 로 하여금 직접 렌더링과 간접 렌더링 사이에서 선택하게 하는 것은 GPU 가 전력, 성능, 및 다른 제약들에 기초하여 렌더링을 최적화하기 위한 유연성을 제공한다.

일반적으로, 직접 렌더링 모드는 비닝 렌더링 모드보다 더 느릴 수도 있다. 하지만, 비닝 렌더링 모드는 일부 고유의 오버헤드를 갖는다. 하지만, 직접 모드 렌더링 모드 부하가 충분히 가벼우면, 직접 렌더링 모드를 사용하는 것이 비닝 모드보다 바람직할 수도 있다. 비닝 렌더링 모드는, 낮은 양의 오버드로우 (overdraw) 가 존재하고 따라서 더 낮은 오버헤드가 존재할 경우에 바람직할 수도 있다. 오버드로우는, 단일 픽셀이 예를 들어, 중첩하는 삼각형들로 인해 프레임마다 렌더링/업데이트되는 횟수에 대응한다.

높은 오버드로우는 직접 렌더링 모드를 위한 (상대적으로 더 느린) 시스템 메모리와의 상호작용 및 높은 대역폭 활용을 야기할 수도 있다. 본 명세서에서 설명된 휴리스틱들은 GPU 로 하여금 직접 렌더링 모드가, 비한정적인 예들로서, 렌더링된 픽셀들의 수, 오버드로우, 클록 속도들, GPU 아키텍처와 같은 팩터들에 기초하여 비닝 렌더링 모드보다 더 빠른 포인트를 결정하게 할 수도 있다.

본 개시의 일 예에 있어서, 그래픽스 프로세싱의 방법은 GPU 에 의해, GPU 가 GPU 에 의해 렌더링될 프레임의 일부를 렌더링하기 위하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 커맨드 패킷을 수신하는 것을 포함한다. GPU 는, 수신된 커맨드 패킷 또는 GPU 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 모드 렌더링을 사용할지를 결정할 수도 있다. GPU 는 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링할 수도 있다.

도 1 은 본 개시의 기법들에 따른 특정 렌더링 모드를 사용할지 여부를 결정하기 위해 사용될 수도 있는 예시적인 컴퓨팅 디바이스를 도시한 블록 다이어그램이다. 컴퓨팅 디바이스 (2) 는, 예를 들어, 개인용 컴퓨터, 데스크탑 컴퓨터, 랩탑 컴퓨터, 태블릿 컴퓨터, 컴퓨터 워크스테이션, 비디오 게임 플랫폼 또는 콘솔, 예를 들어, 셀룰러 또는 위성 전화기와 같은 모바일 전화기, 지상선 전화기, 스마트폰, 휴대용 비디오 게임 디바이스 또는 개인용 디지털 보조기 (PDA) 와 같은 핸드헬드 디바이스, 개인용 뮤직 플레이어, 비디오 플레이어, 디스플레이 디바이스, 텔레비전, 텔레비전 셋탑 박스, 서버, 중간 네트워크 디바이스, 메인프레임 컴퓨터, 임의의 모바일 디바이스, 또는 그래픽 데이터를 프로세싱 및/또는 디스플레이하는 임의의 다른 타입의 디바이스를 포함할 수도 있다.

도 1 의 예에 도시된 바와 같이, 컴퓨팅 디바이스 (2) 는 사용자 입력 인터페이스 (4), 중앙 프로세싱 유닛 (CPU) (6), 메모리 제어기 (8), 시스템 메모리 (10), 그래픽스 프로세싱 유닛 (GPU) (12), 그래픽스 메모리 (14), 디스플레이 인터페이스 (16), 디스플레이 (18) 및 버스들 (20 및 22) 을 포함할 수도 있다. 일부 예들에 있어서, 그래픽스 메모리 (14) 는 GPU (12) 와 "온-칩" 일 수도 있음을 유의한다. 일부 경우들에 있어서, 도 1 에 도시된 모든 하드웨어 엘리먼트들은, 예를 들어, 시스템 온 칩 (SoC) 설계에 있어서 온-칩일 수도 있다. 사용자 입력 인터페이스 (4), CPU (6), 메모리 제어기 (8), GPU (12) 및 디스플레이 인터페이스 (16) 는 버스 (20) 를 이용하여 서로 통신할 수도 있다. 메모리 제어기 (8) 및 시스템 메모리 (10) 는 또한 버스 (22) 를 이용하여 서로 통신할 수도 있다. 버스들 (20, 22) 는 제 3 세대 버스 (예를 들어, HyperTransport 버스 또는 InfiniBand 버스), 제 2 세대 버스 (예를 들어, 어드밴스드 그래픽스 포트 버스, PCI (Peripheral Component Interconnect) 익스프레스 버스, 또는 AXI (Advanced eXentisible Interface) 버스) 또는 다른 타입의 버스 또는 디바이스 상호접속체와 같은 다양한 버스 구조들 중 임의의 구조일 수도 있다. 도 1 에 도시된 상이한 컴포넌트들 사이의 버스들 및 통신 인터페이스들의 특정 구성은 단지 예시적일 뿐이고 동일하거나 상이한 컴포넌트들을 갖는 다른 그래픽스 프로세싱 시스템들 및/또는 컴퓨팅 디바이스들의 다른 구성들이 본 개시의 기법들을 구현하기 위해 사용될 수도 있음을 유의해야 한다.

CPU (6) 는, 컴퓨팅 디바이스 (2) 의 동작을 제어하는 범용 또는 특수목적 프로세서를 포함할 수도 있다. 사용자는 컴퓨팅 디바이스 (2) 에 입력을 제공하여 CPU (6) 로 하여금 하나 이상의 소프트웨어 어플리케이션들을 실행하게 할 수도 있다. CPU (6) 상에서 실행하는 소프트웨어 어플리케이션들은, 예를 들어, 오퍼레이팅 시스템, 워드 프로세서 어플리케이션, 이메일 어플리케이션, 스프레드 시트 어플리케이션, 미디어 플레이어 어플리케이션, 비디오 게임 어플리케이션, 그래픽 사용자 인터페이스 어플리케이션 또는 다른 프로그램을 포함할 수도 있다. 부가적으로, CPU (6) 는 GPU (12) 의 동작을 제어하기 위한 GPU 구동기 (7) 를 실행할 수도 있다. 사용자는, 사용자 입력 인터페이스 (4) 를 통해 컴퓨팅 디바이스 (2) 에 커플링된 키보드, 마우스, 마이크로폰, 터치 패드 또는 다른 입력 디바이스와 같은 하나 이상의 입력 디바이스들 (도시 안됨) 을 통해 컴퓨팅 디바이스 (2) 에 입력을 제공할 수도 있다.

CPU (6) 상에서 실행하는 소프트웨어 어플리케이션들은, 그래픽스 데이터의 디스플레이 (18) 로의 렌더링을 야기하도록 CPU (6) 에게 지시하는 하나 이상의 그래픽스 렌더링 명령들을 포함할 수도 있다. 일부 예들에 있어서, 소프트웨어 명령들은, 예를 들어, 오픈 그래픽스 라이브러리 (OpenGL^®) API, 오픈 그래픽스 라이브러리 임베디드 시스템즈 (OpenGL ES) API, 다이렉트3D API, X3D API, 렌더맨 API, WebGL API, 또는 임의의 다른 공개 또는 독점 표준 그래픽스 API 와 같은 그래픽스 어플리케이션 프로그래밍 인터페이스 (API) 에 부합할 수도 있다. 그 명령들은 또한, 다양한 예들에 있어서 OpenCL 및/또는 DirectCompute 와 같은 소위 이종의 컴퓨팅 라이브러리들에 부합할 수도 있다. 그래픽스 렌더링 명령들을 프로세싱하기 위하여, CPU (6) 는 하나 이상의 그래픽스 렌더링 커맨드들을 (예를 들어, GPU 구동기 (7) 를 통해) GPU (12) 에 발행하여 GPU (12) 로 하여금 그래픽스 데이터의 렌더링의 일부 또는 전부를 수행하게 할 수도 있다. 일부 예들에 있어서, 렌더링될 그래픽스 데이터는 그래픽스 프리미티브들, 예를 들어, 포인트들, 라인들, 삼각형들, 사변형들, 삼각 스트립들 등의 리스트를 포함할 수도 있다.

메모리 제어기 (8) 는 시스템 메모리 (10) 로 들어가고 나오는 데이터의 이송을 용이하게 한다. 예를 들어, 메모리 제어기 (8) 는 메모리 판독 및 기입 커맨드들을 수신하고, 컴퓨팅 디바이스 (2) 에서의 컴포넌트들에 대한 메모리 서비스들을 제공하기 위하여 그러한 커맨드들을 메모리 시스템 (10) 에 관하여 서비스할 수도 있다. 메모리 제어기 (8) 는 메모리 버스 (22) 를 통해 시스템 메모리 (10) 에 통신가능하게 커플링된다. 비록 메모리 제어기 (8) 가 CPU (6) 및 시스템 메모리 (10) 양자로부터 분리된 프로세싱 모듈인 것으로서 도 1 에 도시되지만, 다른 예들에 있어서, 메모리 제어기 (8) 의 기능의 일부 또는 전부는 CPU (6) 및 시스템 메모리 (10) 중 하나 또는 그들 양자 상에서 구현될 수도 있다.

시스템 메모리 (10) 는, CPU (6) 에 의한 실행을 위해 액세스가능한 프로그램 모듈들 및/또는 명령들, 그리고 CPU (6) 상에서 실행하는 프로그램들에 의한 사용을 위한 데이터를 저장할 수도 있다. 예를 들어, 시스템 메모리 (10) 는, 디스플레이 (18) 상에 그래픽 사용자 인터페이스 (GUI) 를 제시하기 위해 CPU (6) 에 의해 사용되는 윈도우 관리자 어플리케이션을 저장할 수도 있다. 부가적으로, 시스템 메모리 (10) 는 사용자 어플리케이션들 및 그 어플리케이션들과 연관된 어플리케이션 표면 데이터를 저장할 수도 있다. 시스템 메모리 (10) 는 부가적으로, 컴퓨팅 디바이스 (2) 의 다른 컴포넌트들에 의해 사용하기 위한 및/또는 그 다른 컴포넌트들에 의해 생성된 정보를 저장할 수도 있다. 예를 들어, 시스템 메모리 (10) 는 GPU (12) 에 대한 디바이스 메모리로서 작용할 수도 있으며, GPU (12) 에 의해 동작될 데이터 뿐 아니라 GPU (12) 에 의해 수행된 동작들로부터 기인한 데이터를 저장할 수도 있다. 예를 들어, 시스템 메모리 (10) 는 텍스처 버퍼들, 심도 버퍼들, 스텐실 버퍼들, 버텍스 버퍼들, 프레임 버퍼들 등의 임의의 조합을 저장할 수도 있다. 시스템 메모리 (10) 는, 예를 들어, 랜덤 액세스 메모리 (RAM), 정적 RAM (SRAM), 동적 RAM (DRAM), 판독 전용 메모리 (ROM), 소거가능한 프로그래밍가능 ROM (EPROM), 전기적으로 소거가능한 프로그래밍가능 ROM (EEPROM), 플래시 메모리, 자기 데이터 매체들 또는 광학 저장 매체들과 같은 하나 이상의 휘발성 또는 비휘발성 메모리들 또는 저장 디바이스들을 포함할 수도 있다.

GPU (12) 는 하나 이상의 그래픽스 프리미티브들을 디스플레이 (18) 에 렌더링하기 위해 그래픽스 동작들을 수행하도록 구성될 수도 있다. 따라서, CPU (6) 상에서 실행하는 소프트웨어 어플리케이션들 중 하나가 그래픽스 프로세싱을 요구할 경우, CPU (6) 는 디스플레이 (18) 로의 렌더링을 위해 그래픽스 커맨드들 및 그래픽스 데이터를 GPU (12) 에 제공할 수도 있다. 그래픽스 데이터는, 예를 들어, 묘화 커맨드들, 상태 정보, 프리미티브 정보, 텍스처 정보 등을 포함할 수도 있다. GPU (12) 는, 일부 경우들에 있어서, CPU (6) 보다 복잡한 그래픽 관련 동작들의 더 효율적인 프로세싱을 제공하는 고도로 병렬적인 구조로 구축될 수도 있다. 예를 들어, GPU (12) 는, 다중의 버텍스들 또는 픽셀들 상에서 병렬 방식으로 동작하도록 구성되는 복수의 프로세싱 엘리먼트들을 포함할 수도 있다. GPU (12) 의 고도로 병렬적인 본성은, 일부 경우들에 있어서, GPU (12) 로 하여금 CPU (6) 를 사용하여 장면들을 디스플레이 (18) 에 직접 묘화하는 것보다 더 신속하게 그래픽스 이미지들 (예를 들어, GUI들 및 2차원 (2D) 및/또는 3차원 (3D) 그래픽스 장면들) 을 디스플레이 (18) 상으로 묘화하게 할 수도 있다.

GPU (12) 는, 일부 경우들에 있어서, 컴퓨팅 디바이스 (2) 의 마더보드에 통합될 수도 있다. 다른 경우들에 있어서, GPU (12) 는 컴퓨팅 디바이스 (2) 의 마더보드 내의 포트에 설치되는 그래픽스 카드 상에 존재할 수도 있거나, 그렇지 않으면, 컴퓨팅 디바이스 (2) 와 상호작용하도록 구성된 주변기기 디바이스 내에 통합될 수도 있다. GPU (12) 는 하나 이상의 마이크로프로세서들, 주문형 집적회로들 (ASIC들), 필드 프로그래밍가능 로직 어레이들 (FPGA들), 디지털 신호 프로세서들 (DSP들), 또는 다른 등가의 집적된 또는 별도의 로직 회로부와 같은 하나 이상의 프로세서들을 포함할 수도 있다.

GPU (12) 는 그래픽스 메모리 (14) 에 직접 커플링될 수도 있다. 따라서, GPU (12) 는 버스 (20) 를 사용하지 않고도 데이터를 그래픽스 메모리 (14) 로부터 판독하고 데이터를 그래픽스 메모리 (14) 에 기입할 수도 있다. 즉, GPU (12) 는 오프-칩 메모리 대신 로컬 저장부를 사용하여 데이터를 국부적으로 프로세싱할 수도 있다. 이는 GPU (12) 로 하여금 무거운 버스 트래픽을 경험할 수도 있는 버스 (20) 를 통해 데이터를 판독 및 기입하기 위한 GPU (12) 의 필요성을 제거함으로써 더 효율적인 방식으로 동작하게 한다. 하지만, 일부 경우들에 있어서, GPU (12) 는 별도의 메모리를 포함하지 않을 수도 있지만, 대신, 버스 (20) 를 통해 시스템 메모리 (10) 를 활용할 수도 있다. 그래픽스 메모리 (14) 는, 예를 들어, 랜덤 액세스 메모리 (RAM), 정적 RAM (SRAM), 동적 RAM (DRAM), 소거가능한 프로그래밍가능 ROM (EPROM), 전기적으로 소거가능한 프로그래밍가능 ROM (EEPROM), 플래시 메모리, 자기 데이터 매체들 또는 광학 저장 매체들과 같은 하나 이상의 휘발성 또는 비휘발성 메모리들 또는 저장 디바이스들을 포함할 수도 있다.

CPU (6) 및/또는 GPU (12) 는 렌더링된 이미지 데이터를 프레임 버퍼 (15) 에 저장할 수도 있다. 프레임 버퍼 (15) 는 독립적 메모리일 수도 있거나 또는 시스템 메모리 (10) 내에 할당될 수도 있다. 디스플레이 인터페이스 (16) 는 프레임 버퍼 (15) 로부터 데이터를 취출하며, 그리고 렌더링된 이미지 데이터에 의해 표현된 이미지를 디스플레이하도록 디스플레이 (18) 를 구성할 수도 있다. 일부 예들에 있어서, 디스플레이 인터페이스 (16) 는, 프레임 버퍼로부터 취출된 디지털 값들을 디스플레이 (18) 에 의해 소비가능한 아날로그 신호로 변환하도록 구성된 디지털-아날로그 변환기 (DAC) 를 포함할 수도 있다. 다른 예들에 있어서, 디스플레이 인터페이스 (16) 는 프로세싱을 위해 디지털 값들을 디스플레이 (18) 로 직접 전달할 수도 있다. 디스플레이 (18) 는 모니터, 텔레비전, 프로젝션 디바이스, 액정 디스플레이 (LCD), 플라즈마 디스플레이 패널, 발광 다이오드 (LED) 어레이, 예컨대, 유기 LED (OLED) 디스플레이, 음극선관 (CRT) 디스플레이, 전자 페이퍼, 표면 전도 전자 방출형 디스플레이 (SED), 레이저 텔레비전 디스플레이, 나노크리스탈 디스플레이 또는 다른 타입의 디스플레이 유닛을 포함할 수도 있다. 디스플레이 (18) 는 컴퓨팅 디바이스 (2) 내에 통합될 수도 있다. 예를 들어, 디스플레이 (18) 는 모바일 전화기의 스크린일 수도 있다. 대안적으로, 디스플레이 (18) 는 유선 또는 무선 통신 링크를 통해 컴퓨터 디바이스 (2) 에 커플링된 자립형 디바이스일 수도 있다. 예를 들어, 디스플레이 (18) 는 케이블 또는 무선 링크를 통해 개인용 컴퓨터에 접속된 컴퓨터 모니터 또는 플랫 패널 디스플레이일 수도 있다.

본 개시의 일 예에 따르면, CPU (6) 및/또는 GPU 구동기 (7) 는 GPU (12) 가 직접 렌더링 모드와 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 GPU 커맨드 패킷을 생성하도록 구성될 수도 있다. GPU 커맨드 패킷은, 본 명세서에서 더 상세하게 논의될 바와 같이, 다양한 예들에 있어서 PM4 ("프로그래밍 모델 4") 포맷을 갖는 GPU 커맨드 패킷을 포함할 수도 있다.

커맨드 패킷은 렌더링 장면 디스크립터, 프레임을 렌더링하기 위한 커맨드들, 예컨대, 간접 버퍼 정보 뿐 아니라 구성 데이터 (예를 들어, 구성 쌍들), 및 렌더링될 장면에 관한 정보, 예컨대, 레더링될 장면의 해상도 (예를 들어, 픽셀 단위의 높이 및 폭) 를 포함할 수도 있다. GPU (12) 는, 수신된 커맨드 패킷에 포함된 정보에 적어도 부분적으로 기초하여 그래픽 장면을 렌더링하기 위해 직접 모드 렌더링을 사용할지 또는 비닝 모드 렌더링을 사용할지를 결정할 수도 있다. 하지만, 커맨드 패킷은 선호된 렌더링 모드를 직접 표시하지 않을 수도 있다.

렌더 타깃 디스크립터는, GPU (12) 가 실행할 수도 있는 각각의 렌더링 모드에 대해 구성 정보, 프리앰블들, 렌더링, 비닝 및 커맨드 버퍼 포인터들을 포함한다. 일부 예들에 있어서, 렌더링 타깃 디스크립터는 또한, GPU (12) 가 현재 장면에 대한 렌더링 모드를 결정하기 위해 사용할 수도 있는 정보를 포함할 수도 있다. 예를 들어, 렌더 타깃 디스크립터는 또한, 비닝 렌더링 모드를 사용하여 렌더링하기 위해 사용될 빈들의 높이 및 폭을 표시할 수도 있다. GPU (12) 는 구성 정보를 검사하고, 렌더 타깃 디스크립터의 정보에 기초하여, 현재 장면에 대한 렌더링 모드를 결정할 수도 있다. 결정된 렌더링 모드에 기초하여, GPU (12) 는, 필요에 따라, 타깃 렌더링 모드에 대응하는 커맨드 버퍼들에서의 명령들을 실행한다.

커맨드 패킷에 포함된 간접 버퍼 정보의 관점에서, 커맨드 패킷은 하나 이상의 간접 버퍼들, 컬러 언리졸브 (unresolve) 버퍼들, 및 심도 스텐실 언리졸브 버퍼들로의 포인터들을 포함할 수도 있다. 커맨드 패킷은 또한 최상위 비트들, 및 이들 간접 버퍼들의 길이들을 포함할 수도 있다. PM4 커맨드의 타입은 MSB들에 포함된다. GPU (12) 는, GPU (12) 가 시스템 메모리 (10) 와 같은 외부 메모리로부터 GPU 메모리로의 값들을 판독할 수도 있는 언리졸브 버퍼들을 사용할 수도 있다. GPU (12) 는, 예를 들어, 1 초과의 장면에 걸쳐 변하지 않는 픽셀 데이터를 보존하기 위해 장면의 오직 일부만이 새로운 데이터로 업데이트되고 있을 경우에 언리졸브 프로세스를 수행할 수도 있다.

커맨드 패킷은 또한 다양한 "클리어" ("폐기" 로서도 또한 지칭됨) 직사각형들을 포함할 수도 있다. 클리어 직사각형들은 예를 들어 UI 의 프레임 버퍼의 영역들을 표시할 수도 있으며, 이 영역들은 일 프레임으로부터 다음 프레임까지 보존되지 않는다. GPU (12) 는 클리어 직사각형들에 의해 명시된 영역들로부터 픽셀 또는 지오메트리 데이터를 로딩하지 않을 수도 있다.

GPU (12) 는 또한, GPU 상태 휴리스틱들에 기초하여 직접 렌더링을 사용할지 또는 비닝 렌더링을 사용할지를 결정할 수도 있다. GPU 휴리스틱들의 예들은 GPU 프로세싱 부하, GPU 전력 소비, 및/또는 GPU 메모리 사용 또는 GPU (12) 의 임의의 다른 상태 파라미터를 포함할 수도 있다. 직접 렌더링을 사용할지 또는 비닝을 사용할지를 결정하는 예로서, GPU (12) 는, GPU 전력 소비가 임계 전력 소비를 초과할 경우에 전력을 보존하기 위해 직접 렌더링 모드로부터 스위칭할 수도 있다. 유사하게, GPU (12) 는, 전력 소비 또는 GPU 부하가 낮을 경우에 비닝 렌더링 모드로부터 직접 렌더링 모드로 스위칭할 수도 있다.

본 개시의 기법들에 따르면, GPU (12) 는, GPU 가 프레임의 일부를 렌더링하기 위해 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시하는 렌더 타깃 디스크립터를 수신하고, 수신된 커맨드 패킷 또는 GPU 상태 중 적어도 하나에 기초하여 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 모드 렌더링을 사용할지를 결정하고, 그리고 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링하도록 구성될 수도 있다.

도 2 는 도 1 의 CPU (6), GPU (12), 및 시스템 메모리 (10) 의 예시적인 구현들을 더 상세히 도시한 블록 다이어그램이다. CPU (6) 는 적어도 하나의 소프트웨어 어플리케이션 (24), 그래픽스 API (26), 및 GPU 구동기 (7) 를 포함할 수도 있으며, 그 각각은 CPU (6) 상에서 실행하는 하나 이상의 소프트웨어 어플리케이션들 또는 서비스들일 수도 있다. GPU (12) 는, 그래픽스 프로세싱 커맨드들을 실행하도록 함께 동작하는 복수의 그래픽스 프로세싱 스테이지들을 포함하는 그래픽스 프로세싱 파이프라인 (30) 을 포함할 수도 있다. GPU (12) 는 비닝 렌더링 모드 및 직접 렌더링 모드를 포함하여 다양한 렌더링 모드들에 있어서 그래픽스 프로세싱 파이프라인 (30) 을 실행하도록 구성될 수도 있다. 도 2 에 도시된 바와 같이, 그래픽스 프로세싱 파이프라인 (30) 은 커맨드 엔진 (32), 지오메트리 프로세싱 스테이지 (34), 래스터화 스테이지 (36), 및 픽셀 프로세싱 파이프라인 (38) 을 포함할 수도 있다. 그래픽스 프로세싱 파이프라인 (30) 에서의 컴포넌트들 각각은 고정 기능 컴포넌트들로서, 프로그래밍가능 컴포넌트들로서 (예를 들어, 프로그래밍가능 쉐이더 유닛 상에서 실행하는 쉐이더 프로그램의 부분으로서), 또는 고정 기능과 프로그래밍가능 컴포넌트들의 조합으로서 구현될 수도 있다. CPU (6) 및 GPU (12) 에게 이용가능한 메모리는 시스템 메모리 (10) 및 프레임 버퍼 (15) 를 포함할 수도 있다. 프레임 버퍼 (15) 는 시스템 메모리 (10) 의 부분일 수도 있거나 또는 시스템 메모리 (10) 로부터 별개일 수도 있다. 프레임 버퍼 (15) 는 렌더링된 이미지 데이터를 저장할 수도 있다.

소프트웨어 어플리케이션 (24) 은, GPU (12) 의 기능을 활용하는 임의의 어플리케이션일 수도 있다. 예를 들어, 소프트웨어 어플리케이션 (24) 은 GUI 어플리케이션, 오퍼레이팅 시스템, 휴대용 매핑 어플리케이션, 엔지니어링 또는 아티스틱 어플리케이션들을 위한 컴퓨터-지원 설계 프로그램, 비디오 게임 어플리케이션, 또는 2D 또는 3D 그래픽스를 사용하는 다른 타입의 소프트웨어 어플리케이션일 수도 있다.

소프트웨어 어플리케이션 (24) 은, 그래픽 사용자 인터페이스 (GUI) 및/또는 그래픽스 장면을 렌더링하도록 GPU (12) 에게 지시하는 하나 이상의 묘화 명령들을 포함할 수도 있다. 예를 들어, 묘화 명령들은, GPU (12) 에 의해 렌더링될 하나 이상의 그래픽스 프리미티브들의 세트를 정의하는 명령들을 포함할 수도 있다. 일부 예들에 있어서, 묘화 명령들은, 집합적으로, GUI 에서 사용된 복수의 윈도윙 표면들의 전부 또는 그 부분을 정의할 수도 있다. 부가적인 예들에 있어서, 묘화 명령들은, 집합적으로, 어플리케이션에 의해 정의된 모델 공간 또는 월드 공간 내에 하나 이상의 그래픽스 오브젝트들을 포함하는 그래픽스 장면의 전부 또는 그 부분을 정의할 수도 있다.

소프트웨어 어플리케이션 (24) 은 그래픽스 API (26) 를 통해 GPU 구동기 (7) 를 호출하여, 하나 이상의 그래픽스 프리미티브들을 디스플레이가능 그래픽스 이미지들로 렌더링하기 위한 하나 이상의 커맨드들을 GPU (12) 에 발행할 수도 있다. 다양한 예들에 있어서, 커맨드들은, 장면 (즉, 하나 이상의 프레임들) 을 렌더링하는 것과 관련된 커맨드들 뿐 아니라 다른 정보를 포함할 수도 있는 데이터의 소위 "패킷들" 을 포함할 수도 있다. 예를 들어, 소프트웨어 어플리케이션 (24) 은 그래픽스 API (26) 를 통해 GPU 구동기 (7) 를 호출하여, 프리미티브 정의들을 GPU (12) 에 제공할 수도 있다. 일부 경우들에 있어서, 프리미티브 정의들은 묘화 프리미티브들, 예를 들어, 삼각형들, 직사각형들, 삼각형 팬들, 삼각형 스트립들 등의 리스트의 형태로 GPU (12) 에 제공될 수도 있다. 프리미티브 정의들은, 렌더링될 프리미티브들과 연관된 하나 이상의 버텍스들을 명시하는 버텍스 사양들을 포함할 수도 있다. 버텍스 사양들은 각각의 버텍스에 대한 포지션 좌표들, 및 일부 경우들에 있어서 예를 들어 컬러 좌표들, 법선 벡터들, 및 텍스처 좌표들과 같은 버텍스와 연관된 다른 속성들을 포함할 수도 있다. 프리미티브 정의들은 또한, 프리미티브 타입 정보 (예를 들어, 삼각형, 직사각형, 삼각형 팬, 삼각형 스트립 등), 스케일링 정보, 회전 정보 등을 포함할 수도 있다. 소프트웨어 어플리케이션 (24) 에 의해 GPU 구동기 (7) 에 발행된 명령들에 기초하여, GPU 구동기 (7) 는, 프리미티브를 렌더링하기 위해 GPU (12) 가 수행하기 위한 하나 이상의 동작들을 명시하는 하나 이상의 커맨드들을 공식화할 수도 있다. GPU (12) 가 CPU (6) 로부터 커맨드를 수신할 경우, 그래픽스 프로세싱 파이프라인 (30) 은 커맨드를 디코딩하고, 커맨드에 명시된 동작을 수행하도록 그래픽스 프로세싱 파이프라인 (30) 내의 하나 이상의 프로세싱 엘리먼트들을 구성한다. 명시된 동작들을 수행한 이후, 그래픽스 프로세싱 파이프라인 (30) 은 렌더링된 데이터를, 디스플레이 디바이스와 연관된 프레임 버퍼 (15) 에 출력한다. 그래픽스 파이프라인 (30) 은 비닝 렌더링 모드 및 직접 렌더링 모드를 포함하여 복수의 상이한 렌더링 모드들 중 하나에 있어서 실행하도록 구성될 수도 있다. 비닝 렌더링 모드 및 직접 렌더링 모드의 동작은 하기에서 더 상세히 논의될 것이다.

GPU 구동기 (7) 는 추가로, 하나 이상의 쉐이더 프로그램들을 컴파일하고, 그리고 컴파일된 쉐이더 프로그램들을, GPU (12) 내에 포함된 하나 이상의 프로그래밍가능 쉐이더 유닛들 상으로 다운로드하도록 구성될 수도 있다. 쉐이더 프로그램들은, 예를 들어, OpenGL 쉐이딩 언어 (GLSL), 하이 레벨 쉐이딩 언어 (HLSL), Cg (C for Graphics) 쉐이딩 언어 등과 같은 하이 레벨 쉐이딩 언어로 기입될 수도 있다. 컴파일된 쉐이더 프로그램들은, GPU (12) 내에서의 프로그래밍가능 쉐이더 유닛의 동작을 제어하는 하나 이상의 명령들을 포함할 수도 있다. 예를 들어, 쉐이더 프로그램들은 버텍스 쉐이더 프로그램들 및/또는 픽셀 쉐이더 프로그램들을 포함할 수도 있다. 버텍스 쉐이더 프로그램은 프로그래밍가능 버텍스 쉐이더 유닛 또는 통일된 쉐이더 유닛의 실행을 제어하고, 하나 이상의 버텍스 당 (per-vertex) 동작들을 명시하는 명령들을 포함할 수도 있다. 픽셀 쉐이더 프로그램은 프로그래밍가능 픽셀 쉐이더 유닛 또는 통일된 쉐이더 유닛의 실행을 제어하고, 하나 이상의 픽셀 당 동작들을 명시하는 명령들을 포함하는 픽셀 쉐이더 프로그램들을 포함할 수도 있다.

GPU 구동기 (7) 는 또한, GPU (12) 가 프레임 또는 프레임의 일부를 렌더링할 경우에 사용할 렌더링 모드를 정의하는 커맨드들, 예를 들어, 하나 이상의 커맨드들, 헤더들, 렌더 장면 디스크립터들, 버퍼들 등으로 이루어진 커맨드 패킷들을 GPU (12) 로 전송할 수도 있다. 예를 들어, GPU 구동기 (7) 는, 특정 프레임이 직접 모드 렌더링을 사용하여 렌더링되어야 하고 다른 프레임은 비닝 모드 렌더링을 사용하여 렌더링되어야 함을 결정할 수도 있다. GPU 구동기 (7) 는 또한, GPU 커맨드 패킷을 GPU (12) 로 전송함으로써 프레임의 일부를 렌더링할 경우에 어느 렌더링 모드인지를 결정하도록 GPU (12) 에게 지시할 수도 있다.

본 개시의 기법들은 GPU (12) 로 하여금 CPU (6) 상에서 실행하는 GPU 구동기 (7) 와 같은 다른 프로세싱 유닛의 개입없이 직접 모드 렌더링과 비닝 모드 렌더링 사이에서 선택할 수 있게 한다. 직접 렌더링 모드와 비닝 렌더링 모드 사이에서 선택하기 위한 이전의 기법들은 특정 프레임 또는 프레임의 부분을 렌더링할 경우에 어느 렌더링 모드가 사용될지를 결정하고 GPU (12) 에게 지시하기 위하여 휴리스틱들과 연관된 다수의 계산들을 수행하도록 GPU 구동기 (7) 및/또는 CPU (6) 에게 요구할 수 있다. 구동기가 수행하였던 휴리스틱 기반 계산들은, 어플리케이션 성능에 영향을 줄 수 있는 높은 양의 CPU 활용도, 및 일부 경우들에 있어서 컴퓨팅 디바이스 (2) 의 전체 응답성을 야기할 수 있었다.

상기 나타낸 바와 같이, GPU (12) 는 수신된 커맨드 패킷으로부터의 정보에 기초하여 및/또는 GPU 상태에 기초하여 결정된 모드에 대한 큐잉된 렌더링 커맨드들의 실행 시퀀스 및 순서를 제어한다. GPU 상태는, GPU (12) 가 예를 들어 전력 소비, 메모리 소비, 작업부하 정보, 및/또는 다른 상태 또는 프로파일링 정보와 관련되어 유지하는 실시간 상태 및 통계들을 포함할 수도 있다.

GPU (12) 로 하여금 직접 렌더링 모드와 비닝 렌더링 모드 사이에서 선택할 수 있게 하기 위하여, CPU (6) 는 GPU 커맨드 패킷 (예를 들어, 렌더 장면 디스크립터) 을 생성하고 GPU 커맨드 패킷을 GPU (12) 로 송신할 수도 있다. 다양한 예들에 있어서, 커맨드 패킷은 PM4 패킷을 포함할 수도 있다. 상기 설명된 바와 같이, PM4 패킷은 하나 이상의 IB들로의 포인터들, 스크린 해상도를 포함하는 렌더 타깃 정보, (예를 들어, 16 픽셀의 배수로의) 빈 폭들, 리졸브 버퍼들, 클리어 영역들, 및 다른 정보를 포함할 수도 있다.

그래픽스 프로세싱 파이프라인 (30) 은 CPU (6) 로부터 GPU 구동기 (7) 를 통해 하나 이상의 그래픽스 프로세싱 커맨드들을 수신하고 그리고 그래픽스 프로세싱 커맨드들을 실행하여 디스플레이가능 그래픽스 이미지들을 생성하도록 구성될 수도 있다. 상기 논의된 바와 같이, 그래픽스 프로세싱 파이프라인 (30) 은 그래픽스 프로세싱 커맨드들을 실행하도록 함께 동작하는 복수의 스테이지들을 포함한다. 하지만, 그러한 스테이지들은 반드시 별도의 하드웨어 블록들에서 구현될 필요는 없음을 유의해야 한다. 예를 들어, 지오메트리 프로세싱 스테이지 (34) 및 픽셀 프로세싱 파이프라인 (38) 의 부분들은 통일된 쉐이더 유닛의 부분으로서 구현될 수도 있다. 다시, 그래픽스 파이프라인 (30) 은, CPU (6) 가 실행하도록 구성되는 GPU 구동기 (7) 로부터 디스크립터 패킷을 수신하는 것에 응답하여, 비닝 렌더링 모드 및 직접 렌더링 모드를 포함하여 복수의 상이한 렌더링 모드들 중 하나에 있어서 실행하도록 구성될 수도 있다.

커맨드 엔진 (32) 은 그래픽스 프로세싱 커맨드들을 수신하고, 그래픽스 프로세싱 커맨드들을 실행하기 위한 다양한 동작들을 수행하도록 그래픽스 프로세싱 파이프라인 (30) 내의 나머지 프로세싱 스테이지들을 구성할 수도 있다. 커맨드 엔진 (32) 은 GPU 구동기 (7) 로부터 커맨드 패킷을 수신할 수도 있다. 그래픽스 프로세싱 커맨드들은, 예를 들어, 묘화 커맨드들 및 그래픽스 상태 커맨드들을 포함할 수도 있다. 묘화 커맨드들은, 하나 이상의 버텍스들에 대한 포지션 좌표들, 및 일부 경우들에 있어서 예를 들어 컬러 좌표들, 법선 벡터들, 텍스처 좌표들, 및 포그 (fog) 좌표들과 같은 버텍스들 각각과 연관된 다른 속성 값들을 명시하는 버텍스 사양 커맨드들을 포함할 수도 있다. 그래픽스 상태 커맨드들은 프리미티브 타입 커맨드들, 변환 커맨드들, 조명 커맨드들 등을 포함할 수도 있다. 프리미티브 타입 커맨드들은 렌더링될 프리미티브의 타입 및/또는 프리미티브를 형성하기 위해 버텍스들이 결합되는 방법을 명시할 수도 있다. 변환 커맨드들은 버텍스들에 대해 수행하기 위한 변환들의 타입들을 명시할 수도 있다. 조명 커맨드들은 그래픽스 장면 내에서의 상이한 빛들의 타입, 방향 및/또는 배치를 명시할 수도 있다. 커맨드 엔진 (32) 은 지오메트리 프로세싱 스테이지 (34) 로 하여금 하나 이상의 수신된 커맨드들과 연관된 버텍스들 및/또는 프리미티브들에 대하여 지오메트리 프로세싱을 수행하게 할 수도 있다.

GPU (12) 는 커맨드 패킷을 수신하고, GPU 커맨드 패킷을 수신한 것에 응답하여, CPU (6) 로부터의 추가적인 개입을 요구하는 일없이 직접 모드와 비닝 모드 사이에서 선택할 수도 있다. GPU (12) 는, 커맨드 패킷의 데이터 및 GPU 상태 휴리스틱들 중 적어도 하나에 기초하여 직접 모드 렌더링을 사용할지 또는 비닝 모드 렌더링을 사용할지를 결정할 수도 있다. 다른 예로서, GPU (12) 는 GPU 상태를 사용하여, 직접 렌더링 모드가 비닝 렌더링 모드보다 더 빠르게 장면을 렌더링할 때를 결정할 수도 있다.

일 예로서, GPU (12) 는 GPU 상태, 예를 들어, GPU 프로세싱 부하, 전력 소비, 메모리 사용, 또는 직접 렌더링 모드와 비닝 렌더링 모드 사이에서 선택하기 위한 GPU (12) 의 하나 이상의 다른 성능 프로파일링 특성을 사용할 수도 있다. 휴리스틱들에 기초하여 직접 렌더링과 비닝 렌더링 사이에서 스위칭하는 예로서, GPU (12) 는, GPU 전력 소비가 임계 전력 소비를 초과할 경우에 전력을 보존하여 전력을 절약하기 위해 직접 렌더링 모드로부터 스위칭할 수도 있다. 유사하게, GPU (12) 는, 전력 소비 또는 GPU 부하가 낮을 경우에 비닝 렌더링 모드로부터 직접 렌더링 모드로 스위칭할 수도 있다.

일 예로서, 높은 GPU 활용도 (예를 들어, 80% 초과) 는 GPU 가 비지 (busy) 인 시간이 다량 존재하고 GPU 의 버스가 데이터 이송들로 포화됨을 나타낼 수 있다. GPU (12) 는 GPU (12) 의 측정된 이송 스루풋을 이론적 최대 스루풋과 비교함으로써 발생하는 데이터 이송량을 측정할 수도 있다. GPU (12) 는 또한, (예를 들어, 쉐이더 프로세서가 측정 주기 동안 GPU (12) 에 의해 사용되었던 1000 사이클들 중 900 사이클들 동안 비지였다면) GPU (12) 의 "올웨이즈 온 (always on)" 카운터와 비교할 때 개별 GPU 하드웨어 블록들의 비지 카운터들의 값을 판독할 수도 있다.

지오메트리 프로세싱 스테이지 (34) 는 래스터화 스테이지 (36) 에 대한 프리미티브 데이터를 생성하기 위하여 하나 이상의 버텍스들에 대해 버텍스 당 동작들 및/또는 프리미티브 셋업 동작들을 수행할 수도 있다. 각각의 버텍스는, 예를 들어, 포지션 좌표들, 컬러 값들, 법선 벡터, 및 텍스처 좌표들과 같은 속성들의 세트와 연관될 수도 있다. 지오메트리 프로세싱 스테이지 (34) 는 다양한 버텍스 당 동작들에 따라 이들 속성들 중 하나 이상을 수정한다. 예를 들어, 지오메트리 프로세싱 스테이지 (34) 는 버텍스 포지션 좌표들에 대해 하나 이상의 변환들을 수행하여 수정된 버텍스 포지션 좌표들을 생성할 수도 있다. 지오메트리 프로세싱 스테이지 (34) 는, 예를 들어, 모델링 변환, 뷰잉 변환, 프로젝션 변환, 모델뷰 변환, 모델뷰 프로젝션 변환, 뷰포트 변환 및 심도 범위 스케일링 변환 중 하나 이상을 버텍스 포지션 좌표들에 적용하여 수정된 버텍스 포지션 좌표들을 생성할 수도 있다. 일부 경우들에 있어서, 버텍스 포지션 좌표들은 모델 공간 좌표들일 수도 있으며, 수정된 버텍스 포지션 좌표들은 스크린 공간 좌표들일 수도 있다. 스크린 공간 좌표들은 모델링, 뷰잉, 프로젝션 및 뷰포트 변환들의 적용 이후에 획득될 수도 있다. 일부 경우들에 있어서, 지오메트리 프로세싱 스테이지 (34) 는 또한, 버텍스들에 대해 버텍스 당 조명 동작들을 수행하여 버텍스들에 대한 수정된 컬러 좌표들을 생성할 수도 있다. 지오메트리 프로세싱 스테이지 (34) 는 또한, 예를 들어, 정규 변환, 정규 정규화 동작들, 뷰 볼륨 클리핑, 동종 분할 및/또는 배면 컬링 동작들을 포함한 다른 동작들을 수행할 수도 있다.

지오메트리 프로세싱 스테이지 (34) 는, 래스터화될 프리미티브를 정의하는 하나 이상의 수정된 버텍스들의 세트를 포함하는 프리미티브 데이터 뿐 아니라 프리미티브를 형성하기 위해 버텍스들이 결합하는 방법을 명시하는 데이터를 생성할 수도 있다. 수정된 버텍스들 각각은, 예를 들어, 버텍스와 연관된 수정된 버텍스 포지션 좌표들 및 프로세싱된 버텍스 속성 값들을 포함할 수도 있다. 프리미티브 데이터는, 집합적으로, 그래픽스 프로세싱 파이프라인 (30) 의 추가적인 스테이지들에 의해 래스터화될 프리미티브에 대응할 수도 있다. 개념적으로, 각각의 버텍스는, 프리미티브의 2개의 에지들이 만나는 프리미티브의 코너에 대응할 수도 있다. 지오메트리 프로세싱 스테이지 (34) 는 추가적인 프로세싱을 위해 래스터화 스테이지 (36) 에 프리미티브 데이터를 제공할 수도 있다.

일부 예들에 있어서, 지오메트리 프로세싱 스테이지 (34) 의 전부 또는 그 부분은 하나 이상의 쉐이더 유닛들 상에서 실행하는 하나 이상의 쉐이더 프로그램들에 의해 구현될 수도 있다. 예를 들어, 지오메트리 프로세싱 스테이지 (34) 는, 그러한 예들에 있어서, 버텍스 쉐이더, 지오메트리 쉐이더, 또는 이들의 임의의 조합에 의해 구현될 수도 있다. 다른 예들에 있어서, 지오메트리 프로세싱 스테이지 (34) 는 고정 기능 하드웨어 프로세싱 파이프라인으로서, 또는 하나 이상의 쉐이더 유닛들 상에서 실행하는 하나 이상의 쉐이더 프로그램들과 고정 기능 하드웨어의 조합으로서 구현될 수도 있다.

래스터화 스테이지 (36) 는, 지오메트리 프로세싱 스테이지 (34) 로부터, 래스터화될 프리미티브를 나타내는 프리미티브 데이터를 수신하고, 그 프리미티브를 래스터화하여 래스터화된 프리미티브에 대응하는 복수의 소스 픽셀들을 생성하도록 구성된다. 일부 예들에 있어서, 래스터화 스테이지 (36) 는 어느 스크린 픽셀 위치들이 래스터화될 프리미티브에 의해 커버되는지를 결정하고, 프리미티브에 의해 커버되도록 결정된 각각의 스크린 픽셀 위치에 대한 소스 픽셀을 생성할 수도 있다. 래스터화 스테이지 (36) 는, 예를 들어, 에지 워킹 (edge-walking) 기법, 평가 에지 방정식들 등과 같이 당업자에게 공지된 기법들을 이용함으로써 어느 스크린 픽셀 위치들이 프리미티브에 의해 커버되는지를 결정할 수도 있다. 래스터화 스테이지 (36) 는 추가적인 프로세싱을 위해 결과적인 소스 픽셀들을 픽셀 프로세싱 파이프라인 (38) 에 제공할 수도 있다.

래스터화 스테이지 (36) 에 의해 생성된 소스 픽셀들은 스크린 픽셀 위치, 예를 들어, 목적지 픽셀에 대응하고, 하나 이상의 컬러 속성들과 연관될 수도 있다. 특정 래스터화된 프리미티브에 대해 생성된 소스 픽셀들 모두는 래스터화된 프리미티브와 연관되는 것으로 일컬어질 수도 있다. 프리미티브에 의해 커버되는 것으로 래스터화 스테이지 (36) 에 의해 결정되는 픽셀들은, 개념적으로, 프리미티브의 버텍스들을 나타내는 픽셀들, 프리미티브의 에지들을 나타내는 픽셀들 및 프리미티브의 내부를 나타내는 픽셀들을 포함할 수도 있다.

픽셀 프로세싱 파이프라인 (38) 은 래스터화된 프리미티브와 연관된 소스 픽셀을 수신하고 소스 픽셀에 대해 하나 이상의 픽셀 당 동작들을 수행하도록 구성된다. 픽셀 프로세싱 파이프라인 (38) 에 의해 수행될 수도 있는 픽셀 당 동작들은, 예를 들어, 알파 테스트, 텍스처 매핑, 컬러 계산, 픽셀 쉐이딩, 픽셀 당 조명, 포그 프로세싱, 블렌딩, 픽셀 소유권 텍스트, 소스 알파 테스트, 스텐실 테스트, 심도 테스트, 시저스 (scissors) 테스트, 및/또는 스티플링 동작들을 포함한다. 부가적으로, 픽셀 프로세싱 파이프라인 (38) 은 하나 이상의 픽셀 쉐이더 프로그램들을 실행하여 하나 이상의 픽셀 당 동작들을 수행할 수도 있다. 픽셀 프로세싱 파이프라인 (38) 에 의해 생성된 결과적인 데이터는 본 명세서에서 목적지 픽셀 데이터로서 지칭되고 프레임 버퍼 (15) 에 저장될 수도 있다. 목적지 픽셀 데이터는, 프로세싱되었던 소스 픽셀과 동일한 디스플레이 위치를 갖는 프레임 버퍼 (15) 내의 목적지 픽셀과 연관될 수도 있다. 목적지 픽셀 데이터는, 예를 들어, 컬러 값들, 목적지 알파 값들, 심도 값들 등과 같은 데이터를 포함할 수도 있다.

프레임 버퍼 (15) 는 GPU (12) 에 대한 목적지 픽셀들을 저장한다. 각각의 목적지 픽셀은 고유한 스크린 픽셀 위치와 연관될 수도 있다. 일부 예들에 있어서, 프레임 버퍼 (15) 는 각각의 목적지 픽셀에 대한 컬러 컴포넌트들 및 목적지 알파 값을 저장할 수도 있다. 예를 들어, 프레임 버퍼 (15) 는 각각의 픽셀에 대한 적색, 녹색, 청색, 알파 (RGBA) 컴포넌트들을 저장할 수도 있으며, 여기서, "RGB" 컴포넌트들은 컬러 값들에 대응하고 "A" 컴포넌트는 목적지 알파 값에 대응한다. 비록 프레임 버퍼 (15) 및 시스템 메모리 (10) 가 별도의 메모리 유닛들인 것으로서 도시되지만, 다른 예들에 있어서, 프레임 버퍼 (15) 는 시스템 메모리 (10) 의 부분일 수도 있다.

상기 논의된 바와 같이, 그래픽스 프로세싱 파이프라인 (30) 은 비닝 렌더링 모드 및 직접 렌더링 모드를 포함하여 특정 렌더링 모드에 따라 그래픽스 이미지를 렌더링할 수도 있다. 비닝 렌더링 모드에 따라 렌더링할 경우, 그래픽스 프로세싱 파이프라인 (30) 은 프리미티브들의 배치 (즉, 하나 이상의 프리미티브들) 를 수신하여 결과적인 그래픽스 이미지로 렌더링할 수도 있다. 프리미티브들의 배치를 렌더링하기 위하여, 결과적인 그래픽스 이미지는 복수의 더 작은 부분들 (예를 들어, 픽셀들의 타일들 또는 빈들) 로 세분될 수도 있으며, 그래픽스 프로세싱 파이프라인 (30) 은 그래픽스 이미지의 각각의 부분을 별도의 렌더링 패스로서 렌더링할 수도 있다.

도 3 은 비닝 렌더링 모드를 위한 빈들로 분할된 프레임을 도시한 개념 다이어그램이다. 프레임 (40) 은 복수의 빈들, 예컨대, 빈 (42) 으로 분할될 수도 있다. 통상적으로, 그래픽스 하드웨어는, 데이터의 적어도 하나의 빈을 유지하기에 충분한 사이즈를 갖는 고속 메모리 (예를 들어, 도 2 의 그래픽스 메모리 (14)) 를 포함할 것이다. 프레임의 특정 부분에 대한 단일 렌더링 패스의 부분으로서, 그래픽스 프로세싱 파이프라인 (30) 은 프레임의 목적지 픽셀들의 특정 서브세트 (예를 들어, 목적지 픽셀들의 특정 빈) 에 대하여 프리미티브들의 배치의 전부 또는 그 서브세트를 렌더링할 수도 있다. 제 1 빈에 대하여 제 1 렌더링 패스를 수행한 이후, 그래픽스 프로세싱 파이프라인 (30) 은 제 2 빈에 대하여 제 2 렌더링 패스를 수행하는 등등일 수도 있다. 그래픽스 프로세싱 파이프라인 (30) 은, 모든 빈과 연관된 프리미티브들이 렌더링될 때까지 빈들에 걸쳐 증분적으로 순회할 수도 있다.

도 4 는 비닝 렌더링 모드에서 사용된 빈들을 더 상세히 도시한 개념 다이어그램이다. 빈들 (44, 46, 48 및 50) 은 다중의 픽셀들 (52) 을 포함하도록 렌더링/래스터화된다. 하나 이상의 그래픽스 프리미티브들은 각각의 빈에서 가시적일 수도 있다. 예를 들어, 삼각형 A (Tri A) 의 부분들은 빈 (44) 및 빈 (48) 양자에서 가시적이다. 삼각형 B (Tri B) 의 부분들은 빈 (44), 빈 (46), 빈 (48) 및 빈 (50) 각각에서 가시적이다. 삼각형 C (Tri C) 는 오직 빈 (46) 에서만 가시적이다. 렌더링 패스 동안, 비닝 렌더링 모드의 일 예에 있어서, 장면은 빈들로 분할되고, 빈에 있는 모든 삼각형들이 렌더링된다 (이는 때때로 소프트웨어 비닝으로 지칭됨). 비닝 렌더링 모드의 다른 예에 있어서, 빈 내의 어느 삼각형들이 최종 렌더링된 장면에서 실제로 가시적인지를 결정하기 위해 렌더링 전에 부가적인 단계가 취해진다 (이는 때때로 하드웨어 비닝으로 지칭됨). 예를 들어, 일부 삼각형들은 하나 이상의 다른 삼각형들 뒤에 있을 수도 있으며, 최종 렌더링된 장면에서 가시적이지 않을 것이다. 이러한 방식으로, 가시적이지 않은 삼각형들은 그 빈에 대해 렌더링될 필요가 없다.

특정 렌더링 패스를 수행하는 동안, 그 특정 렌더링 패스와 연관된 빈에 대한 픽셀 데이터는 (때때로 빈 버퍼로서 지칭되는) 그래픽스 메모리 (14) 에 저장될 수도 있다. 렌더링 패스를 수행한 이후, 그래픽스 프로세싱 파이프라인 (30) 은 그래픽스 메모리 (14) 의 컨텐츠를 프레임 버퍼 (15) 로 이송할 수도 있다. 일부 경우들에 있어서, 그래픽스 프로세싱 파이프라인 (30) 은 프레임 버퍼 (15) 내의 데이터의 일부를 그래픽스 메모리 (14) 에 저장된 데이터로 오버라이트할 수도 있다. 다른 경우들에 있어서, 그래픽스 프로세싱 파이프라인 (30) 은 프레임 버퍼 (15) 내의 데이터를 그래픽스 메모리 (14) 에 저장된 데이터와 합성 또는 결합할 수도 있다. 그래픽스 메모리 (14) 의 컨텐츠를 프레임 버퍼 (15) 로 이송한 이후, 그래픽스 프로세싱 파이프라인 (30) 은 그래픽스 메모리 (14) 를 디폴트 값들로 초기화하고, 상이한 빈에 대한 후속 렌더링 패스를 시작할 수도 있다.

도 5 는 "소프트웨어" 비닝을 사용한 비닝 렌더링 모드를 사용하여 장면을 렌더링하기 위한 예시적인 커맨드 구조를 도시한 개념 다이어그램이다. 레벨 1 간접 버퍼 (IB1) (60) 는, 그래픽스 메모리 파이프라인 (30) 의 다양한 단계들을 수행하도록 GPU (12) 에게 지시하기 위한 실행 커맨드들의 시리즈를 포함한다. GPU (12) 가 IB1 (60) 로의 포인터를 수신하는 PM4 커맨드 패킷. IB1 (60) 에서의 각각의 실행 커맨드는 본질적으로, 렌더링 파이프라인의 다양한 양태들에 대한 커맨드들을 포함하는 하나 이상의 레벨 2 간접 버퍼들 (IB2) 로의 포인터이다. 이러한 방식으로, 2 이상의 레벨 구조가 그래픽스 렌더링 파이프라인을 실행하기 위해 확립된다. GPU (12) 는 IB1 (60) 에서의 각각의 실행 커맨드에 걸쳐 순차적으로 단계를 밟을 수도 있으며, 여기서, IB1 (60) 에서의 각각의 실행은 IB2 에 저장된 커맨드들의 특정 스택으로 포인팅한다. IB1들 및 IB2들은 GPU (12) 에 온-보드인 메모리일 수도 있거나 또는 시스템 메모리 (10) 와 같이 GPU (12) 에 대해 외부 메모리일 수도 있다.

IB1 (60) 에서의 프리앰블 실행 커맨드는, GPU (12) 에 의해 실행가능한 프리앰블 커맨드들을 포함하는 프리앰블 IB2 (62) 로 포인팅한다. 예를 들어, 프리앰블 IB2 (62) 는, GPU (12) 의 그 정적 상태를 초기화하고 GPU (12) 의 초기 렌더링 상태를 설정하는 커맨드들을 포함할 수도 있다. GPU 의 정적 상태는, 특정 어플리케이션에 기초하여 변하지 않는 설정들을 포함한다. 한편, 렌더링 상태는, 특정 어플리케이션 (예를 들어, OpenGL 어플리케이션 대 다이렉트 X 어플리케이션) 에 기초하여 변할 수도 있는 GPU 설정들을 포함한다. 프리앰블 IB2 에서의 커맨드들이 완료된 이후, 제어는 IB1 (60) 로 리턴하여 다음 실행 커맨드를 수행한다.

IB1 (60) 에서의 다음 실행 커맨드는 채용되는 렌더링 모드에 대한 렌더 패스를 구성한다. 다시, 도 5 의 예에 있어서, 렌더링 모드는 소프트웨어 비닝을 사용한 비닝 렌더링 모드이다. 다음으로, IB1 에서의 로드 빈 실행 커맨드는 BLT (블록 이송, 즉, 데이터 카피) IB2 (64) 에서의 비동기 블리팅 (blitting) 커맨드들로 포인팅한다. 블리팅 커맨드들은, 일부 예들에 있어서, 수개의 비트맵들을 래스터 오퍼레이터를 사용한 하나의 비트맵으로 결합할 수도 있다. 도 5 의 예에 있어서, 블리팅은 프리앰블에서 생성된 그래픽스 커맨드들 또는 상태를 결합하거나 수정할 수도 있다. 다음으로, IB1 (60) 에서의 로드 빈 실행 커맨드는 로드 IB2 (66) 에서의 커맨드들로 포인팅한다. 소프트웨어 비닝에 대해, 특정 빈에 대한 데이터는 GMEM (14) 에 로딩된다 (로드 2 GMEM). 그후, 제어는 IB1 (60) 로 다시 전달되고, 렌더 빈 실행 커맨드는 렌더링 IB2 에서의 커맨드들로 포인팅한다. 렌더링 IB2 (68) 는 로딩된 빈에서 삼각형들을 묘화하기 위한 묘화 커맨드들 및 상태 커맨드들의 시리즈로 이루어진다. 각각의 묘화 커맨드는 커맨드들 및/또는 GPU 하드웨어에 의해 확립된 (예를 들어, 지오메트리 프로세싱 스테이지 (34), 래스터화 상태 (36), 및/또는 픽셀 프로세싱 파이프라인 (38) 을 포함한) 그래픽스 프로세싱 파이프라인 (30) 에 따라 삼각형을 묘화하도록 GPU (12) 에게 지시한다. 렌더링 IB2 (68) 에 도시된 바와 같이, 묘화 커맨드들 각각은, 특정 삼각형들이 빈에서 실제로 가시적인지를 결정하기 위해 어떠한 가시성 스트림도 사용되지 않음을 표시한다. 가시성 스트림들은 "하드웨어" 비닝을 사용하는 비닝 렌더링 모드에서 생성되며, 도 6 을 참조하여 더 상세히 논의될 것이다. 렌더링 IB2 (68) 에서의 상태 커맨드들은 GPU (12) 에 의해 실행된 그래픽스 프로세싱 파이프라인의 거동에 영향을 준다. 예를 들어, 상태 커맨드들은 컬러, 다각형 모드 (예를 들어, 솔리드들 또는 라인들 대신 포인트들), 블렌딩 (온/오프), 심도 테스팅 (온/오프), 텍스처링 (온/오프), 컬링, 클리핑, 및 다른 논리 연산들을 변경할 수도 있다. 렌더링 IB2 (68) 에 도시된 바와 같이, 상태 커맨드들은 삼각형 당 (또는 프리미티브 당) 기반으로 발행될 수도 있다. 즉, 커맨드 "상태 Tri A" 는 삼각형 A 를 묘화할 경우에 GPU (12) 의 거동에 영향을 줄 수도 있는 한편, "상태 Tri B1" 및 "상태 Tri B2" 커맨드들은 삼각형 B 를 묘화할 경우에 GPU (12) 의 거동에 영향을 줄 수도 있다. "상태 Tri B1" 및 "상태 Tri B2" 커맨드들은 단지, 다중의 상태 커맨드들이 각각의 삼각형에 대해 실행될 수도 있음을 표시할 뿐이다.

모든 커맨드가 렌더링 IB2 (68) 에서 실행된 이후 (예를 들어, 모든 삼각형들이 묘화된 이후), 제어는 IB1 (60) 로 리턴한다. 저장 빈 실행 커맨드는, 렌더링된 빈을 GMEM (14) 으로부터 메모리 (예를 들어, 프레임 버퍼 (15)) 에 저장하기 위한 커맨드를 포함하는 저장 IB2 (70) 로의 포인터들을 포함할 수도 있다. 그 후, 렌더 패스 (예를 들어, IB1 (60) 에 도시된 바와 같이 구성 렌더 패스로부터 저장 빈으로의 실행 커맨드들) 가 하나 이상의 프레임들에 대한 각각의 빈 (72) 에 대해 반복된다.

도 6 은 "하드웨어" 비닝을 사용한 비닝 렌더링 모드를 사용하여 장면을 렌더링하기 위한 예시적인 커맨드 구조를 도시한 개념 다이어그램이다. IB1 (61) 에서의 실행 커맨드들은, "비닝" 패스에 관련된 커맨드들을 제외하면 도 6 의 IB1 (60) 의 실행 커맨드들과 유사하다. "비닝" 패스는, 빈 내의 특정 삼각형들이 최종 렌더링된 장면에서 실제로 가시적인지 여부를 표시하는 가시성 스트림을 생성하기 위해 사용된다. 예를 들어, 일부 삼각형들은, 일부 시나리오들에 있어서, (예를 들어, 정면의 삼각형이 불투명한 경우 또는 어떠한 블렌딩도 사용되지 않은 경우) 장면에서 다른 삼각형 뒤에 있을 수도 있으며, 가시적이지 않을 것이다. 렌더링 빈들 (72) 전에, IB1 (61) 은, 비닝 IB2 (74) 에서의 커맨드들로 포인팅하는 비닝 패스 실행 커맨드를 포함할 수도 있다. 비닝 IB2 (74) 는 GPU (12) 로 하여금 그래픽스 파이프라인의 단순화된 버전 (예를 들어, 렌더링 IB2 (69) 의 단순화된 버전) 을 수행하게 하는 커맨드들을 포함하지만, 삼각형이 최종 렌더링된 장면에서 가시적인지 여부를 결정하는 심도 테스트 (Z 테스트) 에 기초하여 빈 내의 각각의 삼각형에 대한 가시성 스트림을 업데이트하는 단계를 부가한다.

비닝 패스의 목적은 현재 빈을 교차하는 삼각형들을 식별하는 것이다. 이에 따라, 오직 삼각형의 버텍스들의 포지션만이 삼각형이 특정 빈을 교차하는지를 식별하기 위해 결정될 필요가 있다. 비닝 패스는, 오직 버텍스들의 포지션에 영향을 주는 명령들만을 포함하는 단순화된 버텍스 쉐이더를 활용한다. 예를 들어, 컬러 명령들, 텍스처 좌표들 및 삼각형 버텍스의 포지션에 영향을 주지 않는 다른 명령들은 비닝 패스를 위해 사용된 단순화된 버텍스 쉐이더로부터 제거될 수도 있다. 비닝 패스는 또한, 정밀한 래스터화보다는 대략적 (coarse) 래스터화를 사용하여 각각의 삼각형의 근사적인 심도를 결정한다. 대략적 래스터화는 정밀한 래스터화보다 더 낮은 정밀도로 (예를 들어, 더 적은 수의 비트들을 사용하여) 심도 값을 계산한다. 오직 근사적인 심도 값들만이 삼각형이 빈에서 가시적인지를 결정하기 위해 필요하다. 픽셀 쉐이더들은 비닝 패스에서 사용되지 않는다.

그 후, 비닝 패스는 대략적 심도 값들에 대한 심도 테스트를 활용하여, 삼각형이 빈 내의 다른 삼각형들에 대해 빈에서 가시적인지를 결정한다. 이러한 심도 테스트에 기초하여, 가시성 스트림이 업데이트된다. 가시성 스트림은, 렌더링된 빈 내의 특정 삼각형이 가시적인지 여부를 표시하는 비트들의 스트링일 수도 있다 (예를 들어, 1 은 삼각형이 가시적임을 표시하고 0 은 삼각형이 가시적이지 않음을 표시함).

렌더링 IB2 (69) 에서의 커맨드들은 도 5 에서의 렌더링 IB (68) 의 커맨드들과 유사하지만 가시성 스트림의 사용에 대한 것이다. 렌더링 IB2 (69) 에서의 묘화 커맨드들 (예를 들어, Tri A 묘화, Tri B 묘화, Tri C 묘화 등) 은 비닝 패스에 의해 생성된 가시성 스트림을 사용하여, 특정 삼각형을 묘화할 필요가 있는지 여부를 결정할 수도 있다. 예를 들어, 묘화는 가시성 스트림에 의해 가시적이지 않은 것으로서 표시된 삼각형들에 대해 스킵될 수도 있다.

비닝 렌더링 모드에서와 같이 프레임을 빈 단위로 렌더링하는 것에 반대로, 직접 렌더링은 그래픽스 파이프라인을 통해 하나의 패스에서 전체 프레임을 렌더링한다. 직접 렌더링은, 통상적으로, 제한된 양의 그래픽스 메모리로 비닝 기반 아키텍처들에서 실행될 경우 더 느린 시스템 메모리를 활용한다.

도 7 는 직접 렌더링 모드를 사용하여 장면을 렌더링하기 위한 예시적인 커맨드 구조를 도시한 개념 다이어그램이다. 직접 렌더링 모드에 대한 커맨드들은 도 5 에서의 소프트웨어 비닝에 대한 커맨드들과 유사하지만, 빈 단위 기반으로 렌더링하는 대신, 전체 프레임이 하나의 패스에서 렌더링된다. 예를 들어, IB1 (80) 에서의 실행 커맨드들은 IB1 (60) 에서의 커맨드들과 유사하지만, 빈들을 로딩, 렌더링, 및 저장하기 보다는, IB1 (80) 에서의 실행 커맨드들은, 저장 프레임들을 렌더링하는 개별 IB2들에서의 커맨드들로 포인팅한다. IB1 (80) 의 비동기 블리팅 커맨드들은 BLT IB2 (84) 에서의 비동기 블리팅 커맨드들로 포인팅한다. 더 구체적으로, IB1 (80) 에서의 커맨드들은 프리앰블, 프리앰블/복원, 구성 렌더 패스, 및 렌더 프레임을 포함할 수도 있다. IB1 (80) 에서의 렌더 프레임 실행 커맨드는, GPU (12) 로 하여금 프레임에서의 프리미티브들을 묘화하게 하는 명령들을 포함하는 렌더링 IB2 (88) 로 포인팅한다. 소프트웨어 비닝과 유사하게, 직접 렌더링 모드에서의 렌더링은 하드웨어 비닝 패스 또는 가시성 스트림을 이용하지 않는다. 렌더링 IB2 (88) 에서의 임의의 묘화 커맨드들 (예를 들어, Tri A 묘화, Tri B 묘화, Tri C 묘화) 은 GMEM 메모리를 활용하여 렌더링된 삼각형들을 저장할 것이다.

IB1 (80) 에서의 프리앰블 실행 커맨드는, GPU (12) 의 정적 상태 및 초기 렌더링 상태를 확립하기 위한 명령들을 포함하는 프리앰블 IB2 (82) 로 포인팅한다. 이들 커맨드들은 도 6 의 프리앰블 IB2 (62) 에서의 커맨드들과 유사하게 작용하지만, 비닝 렌더링 모드보다는 직접 렌더링 모드에 대해 렌더링 상태를 셋업한다.

도 5 내지 도 7 에 도시된 바와 같이, 직접 모드 렌더링 및 비닝 모드 렌더링 양자가 IB2들을 활용한다. 렌더링 패스 또는 렌더링 루프 동안, GPU (12) 는 렌더링될 장면에 관한 정보에 기초하여 비닝을 위해 그리고 동적 펀팅 (punting) 로직을 위해 렌더링 IB2들에 걸쳐 루핑한다. 이전 기법들에 있어서는, GPU (12) 이외의 프로세서 상에서 실행하는 구동기 (예를 들어, CPU (6) 상에서 실행하는 GPU 구동기 (7)) 가, 프레임의 일부를 렌더링할 경우에 직접 렌더링 모드를 활용할지 또는 비닝 렌더링을 활용할지를 결정하는 것을 책임졌다. CPU (6) 를 활용하여 장면을 렌더링하기 위해 직접 모드를 사용할지 또는 렌더링 모드를 사용할지를 결정할 경우, 프로세스는 극도로 CPU 한정적일 수도 있다 (즉, CPU (6) 의 상대적으로 높은 활용도를 가질 수도 있음). GPU (12) 가 직접 모드 렌더링을 활용할지 또는 비닝 모드 렌더링을 활용할지를 결정할 경우, 그 결과는 또한, 직접 모드 렌더링과 비닝 모드 렌더링 간의 능력 디스패리티들에 의존할 수도 있다.

본 개시의 기법들에 따르면, GPU (12) 는, 예를 들어, CPU (6) 상에서 실행하는 GPU 구동기 (7) 로부터 GPU 커맨드 패킷을 수신할 수도 있다. 커맨드 패킷은 GPU (12) 가 GPU (12) 에 의해 렌더링될 프레임의 일부를 렌더링하기 위해 직접 렌더링 또는 비닝 모드 렌더링 중 어느 하나를 활용할 수도 있다. 부가적으로, 커맨드 패킷은 구성 정보를 캡슐화할 수도 있다. 커맨드 패킷은 또한, 일부 예들로서 IB2들 (82, 84, 86, 88, 및 90) 과 같이 직접 모드 렌더링 및/또는 하드웨어 및/또는 비닝 렌더링을 위해 하나 이상의 IB2들을 참조 (또는 포인팅) 할 수도 있다.

어플리케이션 (예를 들어, 도 2 의 소프트웨어 어플리케이션 (24)) 이 장면을 렌더링하기 시작하기 전, GPU (12) 는 커맨드 패킷에 포함된 장면 정보에 기초하여 렌더링 모드를 결정 (예를 들어, 비닝 렌더링과 직접 렌더링 사이에서 결정) 할 수도 있다. GPU (12) 는 또한, GPU 상태 휴리스틱들에 기초하여 직접 렌더링을 사용할지 또는 비닝을 사용할지를 결정할 수도 있다. 일부 기법들에 있어서, GPU (12) 는 또한, 이전 렌더링 패스들로부터의 데이터에 기초하여 렌더링 모드를 결정할 수도 있다. 하지만, 어플리케이션이 새로운 장면을 렌더링하기 전에 렌더링 기법들을 스위칭할 수도 있기 때문에, 이러한 기법은 렌더링 모드를 결정하기 위한 항상 최적의 방식은 아닐 수도 있다. 그에 따라, 이 기법은, 적당한 렌더링 모드로 스위칭하기 위해 충분한 새로운 데이터가 누적될 때까지는 비효율적인 렌더링으로 안내할 수도 있다.

부가적으로, 과거 렌더링들에 관한 휴리스틱 데이터는, 현재 장면이 이전 장면들과는 상이하다면, 현재 장면에 대해 가장 최적의 렌더링 모드를 항상 제공하지는 않을 수도 있다. 예를 들어, 신속하게 변하는 렌더링 모드들을 최적으로 사용할 어플리케이션은 다수의 잘못된 예측들로 안내할 수도 있다. 본 개시의 기법들에 따르면, GPU (12) 는 GPU (12) 의 전력 사용을 결정할 수 있으며, 전력 사용에 기초하여 렌더링 모드를 결정할 수도 있다. 본 개시의 기법들에 따른 다른 예에 있어서, GPU (12) 는 GPU (12) 의 현재 또는 장래 활용도를 결정할 수도 있으며, GPU (12) 의 현재 또는 장래 활용도에 기초하여 프레임의 적어도 일부를 렌더링하기 위해 사용할 렌더링 모드를 결정할 수도 있다. 본 개시의 기법들에 따르면, GPU (12) 는 본 명세서에서 구체적으로 설명되지 않은 다른 휴리스틱들을 사용할 수도 있으며, GPU (12) 는 CPU (6) 로부터의 개입 또는 간섭없이 본 명세서에서 설명된 임의의 휴리스틱들을 실행할 수도 있다.

다음의 기법들은 임의의 그래픽스 어플리케이션 프로그램 인터페이스 (API) 를 사용하는 그래픽스 프로세싱 시스템에 적용가능하며, 특히, 비닝 렌더링을 활용하는 그래픽스 API들에 적합하다. 그러한 API들의 예들은 마이크로소프트의 다이렉트X9 (DX9), DX10, 및 DX11, DX12 뿐 아니라 OpenGL 및 OpenGL ES 와 같은 오픈 소스 그래픽스 API들, 및 OpenCL 및 DirectCompute 와 같은 컴퓨팅 API들을 포함한다.

도 8 은 상이한 렌더링 모드들에 대한 커맨드 버퍼들의 개념 다이어그램이다. 도 8 은 IB1 (100), IB1 (102), 및 IB1 (104) 을 포함한다. IB1들 (100, 102, 및 104) 각각은, 특정 렌더링 모드에 대응하는 IB1 버퍼들을 포함할 수도 있다. 각각의 IB1 은 하드웨어 비닝에 대한 커맨드 버퍼에 대응할 수도 있다. IB1 (102) 은 소프트웨어 비닝에 대한 버퍼에 대응할 수도 있고, IB1 은 직접 모드 렌더링에 대한 버퍼에 대응할 수도 있다. 도 8 에 도시된 기법들에 따르면, 상이한 렌더링 모드를 활용하기 위하여, GPU (12) 는 상이한 IB1 로부터 판독하여야 하며, 이는 다중의 IB1들을 GPU (12) 로 이송하도록 GPU 구동기 (7) 에게 요구할 수도 있다. 부가적으로, GPU (12) 는 다중의 IB1들을 저장하도록 요구될 수도 있으며, 이는 GPU (12) 의 부가적인 메모리를 소비한다. 본 개시의 기법들은, 도 8 에 관하여 도시된 기법들과 달리, 다중의 IB1들에게 GPU1 으로 이송되도록 요구하지 않는다.

도 9 는 본 개시의 기법들에 따른 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 장면을 렌더링하기 위한 예시적인 커맨드 구조를 도시한 개념 다이어그램이다. 도 9 의 예에 있어서, GPU 구동기 (7) 또는 GPU (12) 는 IB1 (120) 을 생성 또는 수신할 수도 있다. IB1 (120) 은 도 5 내지 도 7 에 관하여 설명된 다른 IB1들과 유사하다. 하지만, 본 개시의 기법들에 따르면, IB1 (120) 은, PM4 장면 디스크립터를 포함할 수도 있는 커맨드 패킷을 포함한다.

도 9 의 예에 있어서, IB1 (120) 은 호출 비닝 IB2 (132) 뿐 아니라 프리앰블 IB2 (122), BLT IB2 (124), 및 렌더링 IB2 (128), 그리고 저장 IB2 (130) 를 참조 (또는 포인팅) 한다. IB1 (120) 의 GPU 커맨드 패킷, 예를 들어, PM4 장면 디스크립터는 전술한 IB2들을 캡슐화할 수도 있어서, GPU (12) 가 다양한 휴리스틱들에 기초하여 하드웨어 비닝, 소프트웨어 비닝, 또는 직접 모드 렌더링을 수행할 수 있다. IB1 (120) 의 PM4 장면 디스크립터는 그 IB2들의 메모리 어드레스들을 참조함으로써 IB2들 (122, 123, 126, 128, 130, 및 132) 을 참조한다. 하지만, PM4 디스크립터 (120) 는 반드시 IB2들 (122, 124, 126, 128, 130, 및 132) 을 포함해야 하는 것은 아니다. GPU (12) 는, PM4 장면 디스크립터가 실행 순서, 예를 들어, 도 5 내지 도 7 에 도시된 렌더링 모드들 중 하나와 유사한 실행 순서를 생성하도록 참조하는 IB2들을 사용할 수도 있다.

장면 디스크립터를 커맨드 패킷에 포함하고 GPU (12) 로 하여금 프레임의 부분들에 대한 렌더링 모드를 결정하게 함으로써, 본 개시의 기법들은 다중의 이점들을 제공한다. 직접 모드 렌더링과 비닝 모드 렌더링 사이에서 스위칭하기 위한 이전 기술은 다중의 IB2들의 생성을 요구하였고, 구동기 기반 휴리스틱들에 기초하여 (예를 들어, "훅" 기반 함수 호출들보다는 그래픽스 API 제공 함수 호출들에 의존하여) 비닝 및 동적 펀팅 로직을 위해 렌더링 IB2들에 걸친 루핑을 요구하였다. 생성, 반복, 및 구동기 기반 휴리스틱들 그리고 훅 로직은 모두 극도로 CPU 한정적이다 (즉, 현저한 CPU 리소스들을 소비함).

도 9 에 도시된 PM4 장면 디스크립터는 GPU (12) 로 하여금 상이한 렌더링 모드들을 조건부로 트리거하게 하고, GPU (12) 로 하여금 렌더링 모드 판정 메커니즘에서 여분의 GPU 상태 특정 휴리스틱들을 통합하게 한다. 일 예에 있어서, CPU (6) 는 장면 디스크립터 휴리스틱들을 PM4 디스크립터에 포함할 수도 있다. GPU (12) 는 렌더링 모드를 결정하기 위해 PM4 디스크립터에 포함된 휴리스틱들을 평가할 수도 있다. 다른 예에 있어서, GPU (12) 는, 일부 예들에 있어서 전력 상태, 메모리 사용, 및/또는 렌더링 부하를 포함할 수도 있는 GPU 하드웨어 상태 분석에 기초하여 렌더링 모드를 결정할 수도 있다. 다른 예에 있어서, 휴리스틱들은, 상이한 하드웨어 능력들을 갖는 GPU들이 장면들을 상이하게 렌더링할 수 있도록 GPU (12) 의 하드웨어 능력들을 결정하는 것을 포함할 수도 있다. 부가적으로, 결정된 휴리스틱들은 다른 GPU 성능 쿼리들 뿐 아니라 본 명세서에서 명시적으로 개시되지 않은 실행 시의 상태 결정들을 포함할 수도 있다. 본 개시의 기법들은 또한, 펀팅 (즉, 비닝 모드로부터 직접 렌더링 모드로 스위칭할 때를 결정하는 것) 및 렌더링 로직을 CPU (6) 및/또는 GPU 구동기 (7) 로부터 GPU (12) 로 이동한다.

부가적으로, GPU 렌더링 모드 판정을 GPU (12) 로 이동하는 것은 CPU (6) 로부터의 오버헤드를 제거하고, 메모리 풋프린트를 감소하며, 큐잉된 그래픽스 커맨드들을 제출하는데 사용된 IB1 커맨드 공간을 절약한다. 부가적으로, GPU 기반 또는 GPU 보조 휴리스틱들은 동적 펀팅 프로세스를 갖는 CPU (6) 및/또는 GPU 구동기 (7) 로부터의 상호작용없이 GPU (12) 상에서 수행되거나 내장될 수도 있다. 본 개시의 기법들은 또한, CPU 집중형일 수도 있는 다수의 작은 렌더링 호출들을 배치함으로써 야기되는 소위 "소형 배치" 문제와 연관된 성능 페널티들을 감소시킨다.

도 10 은 본 개시의 일 예에 따른 방법을 도시한 플로우차트이다. 도 10 의 방법은 컴퓨팅 디바이스 (2) 상에 상주하는 GPU (12) 에 의해 및/또는 임의의 다른 하드웨어, 펌웨어, 소프트웨어 엘리먼트, 또는 이들의 조합에 의해 수행될 수도 있다. CPU (6) 는 IB1 과 같은 프레임을 렌더링하기 위한 렌더링 커맨드들을 생성하도록 구성될 수도 있다. CPU (6) 는 GPU 커맨드 패킷을 GPU (12) 로 송신할 수도 있다. 다양한 예들에 있어서, 커맨드 패킷은 PM4 포맷 커맨드 패킷을 포함할 수도 있다.

GPU (12) 는 CPU (6) 로부터 커맨드 패킷을 수신할 수도 있다. 커맨드 패킷은 GPU (12) 가 GPU (12) 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수도 있음을 표시할 수도 있다 (160). GPU (12) 는 수신된 커맨드 패킷에서의 정보 또는 GPU (12) 의 상태 중 적어도 하나에 기초하여 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정하고 (162), 결정된 직접 렌더링 모드 또는 비닝 렌더링 모드를 사용하여 프레임의 일부를 렌더링할 수도 있다 (164). 다양한 예들에 있어서, 프레임의 일부를 렌더링하기 위하여, GPU (12) 는 렌더링 루프를 통해 반복하고/하거나 동적 펀팅을 수행할 수도 있다.

다양한 예들에 있어서, 직접 렌더링 모드를 활용할지 또는 비닝 렌더링 모드를 활용할지를 결정하기 위하여, GPU (12) 는 휴리스틱을 실행하여 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드를 활용할지 또는 비닝 렌더링 모드를 활용할지를 결정할 수도 있다. 일부 예들에 있어서, GPU (12) 는 GPU (12) 의 전력 소비에 기초하여 직접 렌더링 모드를 활용할지 또는 비닝 렌더링 모드를 활용할지를 결정할 수도 있다. GPU (12) 는 또한, GPU (12) 의 일부 리소스 활용도에 기초하여 직접 렌더링 모드를 활용할지 또는 빈 렌더링 모드를 활용할지를 결정할 수도 있다.

다양한 예들에 있어서, 커맨드 패킷은, 간접 버퍼 (IB2) 정보 및/또는 구성 쌍들과 같이, 렌더링될 프레임을 렌더링하는데 요구된 정보를 캡슐화하는 장면 디스크립터 패킷을 포함할 수도 있다. 장면 디스크립터의 캡슐화된 정보는, 프레임이 속하는 장면에 관한 해상도 정보를 더 포함할 수도 있다.

일부 예들에 있어서, GPU 상태는 GPU 의 전력 소비를 포함할 수도 있으며, GPU (12) 는 추가로, GPU 의 전력 소비가 임계 전력 소비 값을 초과할 경우에 프레임의 일부를 렌더링하기 위해 비닝 렌더링 모드를 사용하도록 결정할 수도 있다. GPU 상태는 또한 GPU 의 활용도 부하를 포함할 수도 있으며, GPU (12) 는, GPU 의 활용도 부하가 활용도 값을 초과할 경우에 비닝 렌더링 모드를 사용하도록 결정하는 것을 결정할 수도 있다. GPU 상태는 또한 GPU 의 메모리 사용을 포함할 수도 있다.

다양한 예들에 있어서, 수신된 커맨드 패킷은, 렌더링될 프레임을 렌더링하는데 요구된 정보를 캡슐화하는 장면 디스크립터 패킷을 포함할 수도 있다. 장면 디스크립터의 캡슐화된 정보는, 일부 예들에 있어서, 간접 버퍼 정보 및 구성 쌍들을 포함할 수도 있다. 장면 디스크립터의 캡슐화된 정보는 또한, 렌더링될 프레임에 관한 해상도 정보를 포함할 수도 있다.

다양한 예들에 있어서, 수신된 커맨드 패킷에서의 정보는, 렌더링될 프레임의 일부에서의 지오메트리의 양을 포함할 수도 있다. 수신된 커맨드 패킷은 또한, GPU 에 의해 렌더링될 프레임을 렌더링하는데 요구된 빈들 모두를 포함할 수도 있다. 일부 예들에 있어서, GPU (12) 는 GPU 에 의해 이전에 렌더링된 프레임으로부터의 렌더링 정보에 기초하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정할 수도 있다.

일부 예들에 있어서, GPU (12) 는 추가로, 프레임을 렌더링할 경우에 발생할 오버드로우의 양을 결정하도록 구성될 수도 있다. GPU (12) 는, 발생할 오버드로우의 양에 기초하여 직접 렌더링 모드를 사용할지 또는 비닝 렌더링 모드를 사용할지를 결정할 수도 있다.

하나 이상의 예들에 있어서, 상기 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합에서 구현될 수도 있다. 소프트웨어에서 구현된다면, 그 기능들은, 비-일시적인 컴퓨터 판독가능 매체를 포함하는 제조 물품 상에 하나 이상의 명령들 또는 코드로서 저장될 수도 있다. 컴퓨터 판독가능 매체들은 컴퓨터 데이터 저장 매체들을 포함할 수도 있다. 데이터 저장 매체들은 본 개시에서 설명된 기법들의 구현을 위한 명령들, 코드 및/또는 데이터 구조들을 취출하기 위해 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 가용 매체들일 수도 있다. 한정이 아닌 예로서, 그러한 컴퓨터 판독가능 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 저장부, 자기 디스크 저장부 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 수록 또는 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 본 명세서에서 사용된 바와 같은 디스크 (disk) 및 디스크 (disc) 는 컴팩트 디스크 (CD), 레이저 디스크, 광학 디스크, 디지털 다기능 디스크 (DVD), 플로피 디스크 및 블루레이 디스크를 포함하며, 여기서, 디스크 (disk) 는 통상적으로 데이터를 자기적으로 재생하지만 디스크 (disc) 는 레이저를 이용하여 데이터를 광학적으로 재생한다. 상기의 조합들이 또한, 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.

그 코드는 하나 이상의 DSP들, 범용 마이크로 프로세서들, ASIC들, FPGA들, 또는 다른 균등한 집적된 또는 별개의 로직 회로부와 같은 하나 이상의 프로세서들에 의해 실행될 수도 있다. 부가적으로, 일부 양태들에 있어서, 본 명세서에서 설명된 기능은 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공될 수도 있다. 또한, 그 기법들은 하나 이상의 회로들 또는 로직 엘리먼트들에서 완전히 구현될 수 있다.

본 개시의 기법들은 무선 핸드셋, 집적 회로 (IC) 또는 IC들의 세트 (예를 들어, 칩 세트) 를 포함하여 매우 다양한 디바이스들 또는 장치들에서 구현될 수도 있다. 다양한 컴포넌트들, 모듈들 또는 유닛들이 개시된 기법들을 수행하도록 구성된 디바이스들의 기능적 양태들을 강조하기 위해 본 개시에서 설명되지만, 반드시 상이한 하드웨어 유닛들에 의한 실현을 요구하지는 않는다. 오히려, 상기 설명된 바와 같이, 다양한 유닛들은 적합한 소프트웨어 및/또는 펌웨어와 함께 상기 설명된 바와 같은 하나 이상의 프로세서들을 포함하여 코덱 하드웨어 유닛으로 결합되거나 또는 상호운용식 하드웨어 유닛들의 집합에 의해 제공될 수도 있다.

다양한 예들이 설명되었다. 이들 및 다른 예들은 다음의 청구항들의 범위 내에 있다.

Claims (30)

1. 그래픽스 프로세싱의 방법으로서,
   그래픽스 프로세싱 유닛 (GPU) 에 의해, 상기 GPU 가 상기 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수 있음을 표시하는 GPU 커맨드 패킷을 수신하는 단계;
   상기 GPU 에 의해, 수신된 상기 커맨드 패킷에서의 정보 또는 상기 GPU 의 상태 중 적어도 하나에 기초하여 상기 GPU 에 의해 렌더링될 상기 프레임의 상기 일부에 대하여 상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 단계; 및
   상기 GPU 에 의해, 결정된 상기 직접 렌더링 모드 또는 상기 비닝 렌더링 모드를 사용하여 상기 프레임의 상기 일부를 렌더링하는 단계를 포함하는, 그래픽스 프로세싱의 방법.
2. 제 1 항에 있어서,
   GPU 상태는 상기 GPU 의 전력 소비를 포함하는, 그래픽스 프로세싱의 방법.
3. 제 2 항에 있어서,
   상기 GPU 의 전력 소비가 임계 전력 소비 값을 초과할 경우에 상기 프레임의 상기 일부를 렌더링하기 위해 상기 비닝 렌더링 모드를 사용하도록 결정하는 단계를 더 포함하는, 그래픽스 프로세싱의 방법.
4. 제 1 항에 있어서,
   GPU 상태는 상기 GPU 의 활용도 부하를 포함하는, 그래픽스 프로세싱의 방법.
5. 제 4 항에 있어서,
   상기 GPU 의 활용도 부하가 활용도 값을 초과할 경우에 상기 비닝 렌더링 모드를 사용하도록 결정하는 단계를 더 포함하는, 그래픽스 프로세싱의 방법.
6. 제 1 항에 있어서,
   GPU 상태는 상기 GPU 의 메모리 사용을 포함하는, 그래픽스 프로세싱의 방법.
7. 제 1 항에 있어서,
   수신된 상기 커맨드 패킷은, 렌더링될 상기 프레임을 렌더링하는데 요구된 정보를 캡슐화하는 장면 디스크립터 패킷을 포함하는, 그래픽스 프로세싱의 방법.
8. 제 7 항에 있어서,
   장면 디스크립터의 캡슐화된 정보는 간접 버퍼 정보 및 구성 쌍들을 포함하는, 그래픽스 프로세싱의 방법.
9. 제 7 항에 있어서,
   장면 디스크립터의 캡슐화된 정보는 렌더링될 상기 프레임에 관한 해상도 정보를 포함하는, 그래픽스 프로세싱의 방법.
10. 제 1 항에 있어서,
    수신된 상기 커맨드 패킷에서의 정보는, 렌더링될 상기 프레임의 상기 일부에서의 지오메트리의 양을 포함하는, 그래픽스 프로세싱의 방법.
11. 제 1 항에 있어서,
    수신된 상기 커맨드 패킷은 상기 GPU 에 의해 렌더링될 상기 프레임을 렌더링하는데 요구된 빈들 모두를 포함하는, 그래픽스 프로세싱의 방법.
12. 제 1 항에 있어서,
    상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 단계는 상기 GPU 에 의해 이전에 렌더링된 프레임으로부터의 렌더링 정보에 기초하는, 그래픽스 프로세싱의 방법.
13. 제 1 항에 있어서,
    상기 프레임을 렌더링할 경우에 발생할 오버드로우 (overdraw) 의 양을 결정하는 단계를 더 포함하고,
    상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 단계는 발생할 상기 오버드로우의 양에 기초하는, 그래픽스 프로세싱의 방법.
14. 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스로서,
    상기 GPU 는
    메모리; 및
    적어도 하나의 프로세서를 더 포함하고,
    상기 적어도 하나의 프로세서는,
    상기 GPU 가 상기 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수 있음을 표시하는 GPU 커맨드 패킷을 수신하고;
    수신된 상기 커맨드 패킷에서의 정보 또는 상기 GPU 의 상태 중 적어도 하나에 기초하여 상기 GPU 에 의해 렌더링될 상기 프레임의 상기 일부에 대하여 상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하고; 그리고
    결정된 상기 직접 렌더링 모드 또는 상기 비닝 렌더링 모드를 사용하여 상기 프레임의 상기 일부를 렌더링하도록
    구성되는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
15. 제 14 항에 있어서,
    GPU 상태는 상기 GPU 의 전력 소비를 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
16. 제 15 항에 있어서,
    상기 적어도 하나의 프로세서는 추가로,
    상기 GPU 의 전력 소비가 임계 전력 소비 값을 초과할 경우에 상기 프레임의 상기 일부를 렌더링하기 위해 상기 비닝 렌더링 모드를 사용하도록 결정하기 위해
    구성되는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
17. 제 14 항에 있어서,
    GPU 상태는 상기 GPU 의 활용도 부하를 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
18. 제 17 항에 있어서,
    상기 적어도 하나의 프로세서는 추가로,
    상기 GPU 의 활용도 부하가 활용도 값을 초과할 경우에 상기 비닝 렌더링 모드를 사용하도록 결정하기 위해
    구성되는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
19. 제 14 항에 있어서,
    GPU 상태는 상기 GPU 의 메모리 사용을 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
20. 제 14 항에 있어서,
    수신된 상기 커맨드 패킷은, 렌더링될 상기 프레임을 렌더링하는데 요구된 정보를 캡슐화하는 장면 디스크립터 패킷을 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
21. 제 20 항에 있어서,
    장면 디스크립터의 캡슐화된 정보는 간접 버퍼 정보 및 구성 쌍들을 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
22. 제 20 항에 있어서,
    장면 디스크립터의 캡슐화된 정보는 렌더링될 상기 프레임에 관한 해상도 정보를 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
23. 제 14 항에 있어서,
    수신된 상기 커맨드 패킷에서의 정보는, 렌더링될 상기 프레임의 상기 일부에서의 지오메트리의 양을 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
24. 제 14 항에 있어서,
    수신된 상기 커맨드 패킷은 상기 GPU 에 의해 렌더링될 상기 프레임을 렌더링하는데 요구된 빈들 모두를 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
25. 제 14 항에 있어서,
    상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 것은 상기 GPU 에 의해 이전에 렌더링된 프레임으로부터의 렌더링 정보에 기초하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
26. 제 14 항에 있어서,
    상기 적어도 하나의 프로세서는 추가로,
    상기 프레임을 렌더링할 경우에 발생할 오버드로우의 양을 결정하도록 구성되고,
    상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 것은 발생할 상기 오버드로우의 양에 기초하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
27. 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스로서,
    상기 GPU 는
    상기 GPU 가 상기 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수 있음을 표시하는 GPU 커맨드 패킷을 수신하는 수단;
    수신된 상기 커맨드 패킷에서의 정보 또는 상기 GPU 의 상태 중 적어도 하나에 기초하여 상기 GPU 에 의해 렌더링될 상기 프레임의 상기 일부에 대하여 상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하는 수단; 및
    결정된 상기 직접 렌더링 모드 또는 상기 비닝 렌더링 모드를 사용하여 상기 프레임의 상기 일부를 렌더링하는 수단을 더 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
28. 제 27 항에 있어서,
    GPU 상태는 상기 GPU 의 전력 소비를 포함하고,
    렌더링 모드를 결정하는 수단은
    상기 GPU 의 전력 소비가 임계 전력 소비 값을 초과할 경우에 상기 프레임의 상기 일부를 렌더링하기 위해 상기 비닝 렌더링 모드를 사용하도록 결정하는 수단을 더 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
29. 제 27 항에 있어서,
    GPU 상태는 상기 GPU 의 활용도 부하를 포함하고,
    렌더링 모드를 결정하는 수단은
    상기 GPU 의 활용도 부하가 활용도 값을 초과할 경우에 상기 비닝 렌더링 모드를 사용하도록 결정하는 수단을 더 포함하는, 그래픽스 프로세싱 유닛 (GPU) 을 포함하는 디바이스.
30. 명령들을 저장하는 비-일시적인 컴퓨터 판독가능 저장 매체로서,
    상기 명령들은, 실행될 경우, 적어도 하나의 프로세서로 하여금
    GPU 가 상기 GPU 에 의해 렌더링될 프레임의 일부에 대하여 직접 렌더링 모드 또는 비닝 렌더링 모드 사이에서 선택할 수 있음을 표시하는 GPU 커맨드 패킷을 수신하게 하고;
    수신된 상기 커맨드 패킷에서의 정보 또는 상기 GPU 의 상태 중 적어도 하나에 기초하여 상기 GPU 에 의해 렌더링될 상기 프레임의 상기 일부에 대하여 상기 직접 렌더링 모드를 사용할지 또는 상기 비닝 렌더링 모드를 사용할지를 결정하게 하고; 그리고
    결정된 상기 직접 렌더링 모드 또는 상기 비닝 렌더링 모드를 사용하여 상기 프레임의 상기 일부를 렌더링하게 하는, 비-일시적인 컴퓨터 판독가능 저장 매체.

Images