KR20090045349A

KR20090045349A - 프로그램 가능한 하드웨어를 사용하는 실시간 디스플레이 후처리

Info

Publication number: KR20090045349A
Application number: KR1020097005535A
Authority: KR
Inventors: 덩컨 에이. 리아치; 존 엠. 단스킨; 조나 엠. 알벤; 마이클 에이. 오그린크; 안소니 마이클 타마시
Original assignee: 엔비디아 코포레이션
Priority date: 2004-12-20
Filing date: 2005-12-14
Publication date: 2009-05-07
Also published as: US20060132491A1; JP2008524720A; JP4620129B2; WO2006068985A3; TWI406185B; KR100902973B1; TW200632775A; WO2006068985A2; CN101080698A; CN101080698B; KR20070091356A; US7586492B2

Abstract

그래픽 프로세서에서, 렌더링 오브젝트 및 후처리 오브젝트는 호스트 프로세서로의 액세스를 프로그램 가능한 실행 코어와 공유한다. 렌더링 오브젝트는 지오메트리 데이터로부터 이미지를 위한 프레그먼트 데이터를 발생시킨다. 후처리 오브젝트는 프레그먼트 데이터로부터 픽셀 데이터의 프레임을 발생시키고 픽셀 데이터를 프레임 버퍼에 저장하도록 동작한다. 호스트 프로세서의 동작들과 병행하여, 스캔 아웃 엔진은 앞서 발생된 프레임을 위한 픽셀 데이터를 판독하고 픽셀 데이터를 디스플레이 장치에 공급한다. 스캔 아웃 엔진은 호스트 프로세서를 주기적으로 트리거하여, 후속 프레임을 발생시키도록 후처리 오브젝트를 동작시킨다. 스캔 아웃 엔진과 후처리 오브젝트 사이의 타이밍은, 스캔 아웃 엔진이 현재 프레임을 판독하는 것을 종료할 때, 디스플레이될 후속 프레임이 프레임 버퍼에 준비되도록 제어될 수 있다.

그래픽 프로세서, 실시간 디스플레이, 후처리 오브젝트, 프레그먼트 데이터, 픽셀 데이터, 렌더링 오브젝트, 호스트 프로세서, 스캔 아웃 엔진, 프레임 버퍼

Description

프로그램 가능한 하드웨어를 사용하는 실시간 디스플레이 후처리{REAL-TIME DISPLAY POST-PROCESSING USING PROGRAMMABLE HARDWARE}

본 발명은 일반적으로 그래픽 프로세서들에 관한 것으로서, 좀더 구체적으로는, 프로그램 가능한 하드웨어를 사용하는 실시간 디스플레이 후처리에 관한 것이다.

컴퓨터-기반 이미지 렌더링은 일반적으로 화면(scene)의 지오메트리 표현으로 시작한다. 다양한 오브젝트들이, 화면에 배치될 수 있는 "프리미티브들(primitives)"(일반적으로 삼각형들과 같은 단순한 다각형들 뿐만 아니라 점들 및 선들)의 집합들로서 설명된다. 뷰잉 좌표 시스템이 선택되고, 프리미티브들은 그 시스템으로 변환된다. 그 다음, 프리미티브들은 2-차원(2-D) "프레그먼트(fragment)" 어레이 표현으로 변환되는데, 이 경우, 각각의 프레그먼트는 컬러를 가지며, 깊이 좌표 또는 표면 법선과 같은, 다른 속성들을 가질 수도 있다. 비주얼 리얼리즘(visual realism)을 향상시키는 라이팅(lighting), 텍스처, 포그(fog), 및 다양한 다른 효과들이 프리미티브 및/또는 프레그먼트 스테이지들에 도입될 수도 있다. 렌더링 프로세스의 끝에서, 각각의 프레그먼트를 위한 데이터(일반적으 로 적어도 컬러값)는 이미지 버퍼에 저장된다. 이미지 버퍼는, 소정 스크린 리프레시 레이트(refresh rate)에서 픽셀들을 등시에(isochronously) 디스플레이 장치로 전달하도록 동작하는 "스캔 아웃(scanout)" 프로세스에 의해 판독된다. 실시간 애니메이션은, 렌더링 프로세스가 약 30 Hz의 레이트에서 새로운 이미지들을 전달하는 것을 요구한다. 통상적인 디스플레이 장치들은 약 60-80 Hz의 스크린 리프레시 레이트들에서 동작한다.

이러한 처리 속도 요구 사항들을 충족시키기 위해, 많은 컴퓨터 시스템들은, CPU(central processing unit)에 의해 제공되는 데이터에 대해 렌더링 연산들을 수행할 뿐만 아니라 디스플레이 장치를 구동하기 위해 등시적 스캔 아웃 동작도 수행하는 전용의 그래픽 코프로세서를 포함한다. 통상적인 그래픽 프로세서들은, 서로 비동기적으로 동작하는 렌더링 오브젝트(rendering object) 및 스캔 아웃 엔진(scanout engine)을 포함한다. 렌더링 오브젝트는 "백(back)" 이미지 버퍼에서의 새로운 이미지를 위해 프레그먼트 데이터를 발생시키는 한편, 스캔 아웃 엔진은 "프론트" 이미지 버퍼에서의 앞서 렌더링된 이미지를 사용해 디스플레이를 구동한다. 새로운 이미지의 렌더링이 완료될 때, "백" 및 "프론트" 버퍼들이 스위칭됨으로써, 스캔 아웃 엔진은 새롭게 렌더링된 이미지를 디스플레이하기 시작하는 한편, 렌더링 오브젝트는 후속 이미지로 이동한다. 일반적으로, 스캔 아웃 엔진은, 후속 이미지의 렌더링이 완료되기 전에, 동일한 이미지를 2회 또는 3회 판독할 수도 있다.

렌더링 오브젝트 및 스캔 아웃 엔진은 일반적으로, 구현에 있어 아주 상이하 다. 렌더링 오브젝트는 일반적으로 유연하고 프로그램 가능하다. 통상적인 렌더링 오브젝트들은, 동작들의 임의 시퀀스를 실행하도록 지시될 수 있는 기능 유닛들을 갖춘 실행 코어(또는 다수의 병렬 실행 코어들)을 포함한다. 적합한 프로그래밍에 의해, 실행 코어는 렌더링 알고리즘들의 임의 조합을 실행시켜 특정 이미지를 발생시킬 수 있고, 알고리즘들은 원하는 바에 따라 변경될 수 있다.

그와 달리, 스캔 아웃 엔진은 일반적으로 제한된 처리 능력을 가지며 프로그램 불가능하다. 대신에, 스캔 아웃 엔진은, 프레그먼트 데이터가 통과하는 파이프라인 특수 목적 처리 회로들의 시퀀스를 갖는데, 처리 회로들은 프레그먼트 데이터를 픽셀 값들로 변환하기 위한 다양한 동작들을 수행한다. 예를 들어, 일부 스캔 아웃 엔진들은 렌더링된 이미지보다 좀더 높은 레이트들에서 업데이트할 수도 있는 오버레이들(예를 들어, 커서들 또는 비디오 오버레이들)의 추가; 컬러 정정(예를 들어, 디스플레이 응답에서의 비선형성을 설명하기 위한 감마 정정(gamma correction)); 또는 (예를 들어, 안티에일리어싱을 위해) 스크린상의 픽셀들의 수를 맞추기 위한 프레그먼트 데이터의 필터링을 지원한다. 특수 목적 회로들은 일반적으로, 픽셀 데이터가 등시에 디스플레이 장치로 전달된다는 것을 보장하기 위해, 고정된 대기 시간을 갖고 동작하도록 설계된다.

일부 프로세서들에서는, 다양한 스캔 아웃-시간 동작들(scanout-time operations)을 인에이블 또는 디스에이블할 수 있거나(예를 들어, 오버레이들이 턴온 또는 턴오프될 수 있거나) 동작들의 파라미터들(예를 들어, 감마 정정 또는 오버레이의 위치를 위한 파라미터들)을 변경할 수 있다. 그러나, 각각의 동작이 상 이한 특수 목적 회로로 구현되기 때문에, 상이한 스캔 아웃 엔진을 구축하지 않으면서, 파이프라인에 새로운 동작을 추가하거나, 동작들의 시퀀스를 변경하거나, 특정 동작을 구현중인 알고리즘을 변경하는 것은 일반적으로 불가능하다. 이와 같이, 스캔 아웃 엔진을 재구성할 수 있는 능력은 아주 제한적이다. 새로운 사양을 추가하는 것은 일반적으로, 칩 면적 및 스케줄링, 비용 추가와 지연에 영향을 미칠 수 있는, 회로에 대한 변경들을 요구한다.

실시간 렌더링 기술들이 계속해서 발전함에 따라, 디스플레이 레이트에서 다양한 효과들을 추가할 수 있는 좀더 강력하고 유연한 스캔 아웃 엔진이 점차 소망되어 왔다. 또한, 그래픽 프로세서들에 의해 구동될 수 있는 디스플레이 장치들의 범위도 증가되었고; 전통적인 CRT 모니터들 이외에, LCD 모니터들, 디지털 마이크로미러 프로젝터들, 플라즈마 모니터들 등을 구동하기 위한 그래픽 처리 장치들이 사용될 수 있다. 디스플레이 장치의 유형 각각은 그것의 픽셀들을 구동하기 위한 상이한 요구 사항들을 가지며, 이러한 요구 사항들 모두를 하나의 하드웨어 파이프라인에 수용하기는 어렵다. 따라서, 프레그먼트-대-픽셀 변환 프로세스에서의 좀더 큰 유연성(flexibility)이 훨씬 바람직스럽다.

따라서, 디스플레이 카덴스(cadence)에서 동작들의 임의 시퀀스들을 실행할 수 있는 능력을 그래픽 프로세서에 제공하는 것이 바람직스러울 것이다.

디스플레이 장치의 유형 각각은 그것의 픽셀들을 구동하기 위한 상이한 요구 사항들을 가지며, 이러한 요구 사항들 모두를 하나의 하드웨어 파이프라인에 수용하기는 어렵다. 따라서, 프레그먼트-대-픽셀 변환 프로세스에서의 좀더 큰 유연성(flexibility)이 훨씬 바람직스럽다. 따라서, 디스플레이 카덴스(cadence)에서 동작들의 임의 시퀀스들을 실행할 수 있는 능력을 그래픽 프로세서에 제공하는 것이 바람직스러울 것이다.

본 발명의 실시예들은, 렌더링 오브젝트 및 후처리 오브젝트가 호스트 프로세서로의 액세스를 프로그램 가능한 실행 코어와 공유하는 그래픽 프로세서들을 제공한다. 렌더링 오브젝트는 지오메트리 데이터로부터 이미지를 위한 프레그먼트 데이터를 발생시키고 프레그먼트 데이터를 이미지 버퍼에 기입하도록 동작한다. 후처리 오브젝트는 하나 이상의 완료된 이미지 버퍼들에서의 프레그먼트 데이터로부터 픽셀 데이터의 프레임을 발생시키고 픽셀 데이터를 프레임 버퍼에 기입하도록 동작한다. 호스트 프로세서의 동작들과 병행하여, 스캔 아웃 엔진은 앞서 발생된 프레임을 위한 픽셀 데이터를 프레임 버퍼로부터 판독하여 픽셀 데이터를 디스플레이 장치에 공급한다. 스캔 아웃 엔진은 호스트 프로세서를 주기적으로 트리거하여 후속 프레임을 발생시키도록 후처리 오브젝트를 조작한다. 스캔 아웃 엔진과 후처리 오브젝트 사이의 타이밍은, 스캔 아웃 엔진이 현재 프레임을 판독하는 것을 완 료할 때, 디스플레이될 후속 프레임이 프레임 버퍼에 준비되도록 제어되는 것이 바람직스럽다.

본 발명의 일 양상에 따르면, 그래픽 프로세서는 프로그램 가능한 실행 코어, 조정 유닛, 및 스캔 아웃 엔진을 포함한다. 프로그램 가능한 실행 코어는 다수 컨택스트들 사이에서 스위칭 가능하도록 구성되고, 더 나아가, 스위칭된 컨택스트(switched-to context)와 연관된 프로그램 명령어들을 실행하도록 구성된다. 조정 유닛은 실행 코어에 연결되고 상이한 컨택스트들 사이에서 실행 코어의 스위칭을 제어하도록 구성된다. 스캔 아웃 엔진은 상기 프로그램 가능한 실행 코어에 의해 발생된 픽셀 데이터의 프레임들을 등시에 디스플레이 포트로 송신하도록 구성되고 트리거 신호를 조정 유닛으로 주기적으로 송신하도록 연결된다. 컨택스트들은, 이미지 데이터를 발생시키기 위한 제1 시퀀스의 프로그램 명령어들이 연관되어 있는 렌더링 컨택스트 및 이미지 데이터로부터 픽셀 데이터의 프레임을 발생시키기 위한 제2 시퀀스의 프로그램 명령어들이 연관되어 있는 후처리 컨택스트를 포함한다. 더 나아가, 조정 유닛은 트리거 신호에 응답하여 실행 코어를 후처리 컨택스트로 스위칭하도록 구성된다. 일부 실시예들에서, 스캔 아웃 엔진은 부가적으로, 트리거 신호가 EOF(end of frame) 이벤트에 대해 사실상 고정된 시간 관계를 갖도록 구성된다.

일부 실시예들에서, 조정 유닛은 부가적으로, 프로그램 명령어들의 제2 스트림에서 프레임 종료 이벤트가 검출될 때까지, 실행 코어를 후처리 컨택스트로 유지한 다음 실행 코어를 렌더링 컨택스트로 스위칭하도록 구성된다. 프레임 종료 이 벤트는, 예를 들어, 프로그램 명령어들의 제2 스트림에서의, 프로그램 명령어들의 제2 스트림의 시작점을 타겟으로 하는 무조건 점프 명령어(unconditional jump instruction)의 발생에 대응될 수도 있다.

본 발명의 다른 양상에 따르면, 이미지들을 발생시키기 위한 방법이 제공된다. 프로세서의 공유되는 실행 코어에서, 렌더링 오브젝트가 조작되고; 렌더링 오브젝트는 제1 시퀀스의 프로그램 명령어들에 응답하여 이미지들을 위한 프레그먼트 데이터를 발생시킨다. 렌더링 오브젝트를 조작하는 것과 병행하여, 스캔 아웃 엔진은 픽셀 데이터의 프레임들을 등시에 디스플레이 장치로 전달하도록 조작되고; 스캔 아웃 엔진은 트리거 신호를 주기적으로 발생시킨다. 트리거 신호에 응답하여, 후처리 오브젝트는 프로세서의 공유되는 실행 코어에서 조작되며; 후처리 오브젝트는, 제2 시퀀스의 프로그램 명령어들에 응답하여, 프레그먼트 데이터로부터 하나 이상의 이미지들을 위한 픽셀 데이터의 새로운 프레임을 발생시키고, 픽셀 데이터의 새로운 프레임이 스캔 아웃 엔진에 이용될 수 있다. 일부 실시예들에서, 제2 시퀀스의 프로그램 명령어들은, 예를 들어, 이미지를 위한 프레그먼트 데이터를 다운 필터링(downfiltering)하기 위한 명령어들; 이미지를 위한 프레그먼트 데이터를 업 필터링(upfiltering)하기 위한 명령어들; 프레임의 각 픽셀을 위한 LCD 오버드라이브 값(overdrive value)을 계산하기 위한 명령어들; 및/또는 2 이상의 상이한 이미지들을 위한 프레그먼트 데이터를 사용해 합성 이미지(composite image)를 형성하기 위한 명령어들을 포함할 수도 있다.

발명의 또 다른 양상에 따르면, 그래픽 처리 시스템은 이미지 버퍼들, 프레 임 버퍼들, 및 멀티프로세서를 포함한다. 각각의 이미지 버퍼는 이미지를 위한 프레그먼트 데이터를 저장하도록 구성되고, 각각의 프레임 버퍼는 프레임을 위한 픽셀 데이터를 저장하도록 구성된다. 멀티프로세서는 프로그램 가능한 실행 코어, 조정 유닛, 및 스캔 아웃 엔진을 포함한다. 프로그램 가능한 실행 코어는 다수의 컨택스트들 사이에서 스위칭 가능하도록 구성되고, 그에 따라, 실행 코어는 스위칭된 컨택스트와 연관된 프로그램 명령어들을 실행한다. 조정 유닛은 실행 코어에 연결되어 상이한 컨택스트들 사이에서 실행 코어의 스위칭을 제어하도록 구성된다. 스캔 아웃 엔진은 프레임 버퍼들로부터의 픽셀 데이터의 프레임들을 등시에 디스플레이 포트로 송신하도록 구성되고 트리거 신호를 멀티프로세서의 조정 유닛으로 주기적으로 송신하도록 연결된다. 컨택스트들은 이미지들을 위한 프레그먼트 데이터를 발생시키고 각각의 이미지를 위한 프레그먼트 데이터를 이미지 버퍼들 중 하나에 기입하기 위한 제1 시퀀스의 프로그램 명령어들이 연관되어 있는 렌더링 컨택스트 및 이미지 버퍼들에서의 프레그먼트 데이터로부터 픽셀 데이터의 프레임을 발생시키고 프레임을 위한 픽셀 데이터를 프레임 버퍼들 중 하나에 기입하기 위한 제2 시퀀스의 프로그램 명령어들이 연관되어 있는 후처리 컨택스트를 포함한다. 조정 유닛은 부가적으로, 트리거 신호에 응답하여, 실행 코어를 후처리 컨택스트로 스위칭하도록 구성된다.

개요 및 용어

본 발명의 실시예들은, 렌더링 오브젝트 및 후처리 오브젝트가 호스트 프로 세서로의 액세스를 프로그램 가능한 실행 코어와 공유하는 그래픽 프로세서들을 제공한다. 렌더링 카덴스(rendering cadence)에서 동작하는 렌더링 오브젝트는 지오메트리 데이터로부터 이미지를 위한 프레그먼트 데이터를 발생시키고 프레그먼트 데이터를 이미지 버퍼에 기입한다. 스캔 아웃(디스플레이) 카덴스에서 동작하는 후처리 오브젝트는 하나 이상의 완료된 이미지 버퍼들에서의 프레그먼트 데이터로부터 픽셀 데이터를 발생시키고 픽셀 데이터를 프레임 버퍼에 기입한다. 병행하여, 스캔 아웃 엔진은 상이한 프레임 버퍼로부터 앞서 발생된 프레임을 위한 픽셀 데이터를 판독하여 픽셀들을 디스플레이 장치에 공급한다. 스캔 아웃 동작과 동기하여, 스캔 아웃 엔진은 호스트 프로세서를 트리거하여 스캔 아웃 카덴스에서 후처리 오브젝트를 실행하고, 그에 따라, 스캔 아웃 엔진이 현재 프레임을 판독하는 것을 완료할 때, 후속 프레임이 준비될 것이다.

여기에서는 다음의 용어가 사용된다:

"이미지"라는 용어는 소정 픽처의 표현을 구성하는 "프레그먼트들"의 어레이를 의미하고, 이 경우, 각각의 프레그먼트는 컬러를 가지며, 깊이, 투명도 등과 같은, 다른 속성들을 가질 수도 있다. 프레그먼트 컬러는, RGB(red/green/blue), YCrCb(luminance-chrominance), HLS(hue/lightness/saturation), 단색 강도 값들(monochromatic intensity values) 또는 다른 포맷들을 포함하는, 임의의 편리한 포맷으로 그리고 임의의 원하는 해상도로써 표현될 수도 있다. 프레그먼트들은 디스플레이 장치의 픽셀들에 대해, 숫자상으로 또는 배열상으로, 임의의 특정 관계를 가질 것이 요구되지 않으며, 프레그먼트들의 어레이는 프레그먼트들 사이에서 균일 한 간격을 가질 수도 그렇지 않을 수도 있다.

"렌더링"은 일반적으로, 화면 데이터로부터, 프리미티브들 및 관련된 지오메트리 데이터를 통상적으로 포함하는 이미지 또는 프레그먼트 데이터를 발생시키는 프로세스를 의미한다. 렌더링 프로세스는, 버텍스 처리(스크린 공간으로의 변환), (스크린 공간에서 관심있는 프리미티브들 및 속성들을 선택하는) 설정, (어떤 프리미티브(들)가 각각의 프레그먼트를 커버하는지를 판정하기 위해 프레그먼트 위치들의 어레이를 샘플링하는) 래스터화(rasterization), (어떤 프리미티브(들)가 프레그먼트를 커버하는지에 기초해 프레그먼트를 위한 속성들을 발생시키는) 셰이딩, 및 (예를 들어, 다운 필터링에 의해 프레그먼트 어레이를 변환하는) 포스트-셰이딩 래스터 동작들과 같은, 다수 스테이지들을 포함할 수도 있다. 이미지들의 렌더링은 일반적으로, 일부 실시예들에서, 애니메이션에 적당한 스피드, 예를 들어, 약 30개 이미지들/초인 평균 스피드("렌더링 카덴스")에서 발생한다. 렌더링 프로세스들의 세부 사항들은 본 발명에 중요하지 않으며, 렌더링 스피드는 이미지에 따라 변동될 수도 있다.

렌더링된 이미지들은, 각각이 픽셀 값의 함수인 구동 신호에 응답하여 컬러를 디스플레이하는 "픽셀들"의 어레이 또는 래스터를 사용하는 디스플레이 장치에 디스플레이된다. 앞서 지적된 바와 같이, 디스플레이 장치의 픽셀은 렌더링된 이미지의 단일 프레그먼트에 대응될 수도 대응되지 않을 수도 있다. 여기에서 사용되는 "프레임"은 일반적으로 픽셀 래스터를 위한 픽셀 값들의 완전한 세트를 의미한다. 새로운 프레임들은, 사용자 선택 가능 파라미터일 수 있는 소정의 스크린 리프레시 레이트 또는 "디스플레이 카덴스"(예를 들어, 80 Hz)에서 디스플레이된다. 연속적인 프레임들은 동일한 이미지 또는 상이한 이미지들을 디스플레이할 수 있다.

"후처리"는 일반적으로 픽셀 데이터의 프레임을 발생시키기 위한 하나 이상의 이미지들을 위한 프레그먼트 데이터의 처리를 의미한다. 후처리는, 일반적으로 애니메이션 스피드보다 높은 디스플레이 카덴스(스크린 리프레시 레이트)에서 수행되는 것이 바람직스럽다. 본 발명에 따른 다수의 후처리 동작들이 구현될 수도 있다. 다음은 일부 일례들인데, 발명이 후처리 동작들의 임의의 특정 조합 또는 시퀀스로 제한되는 것은 아니라는 것이 이해될 수 있어야 한다.

일 후처리 동작은, 단일 픽셀 값을 획득하기 위해 일 이미지로부터의 상이한 프레그먼트들의 값들을 블렌딩하는 단계를 수반하는 필터링이다. 필터링은, 프레그먼트들의 수와는 상이한 다수 픽셀들을 초래할 수 있다. 일 실시예에서, 프레그먼트들은 프레그먼트들의 수보다 적은 다수 픽셀들을 발생시키기 위해 다운 필터링될 수 있다. 예를 들어, 각각의 픽셀 값은 이웃한 프레그먼트 값들의 가중된 평균일 수도 있다. 다운 필터링은 이미지 사이즈를 감소시키고, 오버샘플링(예를 들어, 멀티샘플링) 동작의 최종 스테이지로서 안티에일리어싱을 구현하는 등에 사용될 수 있다. 다른 방법으로, 프레그먼트들은 업 필터링되어 프레그먼트들의 수보다 많은 다수 픽셀들을 발생시킬 수 있다. 예를 들어, 보간(interpolation)이 사용되어 입력 프레그먼트 값들 사이에 또는 입력 프레그먼트 값들 대신에 추가적인 픽셀 값들을 추가할 수 있다. 업 필터링은, 예를 들어, 디스플레이를 위해 이미지 를 확대하는데 사용될 수 있다.

다른 후처리 동작은, 일반적으로 2 이상의 이미지들로부터의 프레그먼트들을 최종 이미지로 결합하는 것을 의미하는 합성이다. 예를 들어, 커서 이미지가 스크린 이미지의 일부분에 오버레이될 수 있고, 또는 (무비와 같은) 비디오 이미지가 데스크탑의 윈도에 오버레이될 수도 있다. 일부 실시예들에서는, 결합 이미지들이, 디스플레이 카덴스 이외에서, 이미지들을 정확하게 결합하는 것을 어렵게 하면서, 상이한 레이트들에서 업데이트할 수도 있다. 일부 실시예들에서는, 합성 또한 페이드-인(fade-in), 페이드-아웃(fade-out), 또는 디졸브(dissolve)와 같은, 전이 효과들을 발생시키기 위해 이미지들을 블렌딩하는 단계를 포함할 수도 있다. 이러한 효과들을 위해, 예전의 그리고 새로운 이미지들은, 시간의 함수로서 변화하는 개개의 가중치들을 사용해, 블렌딩될 수 있다.

또 다른 후처리 동작은, 일반적으로 이미지를 위한 프레그먼트 데이터를 2-D 또는 3-D 표면으로 매핑하고 그 표면을 픽셀 어레이상으로 투사하는 것을 의미하는 표면 매핑(surface mapping)이다. 일 실시예에서, 프레그먼트 데이터는, 프로젝터들인 디스플레이 장치들에 "키스톤(keystone)" 정정을 제공하기 위해 사다리꼴 표면으로 매핑될 수 있고; 사다리꼴 표면의 형태 및 사이즈는, 프로젝터로부터의 빔 축이 스크린 또는 다른 디스플레이 표면에 수직하지 않을 때 발생하는 주지의 왜곡을 보상하기 위해 사용자에 의해 조정될 수 있다. 다른 실시예들에서, 프레그먼트 데이터는, 원하는 비주얼 효과를 발생시키도록 또는 왜곡이 감소된 비평면 표면(non-planar surface;예를 들어, 원기둥 또는 돔)으로의 프로젝션을 지원하도록 정의될 수도 있는 임의 형태의 표면으로도 매핑될 수 있다.

추가적인 후처리 동작은, 이미지를 위한 프레그먼트 데이터를 이미지에 수직인 축 주위에서 몇몇 각도(예를 들어, 90°의 배수)만큼 회전된 2-D 표면으로 매핑하는 것을 의미하는 표면 회전이다. 예를 들어, 90°만큼의 시계 방향 회전은, 이미지의 상단 왼쪽 코너가 픽셀 어레이의 상단 오른쪽 코너에 나타나며, 이미지에서의 수평선들이 픽셀 어레이에서의 수직선들이 되는 식의 프레그먼트를 초래할 것이다. 표면 회전은, 상술된 표면 매핑 동작의 특수한 경우로서 보여질 수 있을 것이다. 일 실시예에서, 표면 회전은, 태블릿 PC 디스플레이들 및 일부 평판 모니터들을 위한 경우에서와 같이, 회전 가능하게 탑재된 디스플레이 장치들을 위해 사용된다.

또 다른 후처리 동작은 광도 보상(luminosity compensation)이다. 예를 들어, 이미지가 스크린으로 투사될 때, 프로젝터로부터 좀더 먼 픽셀들이 근접 픽셀들보다 좀더 어두침침한 경향이 있다. 또는, 스크린 주위의 주변광(ambient light)이 불균일하면, 스크린의 일부가 나머지보다 좀더 밝게 보일 수도 있다. 광도 보상은, 픽셀 강도를 스크린 위치의 함수로서 변경하는 것에 의해 그러한 효과들을 정정할 수 있고, 사용자는 원하는 바에 따라 다양한 광도 보상 파라미터들을 조정할 수도 있다.

다른 후처리 동작들은 특정 디스플레이 장치의 특성들을 보상한다. 아날로그 신호들에 의해 구동되는 디스플레이 장치들에서의 비선형적인 전압 응답을 보상하기 위해, 예를 들어, 감마 정정이 흔히 사용되어 픽셀 값들을 지수적으로 스케일 링한다. 다른 일례로서, LCD 모니터들에서는, 부분적으로는 원하는 강도에 의존하고 부분적으로는 선행 프레임과 관련하여 강도가 변하는 양에 의존하는 픽셀 각각을 위한 구동 값을 제공하는 것에 의해, 응답 시간이 향상될 수 있다. 디스플레이 장치들의 다른 유형들에 특정 다른 보상 동작들도 후처리로 구현될 수 있다.

일부 실시예들에서, 후처리 동작들은, LCD 오버드라이브 또는 합성과 같은, 정확한 결과들을 발생시키기 위해 디스플레이 카덴스에서 수행되어야 하는 동작들이다. 렌더링이 스캔 아웃과 비동기적인 경우, 렌더링 시점에서, 렌더링 카덴스가 디스플레이 카덴스와 조화를 이룰 방법을 판정하는 것은 대체로 어렵거나 불가능하고, 따라서, 동작이 렌더링 동안 수행되어야 한다면, 정확한 결과들을 보장하는 것 또한 어렵거나 불가능할 것이다.

"스캔 아웃"은 일반적으로 (후처리 이후의) 프레임을 위한 픽셀 데이터를 디스플레이 장치에 접속하는 출력 경로로 전달하는 것을 의미한다. 후처리와 같이, 스캔 아웃은 디스플레이 카덴스에서 발생한다. 일부 실시예들에서, 후처리에 의해 발생된 픽셀 데이터는 이미 디스플레이 장치를 구동하기에 적합한 포맷에 있다. 다른 실시예들에서, 스캔 아웃은 픽셀 데이터를 적합한 포맷으로 변환하는 단계를 포함할 수도 있고, 리스케일링, DA(digital-to-analog) 변환, 및 다른 신호 처리 기술들을 포함할 수도 있다.

시스템 개요

도 1은 본 발명의 실시예에 따른 컴퓨터 시스템(100)의 블록도이다. 컴퓨터 시스템(100)은 버스(106)를 통해 통신하는 CPU(102) 및 시스템 메모리(104)를 포함 한다. 사용자 입력은 버스(106)에 연결된 하나 이상의 사용자 입력 장치들(108;예를 들어, 키보드, 마우스)로부터 수신된다. 비주얼 출력은 시스템 버스(106)에 연결된 그래픽 처리 서브시스템(112)의 제어하에서 동작하는 픽셀 기반 디스플레이 장치(110;예를 들어, 종래의 CRT 또는 LCD 기반 모니터)를 통해 제공된다. 시스템 디스크(107) 및, 하나 이상의 분리형 저장 장치들(109;예를 들어, 플로피 디스크 드라이브, CD(compact disk) 드라이브, 및/또는 DVD 드라이브)과 같은, 다른 컴포넌트들도 시스템 버스(106)에 연결될 수 있다. 시스템 버스(106)는 PCI(Peripheral Component Interconnect), AGP(Advanced Graphics Processing), 및/또는 PCI-E(PCI-Express)를 포함하는 다양한 버스 프로토콜들 중 하나 이상을 사용해 구현될 수 있고; 다양한 컴포넌트들 및/또는 버스들을 상호 접속하기 위해 (도시되지 않은) 노스 브릿지(north bridge) 및 사우스 브릿지(south bridge)와 같은 적합한 "브릿지" 칩들이 제공될 수도 있다.

그래픽 처리 서브시스템(112)은, 예를 들어, 프로그램 가능한 프로세서들, ASIC들(application specific integrated circuits), 및 메모리 장치들과 같은 하나 이상의 집적 회로 장치들을 사용해 구현될 수도 있는, 그래픽 처리 유닛(GPU;114) 및 그래픽 메모리(116)를 포함한다. GPU(114)는 멀티프로세서(120), 메모리 인터페이스 모듈(122), 및 스캔 아웃 엔진(124)을 포함한다.

멀티프로세서(120)는 그래픽 처리 서브시스템(112)을 위해 렌더링 및 후처리 태스크들을 수행하도록 구성될 수도 있다. 멀티프로세서(120)는 (도 1에 명시적으로 도시되어 있지 않은) 프로그램 가능한 실행 코어를 포함하고, 2 이상의 프로세 스들을 동시에 실행할 수 있다. 하나의 프로세스는, CPU(102)에서 실행중인 다양한 프로그램들에 의해 제공되는 2-D 또는 3-D 화면 데이터로부터 이미지(프레그먼트) 데이터를 발생시키도록 구성되는 것이 바람직스러운 "렌더링 오브젝트"(132)이다. 다른 프로세스는, 프레그먼트 데이터를 디스플레이 장치(110)에서의 디스플레이를 위해 준비된 픽셀 데이터로 변환하도록 구성되는 "후처리 오브젝트"(134)이다. 일 실시예에서는, 임의의 소정 시점의 멀티프로세서(120)에서 이 프로세스들 중 하나만이 활성이고; 상이한 프로세스들이 스위칭 인 및 아웃되어 동시 처리의 효과를 제공할 수 있다. 일부 실시예들에서는, 렌더링 오브젝트(132) 및 후처리 오브젝트(134)가, 양자의 오브젝트들을 지원하기 위해 컨택스트 스위칭할 수 있는 것이 바람직스러운 동일한 물리적 처리 엔진으로 구현될 수도 있고; 다른 실시예들에서는, 렌더링 오브젝트(132) 및 후처리 오브젝트(134)가 별도의 처리 엔진들에 구현되고, 그들 사이에서의 컨택스트 스위칭은 요구되지 않는다. 멀티프로세서(120)의 특정 실시예들은 다음에서 부연된다.

멀티프로세서(120) 및 스캔 아웃 엔진(124)과 통신하는 메모리 인터페이스 모듈(122)이 그래픽 메모리(116)와의 모든 상호 작용들을 관리한다. 메모리 인터페이스 모듈(122)은, 멀티프로세서(120)에 의한 처리없이, 시스템 버스(106)로부터 수신된 프레그먼트 또는 픽셀 데이터를 그래픽 메모리(116)에서의 적합한 위치들에 기입하기 위한 경로들도 포함할 수 있다. 메모리 인터페이스 모듈(122)의 세부 구성은 원하는 바에 따라 달라질 수도 있고, 상세한 설명은, 그것이 본 발명을 이해하는데 중요하지 않으므로, 생략된다.

일반적으로 종래 설계의 하나 이상의 집적 회로 메모리 장치들을 사용해 구현될 수 있는 그래픽 메모리(116)는, 렌더 버퍼(126), 디스플레이 버퍼(127), 렌더링 커맨드 버퍼(128), 및 후처리(PP) 커맨드 버퍼(129)와 같은, 다양한 물리적 또는 논리적 서브 분할들을 포함할 수도 있다. 렌더 버퍼(126)는 렌더링 오브젝트(132)에 의해 또는 CPU(102)에서 실행중인 다양한 프로세스들에 의해 발생되는 하나 이상의 이미지들을 위한 프레그먼트 데이터를 저장한다. 렌더 버퍼(126)는 바람직스럽게도, 동일한 프로세스에 의해 발생되는 이미지들의 시퀀스들을 포함하여, 상이한 다수 이미지들을 버퍼링함으로써, 제1 이미지를 위한 프레그먼트 데이터가 후처리되는 동안, 후속 이미지를 위한 프레그먼트 데이터가 렌더 버퍼(126)의 상이한 영역에 기입될 수 있다.

디스플레이 버퍼(127)는 렌더 버퍼(126)에서의 프레그먼트 데이터로부터 후처리 오브젝트(134)에 의해 발생되는 픽셀 데이터를 저장한다. 디스플레이 버퍼(127)는 바람직스럽게도 픽셀 데이터의 2 이상의 완전한 프레임들을 저장하고, 그에 따라, 일 프레임을 위한 픽셀 데이터가 "프론트" 버퍼로부터 스캔 아웃될 수 있고, 후속 프레임을 위한 픽셀 데이터가 "백" 버퍼에 기입될 수 있다.

렌더링 커맨드 버퍼(128) 및 PP 커맨드 버퍼(129)는 멀티프로세서(120)에 의한 실행을 위해 시스템 버스(106)를 통해 수신되는 커맨드들을 큐잉(queuing)하는데 사용된다. 후술되는 바와 같이, 렌더링 커맨드 버퍼(128)에서의 커맨드들은 렌더링 오브젝트(132)에 의해 실행될 것이고, PP 커맨드 버퍼(129)에서의 커맨드들은 후처리 오브젝트(134)에 의해 실행될 것이다.

그래픽 메모리(116)의 다른 부분들은 (텍스처 데이터, 컬러 룩업 테이블들 등과 같은) GPU(114)에 의해 요구되는 데이터, GPU(114)를 위한 실행 가능한 프로그램 코드 등을 저장하는데 사용될 수도 있다.

멀티프로세서(120)와 단일 칩으로 집적될 수 있거나 별도 칩으로 구현될 수 있는 스캔 아웃 엔진(124)은 디스플레이 버퍼(127)로부터 픽셀 데이터를 판독하여 디스플레이될 디스플레이 장치(110)로 데이터를 전달한다. 일 실시예에서, 스캔 아웃 엔진(124)은, GPU(114) 또는 시스템(100)의 어딘가 다른 곳에서 발생할 수도 있는 임의의 다른 활동과 관계없이, 소정의 스크린 리프레시 레이트(예를 들어, 80 Hz)에서 픽셀 데이터의 프레임들을 등시에 스캔 아웃하도록 동작한다. 일부 실시예들에서, 소정 리프레시 레이트는 사용자 선택 가능 파라미터일 수 있고, 스캔 아웃 순서는 디스플레이 포맷(예를 들어, 인터레이스 또는 순차적 스캔)에 적합하게 변경될 수도 있다. 스캔 아웃 엔진(124)은 데이터 포매팅과 DA 변환을 위한 회로들 및 픽셀 데이터를 디스플레이 장치를 위한 적합한 포맷으로 변환하는 다른 신호 처리 회로를 포함할 수도 있다. 스캔 아웃 엔진(124)의 세부 구성은 원하는 바에 따라 달라질 수도 있다.

시스템(100)의 동작 동안, CPU(102)는, 오퍼레이팅 시스템 프로그램들, 애플리케이션 프로그램들, 및 그래픽 처리 서브시스템(112)을 위한 하나 이상의 드라이버 프로그램들과 같은, 다양한 프로그램들을 실행한다. 드라이버 프로그램은, 업계에 공지되어 있는 바와 같이, 애플리케이션 및 오퍼레이팅 시스템 프로그램들이 그래픽 처리 서브시스템(112)의 다양한 기능들을 호출할 수 있게 하는 OpenGL, Microsoft DirectX, 또는 D3D와 같은, 종래의 API들(application program interfaces)을 구현할 수도 있다.

그래픽 처리 서브시스템(112)의 동작은 시스템(100)의 다른 동작들과 비동기인 것이 바람직스럽다. 예를 들어, 일부 실시예들에서, 렌더링 커맨드 버퍼(128) 및 PP 커맨드 버퍼(129)는 GPU(114)에 의한 실행을 위해 시스템 버스(106)를 통해 수신되는 커맨드들을 큐잉한다. 좀더 구체적으로, CPU(102)에서 실행중인 그래픽 드라이버는 렌더링 커맨드 스트림 또는 프로그램을 렌더링 커맨드 버퍼(128)에 기입할 수도 있고, 후처리 커맨드 스트림 또는 프로그램을 PP 커맨드 버퍼(129)에 기입할 수도 있다. 커맨드 스트림들은, GPU(114)가 그것들을 처리하도록 준비될 때까지, 그것들의 개개의 커맨드 버퍼들(128)에 보유된다.

렌더링 커맨드 버퍼(128)는 CPU(102)에 의해(좀더 구체적으로는, CPU(102)에서 실행중인 그래픽 드라이버에 의해) 기입되고 GPU(114)에 의해(좀더 구체적으로, 멀티프로세서(120)의 렌더링 오브젝트(132)에 의해) 판독되는 FIFO(first in, first out) 버퍼로서 구현되는 것이 바람직스럽다. 판독하고 기입하는 것은 비동기적으로 발생할 수 있다. 일 실시예에서, 그래픽 드라이버는 새로운 커맨드들 및 데이터를, 각각의 기입 이후에 그래픽 드라이버가 증분시키는 "풋(put)" 포인터에 의해 판정되는 위치에서 렌더링 커맨드 버퍼(128)에 주기적으로 기입한다. 비동기적으로, 렌더링 오브젝트(132)는 렌더링 커맨드 버퍼(128)에 앞서 저장된 커맨드들 및 데이터를 순차적으로 판독하고 처리할 수 있다. 렌더링 오브젝트(132)는 커맨드 버퍼(128)에서의 현재의 판독 위치를 식별하기 위해 "겟(get)" 포인터를 유지하 고, 겟 포인터는 각각의 판독 이후에 증분된다. 그래픽 드라이버가 렌더링 오브젝트(132)의 앞쪽으로 충분히 멀리 유지된다면, GPU(114)는 CPU(102)를 대기하는 유휴 시간(idle time)을 초래하지 않으면서, 이미지들을 렌더링할 수 있다. 일부 실시예들에서는, 렌더링 커맨드 버퍼(128)의 사이즈 및 화면의 복잡도에 따라, 그래픽 드라이버는, 렌더링 오브젝트(132)에 의해 현재 렌더링되고 있는 이미지 이전의 수개 이미지들을 위한 커맨드들 및 데이터를 기입중일 수도 있다. 렌더링 커맨드 버퍼(128)는 고정된 사이즈(예를 들어, 5 메가바이트)일 수도 있고, 랩어라운드(wraparound) 방식으로 기입 및 판독될 수도 있다(예를 들어, 마지막 위치에 기입한 후, 그래픽 드라이버는 "풋" 포인터를 제1 위치로 리셋할 수 있고; 마찬가지로, 마지막 위치로부터 판독한 후, 렌더링 오브젝트(132)는 "겟" 포인터를 제1 위치로 리셋할 수 있다).

PP 커맨드 버퍼(129)는 원형 큐(circular queue)로서 구현되는 것이 바람직스럽다. 각각의 프레임을 위해 후처리 커맨드들의 새로운 스트림을 기입하는 것이 아니라, 그래픽 드라이버 프로그램은 일단 후처리 스트림 또는 프로그램을 PP 커맨드 버퍼(129)에 기입하고, 후처리가 변경되어야 할 경우에만, 새로운 스트림 또는 프로그램을 기입할 수도 있다. 멀티프로세서(120)의 후처리 오브젝트는 그 스트림을 각각의 프레임에서, 후술되는 바와 같이, 실행하고, 실행된 커맨드들은 후속적인 재실행을 위해 PP 커맨드 버퍼(129)에 유지될 수도 있다. PP 커맨드 버퍼(129)는 고정된 사이즈(예를 들어, 1 메가바이트)일 수 있고, 커맨드 스트림은 후속 프레임의 처리를 위해 제어를 커맨드 스트림의 시작으로 역 전달하는 무조건 "점프" 커맨드로 끝날 수도 있다.

일부 실시예들에서, 멀티프로세서(120)에 의한 렌더링 오브젝트(132)의 동작은 임의의 다른 동작들과 비동기인 한편, 후처리 오브젝트(134)의 동작은 스캔 아웃 엔진(124)의 동작과 동기되어, 디스플레이 카덴스에서 후처리가 발생한다. 예를 들어, 멀티프로세서(120)는 렌더링 오브젝트(132)를 주기적으로(예를 들어, 스캔 아웃 프레임당 한번씩) 일시 중지할 수 있고, 후처리 오브젝트(134)가 스크린 픽셀 데이터의 프레임을 발생시키고 그 데이터를 디스플레이 버퍼(127)에 기입하는 것을 허용하기에 충분히 긴 시간 동안 후처리 오브젝트(134)를 동작시킨다. 적당한 동작을 제공하는 제어 메커니즘들의 일례들이 후술된다.

여기에서 설명되는 시스템이 예시적이라는 것과 변경들 및 변형들이 가능하다는 것을 알 수 있을 것이다. GPU는 임의의 적당한 기술들을 사용해, 예를 들어, 하나 이상의 집적 회로 장치들로서 구현될 수도 있다. GPU는 하나 이상의 그러한 프로세서들을 포함할 수 있는 확장 카드에 탑재될 수 있고, 시스템 마더보드에 직접적으로 탑재될 수 있고, 또는 시스템 칩셋 컴포넌트로(예를 들어, 흔히 사용되는 PC 시스템 아키텍처의 노스 브릿지 칩으로) 집적될 수도 있다. 그래픽 처리 서브시스템은 전용 그래픽 메모리의 임의의 양을 포함할 수 있고(일부 구현들은 전용 그래픽 메모리를 갖지 않을 수도 있다), 시스템 메모리 및 전용 그래픽 메모리를 임의 조합으로 사용할 수도 있다. 스캔 아웃 회로는 GPU와 집적될 수 있거나 별도 칩으로 제공될 수 있고, 예를 들어, 하나 이상의 ASIC들, 프로그램 가능한 프로세서 소자들, 다른 집적 회로 기술들, 또는 그것에 관한 임의 조합을 사용해 구현될 수도 있다. 또한, 본 발명을 구현하는 GPU들은, 범용 컴퓨터 시스템들, 비디오 게임 콘솔들과 다른 특수 목적 컴퓨터 시스템들, DVD 플레이어들, 모바일 폰들 또는 PDA들과 같은 핸드헬드 장치들 등을 포함하는, 다양한 장치들로 통합될 수도 있다.

데이터 흐름도

도 2는 멀티프로세서(120), 렌더링 오브젝트(132), 후처리 오브젝트(134), 및 스캔 아웃 엔진(124) 사이의 관계를 추가적으로 예시하는 그래픽 처리 서브시스템(112)을 위한 데이터 흐름도이다. 데이터 전파는 실선의 화살표들로써 표시되고, 커맨드 전파는 속이 빈 화살표들로써 표시되며, 제어 신호 전파는 점선의 화살표들로써 표시된다.

도 2에서, 렌더 버퍼(126)는 (여기에서 개별적으로 A, B, 및 C로서 언급되는) 3개의 이미지 버퍼들(226) 및 세마포어 저장 영역(206)을 포함하는 것으로 도시되어 있다. 이미지 버퍼들(226)은 각각이 일 이미지를 위한 프레그먼트 데이터 전부를 저장하기에 충분할 정도로 크고, 렌더링 오브젝트(132)는 일 이미지를 위한 모든 프레그먼트 데이터는 버퍼 A에, 후속 이미지를 위한 모든 프레그먼트 데이터는 버퍼 B에 기입하는 식으로 조작되는 것이 바람직하다. 임의 갯수의 이미지 버퍼들(226)이 제공될 수 있다는 것을 이해할 수 있을 것이다. 세마포어 영역(206)은, 후술되는 바와 같이, 이미지 버퍼들(226)로의 액세스를 제어하는데 사용된다.

디스플레이 버퍼(127)는 (여기에서 개별적으로 X 및 Y라고 하는) 2개의 프레임 버퍼들(227) 뿐만 아니라 BSEL(buffer-select) 저장 영역(208)을 포함하는 것으로 도시되어 있다. 프레임 버퍼들(227)은 각각이 완전한 프레임을 위한 픽셀 데이 터 전부를 저장하기에 충분할 정도로 크고, 후처리 오브젝트(134)는 일 프레임을 버퍼 X에, 후속 프레임을 버퍼 Y에 기입하는 식으로 조작될 수도 있다. BSEL 저장 영역(208)은, 프레임 버퍼들(227) 중 어떤 것이 스캔 아웃 엔진(124)에 의해 판독될 것인지를 고유하게 식별하는 값을 저장하기에 충분할 정도로 크다. 일 실시예에서, BSEL 저장 영역(208)은 (비트가 0이라면) 프레임 버퍼 X 또는 (비트가 1이라면) 프레임 버퍼 Y를 식별하는 단일 비트를 저장한다. 다른 실시예에서, BSEL 저장 영역(208)은 프레임 버퍼 X 또는 프레임 버퍼 Y 중 하나를 위한 그래픽 메모리(116)에서의 시작 어드레스의 식별자(예를 들어, 오프셋 값)를 저장한다. 다른 식별자들이 사용될 수도 있다.

이 실시예에서, 렌더링 오브젝트(132)는, 예를 들어, 시스템 버스(106)를 통해 지오메트리 데이터를 수신한다. 수신된 지오메트리 데이터는 그래픽 메모리(116)에, 멀티프로세서(120)의 (도시되지 않은) 온칩 데이터 캐시에, 또는 다른 곳에 저장될 수도 있다. 렌더링 오브젝트(132)는 이미지를 위한 프레그먼트 데이터를 발생시키기 위해, 렌더링 커맨드 버퍼(128)에 의해 제공되는 커맨드들에 따라, 지오메트리 데이터를 처리한다. 프레그먼트 데이터는 이미지 버퍼들(226)들 중 하나(예를 들어, 버퍼 A)에 기입된다.

후처리 오브젝트(134)는, 프레임을 위한 픽셀 데이터를 발생시키기 위해, PP 커맨드 버퍼(129)로부터 수신된 커맨드들에 따라, 이미지 버퍼들(226)에서의 프레그먼트 데이터를 처리한다. 픽셀 데이터는 프레임 버퍼들(227) 중 하나, 예를 들어, 버퍼 X에 기입된다. 이 실시예에서, 후처리 오브젝트(134)는, 렌더링 오브젝 트(132)에 의해 현재 기입되고 있는 이미지 버퍼를 제외한 임의의 이미지 버퍼(226)로부터, 예를 들어, 렌더링 오브젝트(132)가 버퍼 A에 기입중이라면, 버퍼들 B 및/또는 C로부터 프레그먼트 데이터를 획득할 수도 있다.

스캔 아웃 엔진(124)은 프레임 버퍼들(227) 중 하나로부터 픽셀 데이터를 판독하고 그것을 디스플레이 장치에 제공한다. 이 실시예에서, 스캔 아웃 엔진(124)은, 후처리 오브젝트(134)에 의해 기입되고 있는 프레임 버퍼와는 동일하지 않은 것이 바람직스러운, BSEL 저장 영역(208)에서 식별된 프레임 버퍼(227)로부터 판독하는데, 예를 들어, 후처리 오브젝트(134)가 프레임 버퍼 X에 기입중이라면, 스캔 아웃 엔진(124)은 버퍼 Y로부터 판독할 것이다. 스캔 아웃 엔진(124)은 픽셀 데이터를 미변경 상태로 전달할 수 있거나, 스캔 아웃 엔진(124)은 DA 변환 및/또는 다른 신호 처리 알고리즘들을 적용하여 데이터를 디스플레이 장치로의 전달을 위해 적절하게 포매팅할 수도 있다. 일부 실시예들에서는, DA 변환을 제외한 프레임마다의 모든 처리가 픽셀 데이터를 프레임 버퍼(227)에 기입하기 전에 후처리 오브젝트(134)에 의해 수행되는데; 다른 실시예들에서는, 스캔 아웃 엔진(124)이 일부 처리를 수행할 수도 있다.

스캔 아웃 엔진(124)은 바람직스럽게도 각각의 프레임을 위한 픽셀들의 전달을 디스플레이 장치의 요구 사항들에 일치시키고 (업계에 수평 리트레이스(horizontal retrace)로서 공지되어 있는) 스크린 픽셀들의 로우의 끝 및 (업계에 수직 리트레이스로서 공지되어 있는) 스크린의 끝과 같은 이벤트들을 검출할 수 있다. 종래 기술들이 스캔 아웃 엔진(124)을 구현하는데 사용될 수도 있다.

다른 실시예에서, 스캔 아웃 엔진(124)은 교대하는 프레임들 상의 버퍼들(X 및 Y)을 판독하고, 후처리 오브젝트(134)는 교대하는 프레임들상의 버퍼들(Y 및 X)에 기입한다. 이 실시예에서, BSEL 저장 영역(208)은 스캔 아웃 엔진(124) 및 후처리 오브젝트(134)의 동작들을 동기화하기 위해 초기화시에만 사용되는 세마포어를 저장하는데 사용될 수 있다. 예를 들어, 스캔 아웃될 제1 버퍼(예를 들어, 버퍼 X)를 위한 세마포어는 BSEL 저장 영역(208)에 저장될 수 있다. 시스템 설정시에, 예를 들어, 단일 비트일 수 있는 이 세마포어는 스캔 아웃 엔진(124)이 버퍼 X를 판독하는 것을 금지하는 로킹(또는 획득) 상태로 설정된다. 후처리 오브젝트(134)가 제1 프레임을 버퍼 X에 기입한 후, 후처리 오브젝트(134)는 세마포어를 해제하여, 스캔 아웃 엔진(124)에 의한 버퍼 X로부터의 판독 동작들을 가능하게 한다. 그후, 세마포어는 그것의 해제 상태를 유지할 수 있고, 적당한 동기화가 유지될 것이다.

동기화 기술들

스캔 아웃 엔진(124) 및 후처리 오브젝트(134)의 동작들은 매 프레임 기반(per-frame basis)으로 동기되는 것이 바람직스러운데, 이것은, 스캔 아웃 엔진(124)에 의해 디스플레이 버퍼(127)로부터 판독되는 각각의 프레임을 위해, 후처리 오브젝트(134)가 하나의 새로운 프레임을 디스플레이 버퍼(127)에 기입한다는 것을 의미한다. 예를 들어, 후처리 오브젝트(134)는 바람직스럽게도, 스캔 아웃 엔진(124)이 프레임 버퍼 Y로부터 일 프레임을 판독하는 동안 일 프레임을 프레임 버퍼 X에 기입한다. 스캔 아웃 엔진(124)이 프레임 버퍼 Y의 끝에 도달할 때, 그 것은 프레임 버퍼 X를 판독하는 것으로 스위칭하는 한편, 후처리 오브젝트(134)는 일 프레임을 프레임 버퍼 Y에 기입한다.

일 실시예에서, 이러한 동기화는 스캔 아웃 엔진(124)에 의해 "trigger"경로(246)에 선언(assert)되는 트리거 신호를 사용해 핸들링된다. 트리거 신호는, 바람직스럽게는, EOF 이벤트와 고정된 시간 관계에서(예컨대, EOF 이벤트 전후의 정해진 시간에), 매 프레임마다 하나씩 발생된다. EOF 이벤트는, 수직 리트레이스(또는 수직 동기 신호(vsync)) 이벤트, 현재의 프레임 버퍼로부터 마지막(또는 마지막으로부터 N번째) 픽셀을 판독하는 것 등과 같이, 프레임의 끝이거나 프레임의 끝이 가깝다는 것을 스캔 아웃 엔진(124)에 알려주는 임의의 이벤트일 수 있다. 트리거 신호의 선언(assertion)에 응답하여, 멀티프로세서(120)는 픽셀 데이터의 새로운 일 프레임을 발생시키기 위해 후처리 오브젝트(134)를 활성화한다. 새로운 프레임이 발생된 후, 멀티프로세서(120)는, 트리거 신호의 후속 선언까지, 후처리 오브젝트(134)를 비활성화한다.

버퍼가 스캔 아웃되고 있는 동안 후처리 오브젝트(134)가 프레임 버퍼(227)에 기입하는 것을 방지하기 위해 버퍼 동기화가 제공되는 것이 바람직스럽다. 일 실시예에서는, 후처리 오브젝트(134)가 새로운 프레임을 발생시키는 것을 완료할 때마다, 후처리 오브젝트(134)는, "BSEL_write" 경로(242)에 의해 지시되는 바와 같이, 새로운 프레임을 위한 프레임 버퍼(227;예를 들어, X 또는 Y)의 식별자를 BSEL 저장 영역(208)에 기입한다. 각 프레임의 시작에서, 스캔 아웃 엔진(124)은, "BSEL_read" 경로(244)에 의해 지시되는 바와 같이, BSEL 저장 영역(208)에 액세스 하는 것에 의해 어떤 프레임 버퍼(227)를 판독할 것인지 판정한다. BSEL 저장 영역(208)이 매 프레임마다 한번씩 판독되고 매 프레임마다 한번씩 기입되기만 한다면, 이 동작들의 타이밍은 레이스 조건들(race conditions)을 방지하도록 조정될 수 있다. 예를 들어, 스캔 아웃 엔진(124)은, 후처리 오브젝트(134)가 후속 프레임을 발생시키고 BSEL 값을 업데이트하는 것을 종료한 후의 시점에서, 트리거 신호를 발생시키기 직전에, BSEL 저장 영역(208)에 액세스할 수 있다.

렌더링 오브젝트(132) 및 후처리 오브젝트(134)의 동작들은 서로 동기되지 않는 것이 바람직스러운데, 이는 후처리 오브젝트(134)는 디스플레이 카덴스(즉, 스크린 리프레시 레이트)에서 프레임들을 발생시키는 한편 렌더링 오브젝트(132)는 디스플레이 카덴스와는 상이할 수 있는(예를 들어, 디스플레이 카덴스보다 좀더 느릴 수 있는) 렌더링 카덴스에서 이미지들을 발생시키기 때문이다. 일부 실시예들에서, 버퍼 동기화 기술들은, 후처리 오브젝트(134)가 일 이미지(또는 이미지들의 그룹)를 사용해 프레임의 일부분을 발생시키고 상이한 이미지(또는 이미지들의 그룹)를 사용해 동일한 프레임의 다른 부분을 발생시키는 상황들을 방지할 뿐만 아니라 후처리 엔진(132)이 이미지 버퍼(226)로부터 판독하고 있는 동안 렌더링 오브젝트(132)가 버퍼(226)에 기입하는 상황들을 방지하는데도 사용된다. 특히, 이미지 버퍼들(226)로의 액세스는, 후처리 오브젝트(134)가 렌더링 오브젝트(132)에 의해 현재적으로 기입되고 있는 이미지 버퍼(226)로부터 판독하지 않도록 그리고 렌더링 오브젝트(132)가 후처리 오브젝트(134)에 의해 여전히 요구되고 있는 이미지 버퍼(226)에 겹쳐쓰기(overwrite)하지 않도록 제어될 수도 있다. 버퍼 동기화 메커 니즘은 부가적으로, 후처리 오브젝트(134)에 의해 판독될 이미지 버퍼들의 선택에서의 임의 변화들이 후처리 프레임들 사이에서 발생한다고 규정할 수 있고; 이것은 디스플레이된 프레임의 상이한 부분들에서의 분열 또는 다른 시각적 불일치들(other visual inconsistencies)을 방지하는데 도움이 된다.

도 2는, 제어 신호 경로들(232, 234, 236)을 통해, 비대칭 세마포어들 및 버퍼 인덱스에 기초한 이미지 버퍼들(226)을 위한 버퍼 동기화 기술을 예시한다. 렌더 버퍼(126)의 세마포어 영역(206)은, 이미지 버퍼(226)에 존재할 수도 있는 임의의 선행 프레그먼트 데이터로써 후처리 오브젝트(134)가 종료될 때까지 새로운 프레그먼트 데이터가 이미지 버퍼(226)에 기입되지 않도록, 렌더링 오브젝트(132)에 의해 이미지 버퍼들(226) 각각으로의 액세스를 제어하기 위한 세마포어들(207;SA, SB, SC)을 저장한다. 각각의 세마포어(207)는, 후술되는 바와 같이 액세스 제어를 위해 사용되는 "획득(acquired)" 및 "해제(released)" 상태들을 갖는 것이 바람직스럽다. 일반적으로, 전통적인 세마포어 데이터 구조들 및 포맷들이 세마포어들(207)을 구현하도록 적응될 수도 있다.

렌더링 오브젝트(132)가 새로운 이미지를 위한 프레그먼트 데이터를 기입하는 것을 시작하기 전에, 렌더링 오브젝트(132)는, "acquire" 경로(232)에 의해 지시되는 바와 같이, 그 프레그먼트 데이터가 기입될 이미지 버퍼(226)에 대응되는 세마포어(207)를 획득하고자 한다. 렌더링 오브젝트(132)는, 후처리 오브젝트(134)가 그것을 해제한 이후에만 이미지 버퍼를 위한 세마포어를 획득할 수 있고; 다음에서 부연되는 바와 같이, 세마포어를 해제하는 단계는, 후처리 오브젝 트(134)가 연관된 이미지 버퍼를 더 이상 요구하지 않을 때에 발생한다. 세마포어(207)가 즉각적으로 획득될 수 없으면, 렌더링 오브젝트(132)는 세마포어가 획득될 수 있는 그러한 시점까지 그것의 커맨드 처리를 중단하고 대기한 다음, 렌더링을 계속한다. 후처리 오브젝트(134)가 디스플레이 카덴스에서(즉, 매 스캔 아웃 프레임마다 하나씩) 버퍼들을 해제하는 경우, 일반적으로, 렌더링 오브젝트(132)는 대기할 필요가 없을 것이다. 다른 실시예들에서는, 새로운 이미지들을 디스플레이 카덴스보다 빠른 레이트들에서 렌더링하기를 원치 않는 한, 렌더링 오브젝트(132) 실행시의 임의 지연이 수용 가능할 수도 있다.

렌더링 오브젝트(132)가 이미지를 위한 프레그먼트 데이터를 이미지 버퍼들(226) 중 하나에 기입하는 것을 종료할 때, 렌더링 오브젝트(132)는, "release" 경로(234)에 의해 지시되는 바와 같이, 그 버퍼를 위한 세마포어(207)를 해제한다. 세마포어(207;예를 들어, 세마포어 SA)를 해제하는 것은, 세마포어(207)가, 후술되는 바와 같이, 후처리 오브젝트(134)에 의해 해제되는 그러한 시점까지, 렌더링 오브젝트(132)가 연관된 버퍼(226;예를 들어, 버퍼 A)에 액세스하는 것을 방지한다. 세마포어(207)를 해제한 후에(또는 세마포어(207)를 해제하는 것과 동시에), 렌더링 오브젝트(132)는, "index_write" 경로(236)에 의해 지시되는 바와 같이, 새로운 인덱스 값을 PP 커맨드 버퍼(129)에 기입한다. 인덱스 값은 방금 완료된 이미지 버퍼(226)를 식별하고, 이 이미지 버퍼(226)가 이제 처리에 이용 가능하다는 것을 후처리 오브젝트(134)에 시그널링한다.

프레임 각각의 시작 이후에, 후처리 오브젝트(134)는, "index_read" 경 로(238)에 의해 지시되는 바와 같이, PP 커맨드 버퍼(129)로부터 인덱스 값을 판독한다. 일 실시예에서, 인덱스는 PP 커맨드 버퍼(129)에서의 커맨드들 중 하나의 인수(argument)로서 판독된다. 인덱스 값에 기초해, 후처리 오브젝트(134)는, "release" 경로(240)에 의해 지시되는 바와 같이, 그것이 후처리를 위해 어떤 이미지 버퍼들(226)을 필요로 하고 불필요한 임의의 이미지 버퍼들(226)을 위해 세마포어들(207)을 해제하는지를 판정한다. 후처리 오브젝트(134)에 의해 세마포어들(207)이 해제되는 이미지 버퍼들(226)이 렌더링 오브젝트(132)에 의한 사용에 이용될 수 있다.

인덱스 값이 마지막 프레임 이후로 변경되지 않았다면, 후처리 오브젝트(134)는 대기 또는 정지하지 않는 것이 바람직스럽다. 일부 실시예들에서, 후처리 오브젝트(134)는, 인덱스 값의 변경 여부에 상관없이 동일한 후처리를 수행하고; 인덱스 값이 변경되지 않았다면, 후처리 오브젝트(134)에 의해 발생된 새로운 프레임이 선행 프레임과 동일할 수도 있다. 다른 실시예들에서는, 후처리 오브젝트(134)의 일부 또는 모든 활동이 인덱스의 변경 여부에 따라 조건화될 수도 있다. 그러한 실시예들에서, 후처리 오브젝트(134)는 바람직스럽게도 선행 프레임에 사용된 인덱스 값을 저장하고 그것을 PP 커맨드 버퍼(129)에서의 인덱스 값과 비교하여 인덱스의 변경 여부를 판정한다. 인덱스가 변경되지 않았다면, 후처리 오브젝트(134)는 단순하게 아무 것도 수행하지 않을 수 있거나 명령어들의 상이한 세트를 실행할 수도 있다.

여기에서의 동기화 메커니즘은, 세마포어들(207)이 렌더링 오브젝트(132)의 동작을 멈추게 할 수는 있지만 후처리 오브젝트(134)의 동작을 멈추게 할 수는 없다는 점에서 "비대칭(asymmetric)"이다. 이러한 정렬은, 렌더링 오브젝트(132)가 새로운 이미지들을 발생시키는 레이트에 상관없이, 디스플레이 카덴스에서 새로운 프레임들이 발생되게 한다. 데드록(deadlock)을 방지하기 위해, 이미지 버퍼들(226)의 수는, 후처리 오브젝트(134)에 의해 사용되지 않는 하나 이상의 이미지 버퍼(226)가 항상 존재할 정도로 충분히 크게 선택되는 것이 바람직스럽다. 예를 들어, 후처리 오브젝트(134)가 수행해야 할 특정 동작(들)을 위해 M개의 최근 이미지들을 요구한다면, 적어도 (M+1)개의 이미지 버퍼들(226)이 제공될 것이다. 원한다면, 좀더 많은 이미지 버퍼들(226)이 제공될 수도 있다. 추가적인 이미지 버퍼들을 제공하는 것으로 인해, 렌더링 엔진은 스캔 아웃 엔진의 훨씬 앞쪽에서 동작할 수 있다. 추가적인 이미지 버퍼들은, 원한다면, 렌더링 오브젝트(132)에 삼중으로 버퍼링된 렌더링(triple-buffered rendering)을 구현하는데도 사용될 수 있다.

여기에서 설명되는 특정한 동기화 기술들은 예시적이라는 것과 다른 기술들이 사용될 수도 있다는 것이 이해될 것이다. 일부 실시예들은, 디스플레이된 프레임들에서의 티어링(tearing)을 허용하면서, 버퍼 동기화를 완전히 생략할 수도 있다.

커맨드 스트림들

일부 실시예들에서, 렌더링 커맨드 스트림 및 후처리 커맨드 스트림은 상이하게 관리된다. 좀더 구체적으로는, 앞서 지적된 바와 같이, 렌더링 커맨드 버 퍼(128)는, 거기에서의 렌더링 커맨드들이 렌더링 오브젝트(132)에 의해 한번씩 실행되도록 구현되는 것이 바람직스럽고; 커맨드들의 새로운 세트는 렌더링될 각각의 이미지를 위해 렌더링 커맨드 버퍼(128)에 기입된다. 대조적으로, 후처리 동작들의 원하는 세트는 일반적으로 일 프레임에서 후속 프레임까지 변함이 없고, 각각의 프레임을 위해 후처리 커맨드들의 동일한 세트를 기입하는 것은 비효율적일 것이다. PP 커맨드 버퍼(129)가 무한 루프로 동작하는 경우, 새로운 후처리 커맨드들을 PP 커맨드 버퍼(129)에 기입하는 것은 좀더 복잡해진다. 후처리 오브젝트(134)의 실행은 그래픽 드라이버와 비동기적이고, 드라이버는 일반적으로, 후처리 오브젝트(134)가 임의의 소정 시점에서 실행 중인지의 여부 또는 루프에서의 어떤 커맨드가 실행되고 있는지를 알지 못한다.

따라서, PP 커맨드 버퍼(129)는 바람직스럽게도, 그래픽 드라이버가 후처리 커맨드들의 전체 프로그램을 커맨드 스트림으로서 PP 커맨드 버퍼(129)에 기입할 수 있도록 구현된다. 프로그램은, 동일한 프로그램이 모든 프레임을 위해 재실행될 수 있도록 하기 위해, 실행 이후에 PP 커맨드 버퍼(129)에 보존된다. 이와 같이, 새로운 후처리 커맨드들은, 후처리가 변경되어야 하는 경우에만 PP 커맨드 버퍼(129)에 보존된다.

이하에서는, 렌더링 커맨드 버퍼(128) 및 PP 커맨드 버퍼(129)를 위한 예시적 커맨드 스트림 구조들이 설명될 것이다.

도 3A는 본 발명의 실시예에 따라 렌더링 커맨드 버퍼(128)에 버퍼링될 수 있는 렌더링 커맨드 스트림(300)의 일부분을 개략적으로 예시한다. 각각의 새로운 이미지를 위해, 커맨드 시퀀스는, 진행되기 전에, 기입될 후속의 이미지 버퍼(226)를 위한 세마포어(207)(예를 들어, ACQ 커맨드(306)의 경우 버퍼 A를 위한 세마포어 SA, ACQ 커맨드(308)의 경우 버퍼 B를 위한 세마포어 SB)를 획득할 것을 렌더링 오브젝트(132)에 지시하는 "ACQ" 커맨드(306, 308)로써 시작한다. 상술된 바와 같이, 세마포어(207)가 획득될 수 없다면, 렌더링 오브젝트(132)는 그것이 획득될 수 있는 그러한 시점까지 대기한다.

"RCMD" 커맨드들(310, 312) 각각은 이미지를 렌더링하기 위한 커맨드들 및 데이터의 완전한 세트를 표현한다. 실제로, 임의 갯수의 렌더링 커맨드들이 매 이미지마다 포함될 수도 있다. 예를 들어, RCMD 커맨드들(310, 312)은 버텍스(또는 지오메트리) 처리 커맨드들, 래스터라이징 커맨드들, 프레그먼트 셰이딩 커맨드들 등의 임의 조합을 포함할 수도 있다. RCMD 커맨드들(310, 312)도, 다양한 렌더링 커맨드들과 연관될 수 있는 적합한 데이터(예를 들어, 변환 행렬들, 버텍스들의 프리미티브들로의 그룹화들 등)를 포함할 수 있다. 일부 실시예들에서, 렌더링 커맨드들은 멀티프로세서(120)에 의한 실행에 적합한 마이크로명령어들로서 전달될 수도 있고; 다른 실시예들에서는, 실행 이전에 호스트(120)에 의한 커맨드들의 디코딩이 요구될 수도 있다. 일부 실시예들에서, 렌더링 커맨드들의 시퀀스는, 루프들, if-then 스테이트먼트들 등과 같은 흐름 제어 커맨드들도 포함할 수 있다. 일반적으로, RCMD 커맨드들(310, 312)은 사실상 종래의 것일 수 있고, 상세한 설명은, 본 발명을 이해하는데 중요하지 않으므로, 생략된다.

이미지 각각의 끝에는, 현재 이미지의 렌더링이 완전하다는 것을 지시하는 "FLIP" 커맨드(314, 316)가 존재한다. FLIP 커맨드에 응답하여, 렌더링 오브젝트(132)는 바람직스럽게도, 그것의 기입 타겟을 현재의 렌더링 버퍼로부터 후속의 렌더링 버퍼로(예를 들어, FLIP 커맨드(314)의 경우 버퍼 A로부터 버퍼 B로) 스위칭하고, 방금 완료된 렌더링 버퍼를 위한 세마포어(207;예를 들어, FLIP 커맨드(314)의 경우 세마포어 SA)도 해제한다. 세마포어(207)를 해제한 후, 렌더링 오브젝트(132)는 PP 커맨드 버퍼(129)에서의 인덱스 값을 방금 완료된 렌더링 버퍼(예를 들어, FLIP 커맨드(314)의 경우 버퍼 A)를 식별하는 새로운 값으로 업데이트한다. 또한, FLIP 커맨드의 처리는 카운터들 또는 렌더링 오브젝트(132)에 의해 보유될 수도 있는 다른 변수들을 리셋하는 단계도 포함할 수 있다. FLIP 커맨드에 응답하여, 다른 종래의 EOF 처리가 수행될 수도 있다.

도 3B는, 본 발명의 실시예에 따른, PP 커맨드 버퍼(129)에 저장될 수도 있는 후처리 프로그램(또는 스트림)(320)을 개략적으로 예시한다. 이 실시예에서, 프로그램(320)은, 인덱스의 인수가, 상술된 바와 같이, 렌더링 오브젝트(132)에 의해 기입되고 겹쳐쓰기되는 인덱스인 인덱스 커맨드(322); 하나 이상의 후처리("PCMD") 커맨드들(326, 328); 하나 이상의 위치("LOC") 커맨드들(330, 332); BSEL 업데이트("BUPD") 커맨드(334); 및 루프의 시작으로 복귀하기 위한 최종적인 무조건 점프("JMPB") 커맨드(336)를 포함하는 무한 루프를 구현한다.

처음으로 실행될 수도 있는 인덱스 커맨드(322)는 현재의 인덱스 값을 후처리 오브젝트(134)에 제공한다. 일부 실시예들에서, 후처리 오브젝트(134)는 현재의 인덱스 값을, 후처리 오브젝트(134)에 액세스 가능한 (도 2 또는 도 3B에 도시 되지 않은) 상태 레지스터에 저장될 수도 있는 가장 최근에 사용된 인덱스 값과 비교하고, 비교의 결과에 기초해, 추가적인 처리가 제어될 수도 있다. 예를 들어, 인덱스 값이 변경되지 않은 일부 경우들에서, 후속의 디스플레이 프레임은 현재의 디스플레이 프레임과 동일할 것이다. 그 경우, 후처리 오브젝트(134)는 새로운 프레임을 발생시키지 않을 수도 있고 BSEL 값을 변경되지 않은 위치(208;도 2)에 남길 수도 있어, 인덱스 값이 달라지는 그러한 시점까지, 스캔 아웃 엔진(124)은 단순히 동일한 프레임 버퍼(227)를 연속적으로 수차례 판독할 것이다. 다른 경우들에서는, 인덱스 값이 변경되지 않은 경우라 하더라도, 후처리 오브젝트(134)가, LCD 오버드라이브 값들을 조정하거나 페이드-인, 페이드-아웃, 또는 디졸브와 같은 전이 효과를 통해 진행하는 것과 같은, 몇몇 액션을 취하는 것이 바람직스러울 수도 있다. 다른 실시예들에서, 후처리 오브젝트(134)는, 인덱스 값의 변경 여부와 상관없이 동일한 커맨드들을 실행한다. 초기화시에, 인덱스 값은, 이미지들이 이미지 버퍼들(226)에 렌더링되지 않았다는 것을 지시하면서, 널 값으로 설정될 수 있고; 후처리 오브젝트(134)는 바람직스럽게도 널 값을 검출하고 적합한(예를 들어, 블랭크-스크린 값을 프레임 버퍼(227)에서의 모든 픽셀에 기입하는) 액션을 취한다.

PCMD 커맨드들(326, 328)은 수행될 다양한 후처리 동작들을 위한 명령어들을 표현한다. 실제로, 임의 갯수의 PCMD 커맨드들이 내용들(320)에 포함될 수도 있다. 상술된 RCMD(렌더링) 커맨드들에서와 같이, PCMD 커맨드들은 멀티프로세서(120)에 의한 직접적인 실행에 적합한 명령어들의 형태로 전달될 수도 있고; 다 른 실시예들에서는, 실행 이전에 호스트(120)에 의한 커맨드들의 디코딩이 요구될 수도 있다. 이번에도, RCMD 커맨드들의 경우에서와 같이, PCMD 커맨드들은 원하는 흐름-제어 커맨드들을 포함할 수도 있다(예를 들어, 일부 커맨드들은, 인덱스 엔트리(324)에서의 인덱스 값이 변경되었는지의 여부에 따라 조건화될 수도 있다).

다음에서 부연되는 바와 같이, 일부 실시예들에서, 후처리 오브젝트(134)는 렌더링 오브젝트(132)와 동일한 처리 엔진을 사용해 실행되고; 따라서, RCMD 커맨드들(310, 312;도 3A)로서 주어질 수 있는 커맨드들의 임의 시퀀스가 PCMD 커맨드들(326, 328)로서 주어질 수도 있다. 또한, 후처리 동작들에 특징적인 특수한 PCMD 커맨드들이 정의될 수도 있다. 원칙적으로, (앞서 언급된 일례들 중 어느 하나 또는 그 이상을 포함하는) 후처리 동작들의 임의 조합이 PCMD 커맨드들(326, 328)의 적당한 시퀀스를 통해 구현될 수도 있다. 일부 실시예들에서, PCMD 커맨드들(326, 328)은, LCD 오버드라이브 또는 커서 오버레이들과 같은, 매-프레임 기반으로 발생해야 하는 처리에만 사용된다. 그러나, 광범위한 후처리 동작들이 PCMD 커맨드들(326, 328)을 통해 프로그램될 수도 있다는 것을 알 수 있을 것이다.

LOC 커맨드들(330, 332)은 이미지 버퍼들(226) 중 하나(또는 그 이상)를 특정한 PCMD 커맨드 또는 PCMD 커맨드들의 그룹을 위한 데이터 소스로서 식별하기 위한 인덱스 엔트리(324)와 함께 사용된다. 상술된 바와 같이 FLIP 커맨드에 응답하여 렌더링 오브젝트(132)에 의해 기입되는 인덱스 엔트리(324)는 가장 최근에 완료된 이미지 버퍼(226)를 식별한다. LOC 커맨드들(330, 332)은, 적절하게, 가장 최근에 완료된 이미지 버퍼(226) 또는 앞서 완료된 이미지 버퍼들(226)을 의미할 수 있다. 일 실시예에서, LOC 커맨드들(330, 332)은 가장 최근에 완료된 이미지 버퍼에 관련한 이미지 버퍼들(226)을 식별한다. 예를 들어, 0, 1, ..., N-1의 인덱스 값들이 할당되고 인덱스 엔트리(324)에서의 값이 R로써 지시되는 N개의 이미지 버퍼들(226)이 존재한다고 가정한다. LOC 커맨드는 가장 최근에 완료된 이미지 버퍼를 식별하기 위한 LOC = R의 형태일 수 있거나 두번째로 최근에 완료된 이미지 버퍼를 식별하기 위한 LOC = (R-1) mod N의 형태일 수 있다는 식이다. 상대적 기준들이 사용되는 경우, 인덱스 엔트리(324)가 업데이트될 때, LOC 커맨드들(330, 332)을 변경하는 것은 불필요하다. 일부 실시예들에서는, 모든 PCMD 커맨드들에 적용될 수 있는 하나의 LOC 커맨드 또는 한 세트의 LOC 커맨드들이 존재할 수도 있다.

BUPD 커맨드(334) 및 JMPB 커맨드(336)는 후처리 루프를 종결한다. BUPD 커맨드(334)는, 새롭게 기입된 프레임 버퍼(227)의 식별자를 BSEL 저장 위치(208)에 기입할 것을 후처리 오브젝트(134)에 지시하고, 그에 따라, 스캔 아웃 엔진(124)은 그것을 후속 프레임으로서 판독할 것이다. JMPB 커맨드(336)는, 점선 화살표(338)에 의해 지시되는 바와 같이, 프로그램(320)의 시작으로 제어를 되돌린다. 후술되는 바와 같이, JMPB 커맨드(336) 또한 후처리 프로그램을 위한 ("프레임 완료 이벤트(frame completion event)"라고도 하는) 완료 신호로서 기능하는데; 다시 말해, 일단 JMPB 커맨드(334)가 후처리 오브젝트(134)에 의해 조우되고 나면, 그것은 후속의 트리거 이벤트를 대기하기 위해 휴지 상태로 진입한다. 예를 들어, 후술되는 바와 같이, 후처리 오브젝트(134)는 JMPB 커맨드(336) 도달시에 컨택스트-전환될 수도 있다.

일부 실시예들에서, PCMD 커맨드들(326, 328) 중 일부는 상태 파라미터들과 연관될 수도 있다. 예를 들어, 확대 파라미터는 확대 또는 축소를 구현하는 PCMD 커맨드와 연관될 수 있고, 또는 오버레이 사이즈 또는 위치 파라미터들은 합성을 구현하는 PCMD 커맨드와 연관될 수도 있다. 이 파라미터들은 후처리 커맨드 스트림에 포함될 수 있거나, 이 파라미터들은 후처리 오브젝트(134;예를 들어, PP 커맨드 버퍼내의 파라미터 섹션, 별도 버퍼, 또는 실행 코어에서의 파라미터 레지스터들)에 액세스 가능한 상이한 위치에 기입될 수도 있다. 파라미터 업데이트들은 후처리 커맨드 스트림을 재기입하거나, 후처리 커맨드 스트림을 선택적으로 변경하거나, 버퍼 또는 레지스터의 내용들을 변경하는 것에 의해 핸들링될 수 있다. 커맨드들 및 파라미터들의 변경은 다음에서 부연된다.

여기에서 설명되는 프로그램 스트림들은 예시적이라는 것과 변형들 및 변경들이 가능하다는 것을 이해할 수 있을 것이다. 임의의 적당한 커맨드 세트가 RCMD 및 PCMD 커맨드들을 구현하는데 사용될 수도 있다. JMPB 커맨드 대신에, 다른 조건들이 후처리 프로그램의 끝을 나타내기 위한 프레임 완료 이벤트들로서 사용될 수도 있다. 예를 들어, PP 커맨드 버퍼가 (도 1에서의 렌더링 커맨드 버퍼(128)를 참조하여 상술된 포인터들과 유사한) "put" 포인터 및 "get" 포인터를 사용해 구현된다면, "put" 포인터는 프로그램에서의 마지막 커맨드의 위치를 참조할 것이다. "get" 포인터가 "put" 포인터와 동일한 위치를 참조할 때, 마지막 커맨드에 도달되었다. 이 사건은, 후처리 오브젝트가 프레임을 완료했다는 것을 지시하는 프레임 완료 이벤트로서 사용될 수도 있다. 다른 실시예들에서는, 프레임을 위한 후처리의 완료과 고유하게 연관된 임의 이벤트 또는 조건이 프레임 완료 이벤트로서 사용될 수도 있다.

멀티프로세서

도 4는 본 발명의 실시예에 따른 멀티프로세서(120)의 간략화된 블록도이다. 멀티프로세서(120)는 조정 유닛(402) 및, 컨택스트 관리자(406)를 포함하는 실행 코어(404)를 포함한다.

실행 코어(404)는 일반적인 종래의 설계일 수 있고 임의의 원하는 마이크로아키텍처 및/또는 명령어 세트를 구현할 수도 있다. 일부 실시예들에서, 실행 코어(404)는, 인입하는 커맨드들을 기능 유닛들을 위한 실행 가능 명령어들로 디코딩하고, 각각의 명령어를 위해 요구되는 피연산자들을 식별 및 수집하며, 명령어들을 기능 유닛들로 발행하고, 결과들을 다른 기능 유닛들로 또는 (명시적으로 도시되지 않은) 레지스터 파일로 포워딩하기 위한 연관된 제어 로직(407)과 함께, 다양한 연산들(덧셈, 곱셈, 벡터 계산, 수학 함수들, 필터링 알고리즘들, 메모리 액세스 등)을 수행하기 위한 다수의 기능 유닛들(405)을 포함한다. 실행 코어(404)는 하드웨어 상태의 양상들을 보유하는 다양한 다른 레지스터들을 포함할 수도 있다. 또한, 실행 코어(404)는 (도 1에 도시된 바와 같이 그래픽 메모리(116)에 위치할 수 있는) 렌더 버퍼들(126) 및 디스플레이 버퍼들(127)에 액세스하도록 구성된다. 일부 실시예들에서는, 다수의 병렬 실행 코어들(404)이 제공될 수도 있는데, 각각의 코어(404)는 화면, 이미지, 또는 프레임의 상이한 부분에 대해 연산한다. 실행 코 어(404)의 특정 아키텍처가 본 발명에 중요한 것은 아니다.

일 실시예에서, 실행 코어(404)는 2개의 독립적인 처리 채널들: 후처리 오브젝트(134;도 1)를 구현하는 HPC(high priority channel) 및 렌더링 오브젝트(132)를 구현하는 NPC(normal priority channel)를 지원한다. 컨택스트 관리자(406)에 의해 별도의 아키텍처 상태(컨택스트)가 각각의 채널을 위해 보유된다. 좀더 구체적으로, NPC 컨택스트 블록(408)은 NPC를 위해 저장된 아키텍처 상태를 포함하고, HPC 컨택스트 블록(410)은 HPC를 위해 저장된 아키텍처 상태를 포함한다. 아키텍처 상태는 레지스터들 또는 적당한 다른 하드웨어에 저장될 수도 있다.

컨택스트 관리자(406)는, 실행 코어(404)의 기능 유닛들(405) 및 제어 로직(407)에, 현재 활성인 채널을 위한 적합한 아키텍처 상태로의 액세스를 제공하고, 그에 따라, 그것의 처리 동안 몇몇 시점에서 스위칭되는 채널은 다시 스위칭될 때 동일한 시점에서 재개할 수 있다. 일부 실시예들에서, 실행 코어(404)는 (도 4에 도시되어 있지 않은) 활성 레지스터 세트를 갖고, 컨택스트 관리자(406)는 먼저 "선행(old)" 채널(예를 들어, HPC)의 아키텍처 상태를 활성 레지스터 세트로부터 적합한 컨택스트 블록(예를 들어, HPC 컨택스트 블록(410))으로 복사한 다음, "새로운(new)" 채널(예를 들어, NPC)의 아키텍처 상태를 적합한 컨택스트 블록(예를 들어, NPC 컨택스트 블록(408))으로부터 활성 레지스터 세트로 복사하는 것에 의해 (예를 들어, HPC로부터 NPC로의) 채널 스위치를 실행한다. 다른 실시예들에서, 실행 코어(404)는 NPC 컨택스트 블록(408)이나 HPC 컨택스트 블록(410) 중 어느 하나에서의 대응되는 레지스터에 선택 가능하게 액세스할 수 있고, 컨택스트 관리 자(406)는 컨택스트 의존적인 방식으로 실행 코어(404)를 적합한 레지스터로 유도한다. 컨택스트 스위칭의 특정 구현이 본 발명에 중요한 것은 아니며; 일부 실시예들에서는, 충분히 빠른(예를 들어, 300 마이크로초 또는 좀더 빠른) 컨택스트 스위칭을 제공하는 임의 구현이 사용될 수도 있다.

조정 유닛(402)은, 어떤 채널이 임의의 소정 시점에서 활성이어야 하는지를 판정한다. 일 실시예에서, 조정 유닛(402)은 렌더링 커맨드 버퍼(128)로부터 후보 커맨드(candidate command)를 수신하는 NPC 입력(412) 및 후처리 커맨드 버퍼(129)로부터 후보 커맨드를 수신하는 HPC 입력(414)을 가진다. 또한, 조정 유닛(402)은 스캔 아웃 엔진(124)으로부터 (도 2를 참조하여 상술된) 트리거 신호를 수신하는 트리거 입력(416) 및 실행 코어(404)로부터 이벤트 신호들을 수신하는 이벤트 입력(418)을 가진다. 이 입력들에 기초해, 각각의 사이클 동안, 조정 유닛(402)은 HPC 또는 NPC 중 어느 하나를 활성 채널로서 선택하고, (경로(420)를 통해) 선택된 채널을 식별하는 컨택스트 신호를 그리고 (경로(422)를 통해) 선택된 채널을 위한 후보 커맨드를 실행 코어(404)로 송신한다. 선택되지 않은 후보 커맨드는, 그것이 선택될 수도 그렇지 않을 수도 있는 시점인 후속 사이클에서 다시 입력에 나타낸다. 실행 코어(404)가 그 커맨드를 위한 정확한 컨택스트를 가질 때에, 선택된 커맨드들이 실행된다는 것을 보장하기 위해, (도 4에 도시되지 않은) 적당한 타이밍 및 제어 회로가 사용될 수도 있는데; 그러한 회로는 일반적으로 종래의 설계일 수 있다.

도 5는 조정 유닛(402)에서 구현될 수 있는 선택 로직 프로세스(500)의 흐름 도이다. 이 실시예에서, 스캔 아웃 엔진(124)은 각각의 수직 리트레이스(retrace)(또는 다른 EOF) 이벤트와 거의 동시에 경로(424)상에 트리거 신호를 발생시킨다. 후처리 커맨드 버퍼(129)는, 도 3B에 도시된 바와 같이, 무조건 JMPB 커맨드를 갖춘 무한 루프를 위한 커맨드들을 포함한다.

초기화(단계 501) 이후에, 조정 유닛(402)은 NPC로 스위칭한다(단계502). 각각의 사이클에서, 조정 유닛(402)은 트리거 신호의 선언을 점검한다(단계 504). 트리거 신호가 선언되지 않는 한, 렌더링 커맨드 버퍼(128)로부터의 커맨드들이 계속해서 선택될 것이다(단계 506). 렌더링 커맨드 버퍼(128)에서의 커맨드들에 따라, 이미지들이 렌더링되고 프레그먼트 데이터가 렌더 버퍼(126)에 기입되는데; 다시 말해, 렌더링 오브젝트(132)가 동작한다. HPC는 이 시간 동안 비활성이다.

단계 504에서 트리거 신호가 검출될 때, 조정 유닛(402)은 컨택스트들을 HPC로 스위칭하고(단계 508), PP 커맨드 버퍼(129)로부터 커맨드들을 선택하기 시작한다(단계 510). 조정 유닛(402)은, 단계 512에서 무조건 JMPB 커맨드가 검출될 때까지, 계속해서 PP 커맨드 버퍼(129)로부터 커맨드들을 선택한다. PP 커맨드 버퍼(129)에서의 커맨드들에 따라, 렌더 버퍼(126)에서의 프레그먼트 데이터에 대해 후처리가 수행되고, 결과로서의 스크린 픽셀 데이터는 디스플레이 버퍼(127)에 기입되는데; 다시 말해, 후처리 오브젝트(134)가 동작한다. 프레임을 위한 후처리의 완료는, 상술된 바와 같이, JMPB 커맨드에 의해 지시된다. 일단 이 커맨드가 검출되고 나면(단계 512), 그것은 코어(404)로 포워딩되고(단계 514), 이후에, 조정 유닛(402)은 단계 502로 복귀하며 NPC 컨택스트로 스위칭한다. 일부 실시예들에서, JMPB 커맨드는 조정 유닛(402)에만 영향을 미치고 코어(404)로 포워딩되지 않는다. 그 지점에서, 렌더링 오브젝트(132)가 재개한다.

프로세스(500)는, 후처리가 디스플레이 카덴스에서 수행될 수 있도록 하기 위해 디스플레이 프레임 레이트(예를 들어, 80 Hz)에 대응되는 구간들에서 렌더링을 일시 중지한다. 일반적으로, 후처리를 위한 렌더링의 이러한 주기적 일시 중지는, 후처리에 의해 소비되는 (그에 따라 렌더링에 이용 불가능한) 시간이, 원하는 스피드(예를 들어, 30 Hz)에서 새로운 이미지들이 렌더링될 수 없을 정도로 충분히 길지 않다면, 그래픽 서브시스템의 전반적인 성능에 부정적인 영향을 미치지 않는다. 현재의 실행 코어들 및 통상적인 후처리 동작 시퀀스들에서 이용 가능한 처리 능력이 주어지면, 수용 가능한 성능이 유지될 수 있다.

여기에서 설명되는 멀티프로세서 및 조정 로직은 예시적이라는 것과 변형들 및 변경들이 가능하다는 것을 알 수 있을 것이다. "컨택스트 스위칭"은 여기에서, 제1 스트림에서의 임의 위치에서 명령어들의 일 스트림으로부터 다른 스트림으로 스위칭한 다음 사실상 동일한 위치에서 제1 스트림으로 복귀할 수 있는 프로세서의 동작을 설명하기 위한 일반적인 용어로 사용되는데; 이 용어는 임의의 특정한 프로세서 아키텍처로 제한된다. 종래의 멀티스레딩 아키텍처들(multithreading architectures)을 포함하는 임의의 멀티태스킹 아키텍처가 이용될 수도 있고, 임의의 메커니즘이 일시적인 휴지 프로세스 또는 컨택스트의 상태를 보존하는데 사용될 수도 있다. 또한, HPC가 디스플레이 카덴스에 의해 판정되는 스케줄에 따라 새로운 프레임을 발생시키는 것을 신뢰 가능하게 종료할 수만 있다면, HPC에 NPC보다 높은 절대적 우선 순위가 주어질 필요는 없다. 여기에서 설명되는 일례의 조정 유닛은 이벤트 입력(418)을 사용하지 않는다는 것에도 주의해야 하는데; 상이한 조정 로직이 이 입력을 사용할 수도 있다. 예를 들어, 후처리 오브젝트(134)는, 그것이 프레임을 종료했다는 것을 조정 유닛(402)에 통지하기 위해 입력 경로(418)상에 이벤트 신호를 발생시킬 수 있다.

다른 실시예에서, 렌더링 오브젝트 및 후처리 오브젝트는 별도의 버퍼 판독 경로들을 가진 독립적인 처리 엔진들을 사용해 구현될 수도 있다. 이 실시예에서, 렌더링 오브젝트 및 후처리 오브젝트는 병렬로 실행할 수 있고, 이 오브젝트들 사이의 컨택스트-스위칭은 요구되지 않는다.

후처리 프로그램 변경하기

상술된 실시예에서, PP 커맨드 버퍼(129)는 일반적으로 매 프레임 기반으로 업데이트되지 않는다. PP 커맨드 버퍼(128)는, 예를 들어, 도 1의 CPU(102)에서 동작중인 그래픽 드라이버에 의해, 후처리 오브젝트(134)가 휴지인 임의 시점에서, 업데이트될 수 있지만, 그러한 업데이트들은 임의의 특정 이미지 디스플레이와 동기되지 않는다. 대신에, PP 커맨드 버퍼(129)로의 업데이트들은 일반적으로, 업데이트 이후의 후속 프레임에 의해 효과가 나타난다. 다수 업데이트들이 이루어진다면, 모든 업데이트들이 동일한 프레임에 대해 효과를 나타낼 것이 보장되지 않는다.

다른 실시예들에서, 후처리 동작들에서의 변화를 특정 이미지와 동기시키는 것은 불가능하다. 또한, 이러한 선택적 사양은, 다수 업데이트들이 동일한 프레임 에 대해 효과를 나타내도록 제어될 수 있게 한다. 그러한 동기화는, 예를 들어, 다수의 PP 커맨드 버퍼들(129)을 구현하는 것에 의해 제공될 수 있는데, 이 경우, 렌더링 오브젝트(132)가, PP 커맨드 버퍼들(129)의 내용 뿐만 아니라 임의의 소정 시점에서 어떤 PP 커맨드 버퍼(129)가 판독되어야 하는지의 선택도 제어한다.

도 6은 다수의 PP 커맨드 버퍼들(602(1)-602(3))을 구현하는 본 발명의 실시예에 따른 멀티프로세서(600)의 간략화된 블록도이다. 멀티프로세서(600)는 조정 유닛(604) 및, 컨택스트 관리자(608)를 갖춘 실행 코어(606)를 포함한다. 이 컴포넌트들은 일반적으로, 상술된 조정 유닛(402), 실행 코어(404), 및 컨택스트 관리자(406)와 유사할 수 있고; 따라서, 호스트(600)는 후처리 오브젝트(134)를 구현하는 HPC 및 렌더링 오브젝트(132)를 구현하는 NPC를 제공한다. 또한, 멀티프로세서(600)는 PPC 커맨드 버퍼들(602(1)-602(3)) 사이의 선택을 제어하기 위한 추가 로직을 포함한다.

좀더 구체적으로, PP 커맨드 버퍼들(602(1)-602(3)) 각각은 선택 회로(예를 들어, 멀티플렉서;610)에 후보 후처리 커맨드를 공급한다. 선택 회로(610)는 호스트(600)의 PP 인덱스 레지스터(612)에 저장된 "PP 인덱스" 값에 응답하여 후보들 중 하나를 선택한다. 선택된 후보는 HPC 후보 명령어로서 조정 유닛(604)에 제시된다. 조정 유닛(604)은, 상술된 바와 같이, HPC와 NPC 후보 명령어들 사이를 선택할 수 있다.

PP 인덱스 레지스터(612)는 렌더링 커맨드 버퍼(614)를 통해 호스트(600)로 전달되는 렌더링 커맨드 스트림에 포함될 수 있는 특수 커맨드들에 응답하여 NPC에 의해 기입된다. 도 7은 적합한 커맨드들을 포함하는 렌더링 커맨드 스트림의 일부분을 예시한다. 스트림(700)에서, ACQ 커맨드(702), RCMD 커맨드들(704), 및 FLIP 커맨드(710)는 일반적으로 도 3A를 참조하여 상술된 커맨드들과 유사하다. PP 커맨드 버퍼 선택("SELPP") 커맨드(706) 및 PP 커맨드 버퍼 기입("WRPP") 커맨드(708)는 특정 이미지와 동기되는 후처리 동작들에서의 변화들을 구현한다.

좀더 구체적으로, SELPP 커맨드(706)는 기입될 PP 커맨드 버퍼들(602(1)-602(3)) 중 이용 가능한 하나를 선택할 것을 (NPC에 구현된) 렌더링 오브젝트(132)에 지시한다. 상술된 세마포어들(207;도 2)과 유사한 세마포어 메커니즘 또는 다른 제어 메커니즘들이, 렌더링 오브젝트가 후처리 오브젝트(134)에 의해 여전히 사용중인 PP 커맨드 버퍼(602)를 선택하는 것을 방지하는데 사용될 수도 있다.

WRPP 커맨드(708)에는 바람직스럽게도, 선택된 PP 커맨드 버퍼(602)에 기입될 (도 7에 명시적으로 도시되지 않은) 데이터가 후처리 프로그램(또는 그것에 관한 일부분)의 형태로 수반된다. 프로그램은, 원하는 바에 따라, 도 3B에 도시된 형태 또는 상이한 형태를 가질 수도 있다. 렌더링 오브젝트(132)는 연관된 프로그램을 도 6에 도시된 "PPC_write" 경로(616)를 통해 선택된 PP 커맨드 버퍼(602)에 기입하는 것에 의해 WRPP 커맨드(708)를 실행한다. 경로(616)는 프로그램 정보를 PP 커맨드 버퍼들(602(1)-603(3)) 중 하나로만 선택 가능하게 유도하기 위한 (도시되지 않은) 적당한 회로를 포함할 수도 있는데; 그러한 회로는 종래의 설계일 수 있다. 일부 실시예들에서는, 렌더링 오브젝트(132)에 의해 방금 완료된 이미지 버퍼를 식별하는 인덱스 엔트리 또한 WRPP 커맨드(708)의 실행 동안 선택된 PP 커맨 드 버퍼(602)에 기입된다.

그후, 렌더링 오브젝트(132)는 FLIP 커맨드(710)를 실행하고, 선택된 PP 커맨드 버퍼(602)의 식별자를 "PPI_write" 경로(618)를 통해 PP 인덱스 레지스터(612)에 기입한다. HPC가 활성인 동안 PP 인덱스 레지스터(612)로의 업데이트들이 효력을 발휘하지 않도록, 적합한 인터로크들(예를 들어, 조정 유닛(604)에 의해 제어되는 래치들 또는 전송 게이트들)이 경로(618)를 따라 제공될 수도 있다. 예를 들어, 렌더링 오브젝트(132)에 의한 PP 인덱스 기입 동작의 실행은, PP 인덱스 레지스터(612)가 후처리 오브젝트(134)에 의해 사용(로킹)중인 동안 지연될 수도 있다. 이 실시예에서, WRPP 커맨드는 적합한 인덱스 값을 선택된 PP 커맨드 버퍼(602)에 기입하는 단계를 포함할 수 있다는 것에 주의해야 하고; 별도의 인덱스 업데이트 동작은 요구되지 않는다.

(HPC에 구현된) 후처리 오브젝트(134)는 그것의 마지막 반복시에 어떤 PP 커맨드 버퍼(602)가 판독되었는지를 추적하고, "PPI_read" 경로(620)를 통한 PP 인덱스 레지스터(612)로의 판독 액세스도 가진다. 따라서, 후처리 오브젝트(134)는, (PP 인덱스 레지스터(612)에 의해 특정된) 현재의 PP 커맨드 버퍼(602)와 마지막으로 판독된 PP 커맨드 버퍼(602)가 동일한지의 여부를 판정할 수 있고; 그렇지 않다면, 후처리 오브젝트(134)는 마지막으로 판독된(last-read) PP 커맨드 버퍼(602)를 위한 세마포어를 언로킹하거나 마지막으로 재기입을 위해 판독된 PP 커맨드 버퍼(602)를 제거한다.

일부 실시예들에서, SELPP 커맨드(706) 및 WRPP 커맨드(708)는, 후처리 프로 그램이 변경되어야 하는 이미지들만을 위한 렌더링 커맨드 스트림(700)에 포함된다. 다른 프레임들에 대해, 이 커맨드들은 생략될 수도 있는데, 이 경우, FLIP 커맨드(710)는 바람직스럽게도 PP 인덱스 레지스터(612)에 저장된 값을 변경하지 않는다. 대신에, 현재의 PP 커맨드 버퍼(602)를 위한 인덱스 업데이트가 실행될 수도 있다. 이와 같이, 동일한 PP 커맨드 버퍼(602)가 임의 갯수의 연속적인 프레임들을 위해 사용될 수 있는데, 새로운 PP 커맨드 버퍼(602)는, 후처리 프로그램이 실제로 변경되는 경우에만 사용된다.

다른 실시예에서는, PP 커맨드 버퍼(602)에서의 후처리 프로그램이 완전히 재기입되는 것이 아니라 WRPP 커맨드들에 의해 점진적으로 업데이트된다. 예를 들어, 초기화시에, 각각의 PP 커맨드 버퍼(602)에는 동일한 "디폴트" 후처리 프로그램이 로딩될 수도 있다. 렌더링 오브젝트(132)는 프로그램의 일부분들(예를 들어, 다양한 동작들을 위한 파라미터들)을 필요에 따라 변경하고 인덱스 값을 업데이트한다. 상술된 SELPP 및 WRPP 커맨드들은, 예를 들어, 겹쳐쓰기될 선택된 PP 커맨드 버퍼(602)에서의 엔트리를 특정하는 WRPP 커맨드들 뿐만 아니라 새로운 커맨드들(또는 단순히 파라미터 값들)로써 이 실시예를 위해 적응될 수도 있다.

당업자들이라면, 다른 동기화 방식들도 가능하다는 것을 알 수 있을 것이다. 예를 들어, 어떤 PP 커맨드 버퍼가 다음으로 판독되어야 하는지에 관한 정보는, 원하는 바에 따라, 조정 유닛에, 메모리에, HPC 컨택스트에, 또는 다른 곳에 저장될 수도 있다.

다중 디스플레이 헤드들

업계에 공지되어 있는 바와 같이, 일부 GPU들은 다중 디스플레이 장치들을 구동하기 위해 다중 디스플레이 헤드들을 갖도록 설계된다. 상이한 디스플레이 장치들은 상이한 픽셀 또는 프레임 레이트들에서 동작할 수 있거나 상이한 픽셀 포맷 요구 사항들을 가질 수도 있으므로, 일반적으로 각각의 디스플레이 헤드를 위해 별도의 스캔 아웃 엔진이 제공된다.

도 8은, 본 발명의 실시예에 따른, (명시적으로 도시되지 않은) 디스플레이 장치 "0"를 구동하기 위한 제1 스캔 아웃 엔진(802(1)) 및 (이 또한 명시적으로 도시되지 않은) 디스플레이 장치 "1"을 구동하기 위한 제2 스캔 아웃 엔진(802(2))을 지원하는 멀티프로세서(804)를 예시하는 간략화된 블록도이다. 멀티프로세서(804)는 조정 유닛(806) 및, 컨택스트 관리자(810)를 포함하는 실행 코어(808)를 포함한다. 이 컴포넌트들은 일반적으로, 멀티프로세서(804)가 (여기에서 HPCO 및 HPC1으로 지시된) 2개의 HPC들 및 하나의 NPC를 지원한다는 것을 제외하면, 도 4에서의 대응되는 컴포넌트들과 유사할 수도 있다. 각각의 HPC는 상이한 후처리 오브젝트를 구현하는데; HPCO는 디스플레이 장치 "0"를 위한 것이고 HPC1은 디스플레이 장치 "1"을 위한 것이며; NPC는 양자의 후처리 오브젝트들에 의해 소비될 이미지들을 제공하는 인스턴스화된 렌더링 오브젝트를 포함한다. 일부 실시예들에서는, 다중 렌더링 오브젝트들이 존재할 수도 있는데, 렌더링 오브젝트들에 의해 발생되는 이미지들은, 원하는 임의 방식으로, 후처리 오브젝트들 중 하나 이상에 의해 소비된다. 따라서, 실행 코어(808)는 적어도 3개의 컨택스트들을 지원하고, 조정 유닛(806)은, 후술되는 바와 같이, 3가지 방식의 (또는 그 이상의) 조정을 수행한다.

각각의 스캔 아웃 엔진(802(1), 802(2))은 그것의 개개 디스플레이 장치를 위한 적합한 파라미터들(예를 들어, 픽셀 레이트, 프레임 레이트)에 의해 동작한다. 상이한 디스플레이 장치들을 위한 후처리 동작들이 상이할 수 있으므로, HPCO에 구현된 후처리 오브젝트는 바람직스럽게도 프레임들을 디스플레이 버퍼(820(1))에 기입하는 한편, HPC1에 구현된 후처리 오브젝트는 프레임들을 물리적으로 또는 논리적으로 분리된 디스플레이 버퍼(820(2))에 기입한다. 디스플레이 버퍼(820(1))는 스캔 아웃 엔진(802(1))에 의해 판독되고, 디스플레이 버퍼(820(2))는 스캔 아웃 엔진(802(2))에 의해 판독된다. HPCO 및 HPC1 양자는 동일한 렌더링 버퍼(822)로부터 판독할 수 있고 거기에 저장된 동일한 이미지 또는 상이한 이미지들을 판독할 수도 있지만, HPCO 및 HPC1 양자가 상이한 렌더링 버퍼들(822)로부터 판독할 수도 있다.

조정 유닛(806)은 렌더링 커맨드 버퍼(812)를 통해 NPC를 위한 후보 커맨드 스트림을, PP 커맨드 버퍼(814(1))를 통해 HPCO를 위한 후보 커맨드 스트림을, 그리고 PP 커맨드 버퍼(814(2))를 통해 HPC1을 위한 후보 커맨드 스트림을 수신한다. 일반적으로, 상이한 디스플레이 장치들을 위한 바람직한 후처리 동작들이 상이할 수도 있으므로, PP 커맨드 버퍼들(814(1), 814(2))이 상이한 후처리 프로그램들을 제공할 수도 있다.

조정 유닛(806)은 각각의 스캔 아웃 엔진(802)으로부터 독립적으로 트리거 신호들을 수신하는데; "trigger-O" 경로(824(1))는 스캔 아웃 엔진(802(1))으로부터의 트리거 신호들을 제공하고, "trigger-1" 경로(824(2))는 스캔 아웃 엔 진(802(2))으로부터의 트리거 신호들을 제공한다. trigger-0 신호에 응답하여, 조정 유닛(806)은 HPCO로 스위칭하는데, 이는, (다른 실시예들에서 상술된 바와 같이) 프레임의 완료로 진행하고, trigger-1 신호에 응답하여, 조정 유닛(806)은 HPC1으로 스위칭하는데, 이 또한, 프레임의 완료로 진행한다.

일부 경우들에서는, 중첩하는 트리거 이벤트들이 가능하다. 예를 들어, 조정 유닛(806)은 trigger-0 신호에 응답하여 HPCO로 스위칭한 다음, HPC0가 그것의 프레임을 완료하기 전에 trigger-1 신호를 수신한다. 일 실시예에서, 조정 유닛(806)은 HPCO가 그것의 프레임을 완료하게 한 다음, 즉각적으로, HPC1으로 스위칭한다. 또한, 유사한 로직이, trigger-1 신호가 처음으로 도달하는 또 하나의 중첩 상황을 핸들링하는 데 사용될 수도 있다. (2개의 디스플레이 장치들이 상이한 프레임 레이트들을 가진다면 좀더 빠른 프레임 레이트에서) HPCO 및 HPC1이 프레임을 각각 발생시키기 위해 요구되는 총 시간이 사실상 프레임 시간 미만이기만 하다면 그리고 수용 가능한 레이트에서 새로운 이미지들을 렌더링하기에 충분한 처리 시간이 NPC에 남겨지기만 한다면, 이 알고리즘은 효과적이다.

다른 실시예들에서는, 다양한 오브젝트들 중 일부 또는 전부가, 병렬 처리 용량을 증가시키면서, 별도 처리 엔진들에 구현될 수도 있다. 예를 들어, 3개 엔진들의 경우, NPC 및 2개의 HPC들이 별도 엔진들에 각각 구현될 수도 있다.

다른 실시예에서는, 2개의 스캔 아웃 엔진들 및 단일 HPC를 제공하는 것에 의해 다중 디스플레이 헤드들이 지원될 수 있는데, 스캔 아웃 엔진들 중 하나가 HPC를 배타적으로 사용한다. 나머지 디스플레이 헤드를 위한 스캔 아웃 엔진은, 원한다면, 종래의 특수 목적 회로들을 사용해 제한된 후처리 능력을 구현할 수도 있다. 또 다른 실시예에서, 단일 HPC는 2개(또는 그 이상의) 스캔 아웃 엔진들 중 어느 하나로부터의 트리거 신호들에 의해 트리거될 수 있다.

후처리의 일례들

앞서 지적된 바와 같이, 후처리는 광범위한 동작들을 포함할 수도 있다. 본 발명의 범위를 제한하지 않으면서, 이하에서는, 후처리 동작들의 일부 일례들이 설명될 것이다.

한가지 후처리 동작은, 상이한 버퍼들로부터의 이미지들이 서로에 대해 중첩되어 프레임을 발생시키는 합성(compositing)이다. 예를 들어, 도 9는 3개의 상이한 이미지 버퍼들로부터 발생되는 합성 프레임(900)을 예시한다. 배경 이미지 버퍼(902)는 배경 영역(904)에서의 픽셀들을 발생시키는데 사용되는 프레그먼트 데이터를 제공하고, 무비 이미지 버퍼(906)는 무비 영역(908)에서의 픽셀들을 발생시키는데 사용되는 프레그먼트 데이터를 제공하며, 커서 이미지 버퍼(910)는 커서 영역(912)에서의 픽셀들을 발생시키는데 사용되는 프레그먼트 데이터를 제공한다.

이 일례에서, 이미지들 중 어느 하나의 내용 및/또는 위치는 프레임에 따라 독립적으로 달라질 수 있고, 상이한 이미지들을 위한 업데이트 레이트가 상이할 수도 있다. 예를 들어, 영역(904)에서의 배경 이미지는 거의 변하지 않는 데스크탑 월 페이퍼일 수 있고, 영역(908)에서의 무비 이미지는 30 Hz 이상의 레이트에서 변할 수도 있으며, 커서 이미지 버퍼(910)의 내용 또한, 예를 들어, 현재의 시스템 활동을 지시하기 위해 사실상 실시간으로 변할 수도 있다. 사용자에 의해 조작되 는 포인팅 장치의 모션을 반영하기 위해, 커서 영역(912)의 위치 또한 사실상 실시간으로 변할 수도 있다.

본 발명의 실시예에 따르면, 합성 이미지들은 후처리 오브젝트를 위한 프레그먼트 데이터 소스들로서 다수의 독립적인 이미지 버퍼들(또는 이미지 버퍼들의 그룹들)을 공급하는 것에 의해 발생될 수 있다. 도 10은, 다수 이미지들을 독립적으로 발생시키도록 구성되는 멀티프로세서(1000)를 나타내는 블록도이다. 이 실시예에서, 멀티프로세서(1000)는 후처리 오브젝트를 구현하는 하나의 HPC 및 2개의 NPC들을 지원하는데: NPCF는 풀-스크린(full-screen) 이미지를 위한 렌더링 오브젝트를 구현하고, NPCC는 커서 이미지를 위한 렌더링 오브젝트를 구현한다. 도 10에는 2개의 NPC들이 예시되지만, 조합하는 것이 바람직스러울 수 있는 임의 갯수의 이미지 소스들을 발생시키기 위해 임의 갯수의 NPC들이 제공될 수도 있다는 것을 이해할 수 있어야 한다. 더 나아가, 오브젝트들은 임의 갯수의 별도 처리 엔진들을 사용해 구현될 수도 있는데; 예를 들어, 하나의 엔진이 3개의 오브젝트들 모두를 구현할 수 있거나, 별도 엔진이 각각의 오브젝트를 위해 제공될 수 있거나, 다수 엔진들이 매 오브젝트마다 제공될 수도 있다.

일반적으로 상술된 그래픽 메모리(116)와 유사할 수도 있는 그래픽 메모리(1002)는, 상술된 바와 같이, 각각이 다수 이미지들을 저장하는 것이 바람직스러운 2개의 렌더 버퍼들(1004, 1006)을 포함한다. 렌더 버퍼(1004)는 NPCF에 의해 렌더링되는 풀-스크린 이미지들을 위한 프레그먼트 데이터를 저장하는 한편, 렌더 버퍼(1006)는 NPCC에 의해 렌더링되는 커서 이미지들을 위한 프레그먼트 데이터를 저장한다. 커서 이미지들은 풀-스크린 이미지들보다 훨씬 적은 프레그먼트들을 포함할 수 있고; 따라서, 렌더 버퍼(1006)가 렌더 버퍼(1004)보다 훨씬 더 작을 수도 있다는 것에 주의해야 한다. 또한, 그래픽 메모리(1002)는 HPC에 의해 발생되는 프레임들을 위한 픽셀 데이터를 저장하는 디스플레이 버퍼(1008)를 포함한다.

호스트(1000)는 상술된 대응되는 컴포넌트들과 일반적으로 유사할 수 있는 조정 유닛(1010) 및 컨택스트 관리자(1014)를 갖춘 실행 코어(1012)를 포함한다. 이 경우, 컨택스트 관리자(1014)는 3개의 상이한 컨택스트들(NPCC 컨택스트(1011), NPCF 컨택스트(1013), 및 HPC 컨택스트(1015))을 저장하고, 조정 유닛(1010)은 3개의 상이한 컨택스트들 중에서 선택한다. 풀-스크린 이미지 및 커서 이미지를 위한 별도의 렌더링 커맨드 스트림들이 개개의 렌더링 커맨드 버퍼들((풀-스크린 이미지들을 위한) 1016 및 (커서 이미지들을 위한) 1018)을 통해 제공된다. 이들 렌더링 스트림들은 일반적으로 도 3A의 렌더링 스트림(300)과 유사할 수도 있다.

조정 유닛(1010)은 (상술된 바와 같이) 스캔 아웃 엔진(1030)으로부터의 트리거 신호들에 응답하여 HPC를 선택하고, HPC가 휴지일 때에는, NPCC와 NPCF 사이에서 선택한다. 라운드-로빈(round-robin) 선택, (예를 들어, "evt" 경로(1017)를 통해 실행 코어(1012)로부터 수신되는 이벤트 신호들에 기초한) 이벤트-구동 선택, 또는 다른 선택 알고리즘들이 사용될 수도 있다.

PP 커맨드 버퍼(1020)는 그것의 일례가 도 11에서 예시되는 후처리 프로그램을 공급한다. 후처리 프로그램(1100)은, 다수의 인덱스 엔트리들(1104, 1106)이 제공된다는 것을 제외하면, 일반적으로 도 3B의 후처리 프로그램(320)과 유사하다. 인덱스 엔트리(1104)는 새로운 커서 이미지의 완료시에 NPCC에 의해 업데이트되는 커서 인덱스 값(INDC)을 저장하는 한편, 인덱스 엔트리(1106)는 새로운 풀-스크린 이미지의 완료시에 NPCF에 의해 업데이트되는 풀-스크린 인덱스 값(INDF)을 저장한다. INDC 및 INDF 값들은 서로 독립적으로 그리고 상이한 레이트들에서 업데이트될 수 있다는 것에 주의해야 한다.

이 실시예에서, 후처리 오브젝트는 바람직스럽게도, 인덱스 엔트리의 변경 여부와 상관없이, 그것이 트리거될 때마다 새로운 프레임을 발생시킨다. 이것은, 온-스크린 커서 위치가, 대체로 바람직스러울 수 있듯이, 디스플레이 카덴스에서 업데이트될 것을 보장한다.

일 실시예에서, PCMD 커맨드들(1110, 1112)은 (종래의 설계일 수 있는) 적합한 레지스터들로부터 또는 메모리 로케이션으로부터 현재의 커서 위치를 판독하고;(예를 들어, PP 커맨드 버퍼(1020)에서의 커맨드에 의해 설정될 수 있는) 현재의 커서 사이즈를 판정하며; 어떤 픽셀들이 커서 영역내에 위치하는지를 판정하고; 어떤 픽셀들이 커서 영역내에 위치하는지에 따라, (인덱스 값(INDC)에 의해 식별되는) 현재의 커서 이미지 또는 (인덱스 값(INDF)에 의해 식별되는) 현재의 풀-스크린 이미지로부터 각각의 픽셀을 위한 하나 이상의 프레그먼트들을 선택하기 위한 커맨드들을 포함한다. 합성 알고리즘 자체는 기존의 하드웨어-기반 알고리즘들과 유사할 수 있지만, 전용 하드웨어가 아니라 실행 코어(912)에서 실행될 수 있는 프로그램 코드로 구현되는 것이 바람직스럽다. 투명도 또는 커서와 풀-스크린 이미지의 아래쪽 부분들 사이의 에지 블렌딩(edge blending)과 같은 사양들도 적당한 프로그램 코드를 통해 구현될 수 있다.

다시 도 10을 참조하면, 스캔 아웃 엔진(1030)은 상술된 다양한 스캔 아웃 엔진들과 동일할 수도 있다. 이 실시예에서, 모든 합성은 HPC에서의 후처리 오브젝트에 의해 호스트(1000)에서 수행되고, 스캔 아웃 엔진(1030)의 동작은, 디스플레이 버퍼(1008)에서의 픽셀들이 발생된 방법과 무관하다.

다른 후처리 동작은 (업계에서 "LCD 피드-포워드" 또는 "응답 시간 보상(RTC)"이라고도 하는) LCD 오버드라이브이다. 업계에 공지되어 있는 바와 같이, 픽셀을 구동중인 신호들이 부분적으로는 소정의 새로운 강도에 기초하고 부분적으로는 소정의 새로운 강도와 선행 강도 사이의 차이에 기초해 프레임마다 조정된다면, LCD 스크린은 좀더 빨리 응답하게 될 수 있다. 본 발명의 실시예에 따르면, LCD 오버드라이브는 적합한 커맨드들을 포함하는 후처리 프로그램을 실행중인 후처리 오브젝트 내에 구현될 수 있다.

예를 들어, 이미지의 프레그먼트 각각이 프레임의 일 픽셀에 대응되는 상황을 고려한다. (본 발명이 이 경우로 제한되는 것은 아니며; 그것이 여기에서는 예시의 목적들을 위해 사용된다.) 도 12는, (예를 들어, 도 3B에 도시된) 적합한 후처리 프로그램을 통해 후처리 오브젝트(134;예를 들어, 도 2 참고)에 구현될 수도 있는, 프레임을 발생시키기 위한 프로세스(1200)를 예시한다. 프로세스(1200)는, 가장 최근에 완료된 이미지가 인덱스 값 R을 가진 이미지 버퍼(226;도 2)에 저장되고 직전의 이미지가 인덱스 값 (R-1) mod N을 가진 상이한 이미지 버퍼(226)에 저장되는 실시예로 구현되는 것이 바람직스럽고; 이들 양자의 이미지 버퍼들(226)은 후처리 오브젝트(134)에 의해 계속해서 로킹된다.

단계 1202에서, 후처리 오브젝트(134)는 PP 커맨드 버퍼(129)에서의 인덱스 엔트리를 점검한다. 단계 1204에서는, 인덱스 값의 변경 여부가 판정된다. 그렇지 않다면, 단계 1206에서는, 프레임에서의 모든 픽셀들을 위한 델타 값들이 0으로 설정되는데, 이는 원하는 픽셀 값들 중 어떤 것도 변경되지 않았다는 것을 반영한다. 인덱스 값이 변경되었다면, 단계 1208에서는, 버퍼 R에서의 프레그먼트 값 및 버퍼 (R-1) mod N에서의 프레그먼트 값에 기초해 픽셀 각각을 위한 델타 값이 계산된다. 일 실시예에서, 델타 값은 단순히 2개 버퍼들에서의 대응되는 프레그먼트들을 위한 값들 사이의 차이(difference)이다.

단계 1210에서는, 원하는 픽셀 강도가 버퍼 R에서의 프레그먼트 값으로부터 판정된다. 일 실시예에서, 프레그먼트 값은 원하는 픽셀 강도이고; 다른 실시예들에서, 원하는 픽셀 강도는 프레그먼트 값의 함수(예를 들어, 통합 감마 정정)이다.

단계 1212에서는, 원하는 강도 및 델타 값에 기초해 픽셀을 위한 오버드라이브 값이 판정된다. 일 실시예에서는, 오버드라이브 신호를 계산하기 위한 함수가 규정될 수 있다. 다른 실시예에서는, 오버드라이브 신호들이, 원하는 강도 및 델타 값(또는 새로운 강도 값 및 이전의 강도 값)을 사용해 인덱싱되는 룩업 테이블로부터 판정될 수도 있고; 실행 코어(404)는 테이블 룩업을 수행하도록 구성된 기능 유닛을 포함할 수도 있다.

프로세스(1200)는 예시적이라는 것과 변형들 및 변경들이 가능하다는 것을 알 수 있을 것이다. 단계들은 각각의 프레그먼트에 대해 순차적으로 또는 프레그 먼트들의 그룹들에 대해(또는 모든 프레그먼트들에 대해) 병렬로 실행될 수 있고, 단계들의 순서는 변경될 수 있으며, 단계들은 변경되거나 조합될 수 있다. 델타 값들의 상이한 정의들은 대체될 수도 있고, 프레그먼트 값들에 대한 다른 변경들이 도입될 수도 있다. 또한, 프로세스(1200)는 프레그먼트 데이터로부터 픽셀 데이터를 발생시키기 위한 추가 단계들(예를 들어, 다운 필터링, 업 필터링, 합성 등)과 조합될 수 있다.

프로세스(1200)에 의해 픽셀을 위해 발생된 오버드라이브 신호가 반드시 프레임 버퍼(227)에 저장될 최종 값일 필요는 없다는 것을 이해할 수 있어야 한다. 추가적인 후처리 커맨드들을 사용해 후속적인 조작이 구현될 수도 있다.

후처리 동작의 제3 일례는, 이미지를 위한 프레그먼트 데이터가 이미지에 수직인 축 주위로 소정 각도(예를 들어, 90°의 배수)에 걸쳐 회전된 2-D 표면 상에 매핑되는 표면 회전이다. 축과 이미지 평면의 교차점 및/또는 회전 각도는 구성 가능한 파라미터들일 수 있다. 일 실시예에서, 교차점은 이미지의 중앙에(또는 중앙 부근에) 고정되고, 각도는 90°의 구성 가능한 배수(예를 들어, 0°, 90°, 180°, 270°)이다. 교차점 및 회전 각도에 기초해, 이미지 버퍼에서의 각각의 프레그먼트 로케이션이 프레임 버퍼에서의 대응되는 픽셀 로케이션으로 매핑될 수 있다. 따라서, 프레그먼트 로케이션들과 픽셀 로케이션들 사이의 매핑을 정의하고, 매핑을 사용해, 프레그먼트가 판독되었던 어드레스에 기초해 픽셀 각각을 위한 기입 어드레스를 판정하는 것에 의해 후처리 오브젝트에 표면 회전이 구현될 수 있다. 매핑은, 예를 들어, 이미지 버퍼를 위한 로케이션 오프셋에 의해 액세스 가능 한 룩업 테이블로서 또는 이미지 버퍼를 위한 로케이션 오프셋으로부터 픽셀 버퍼를 위한 로케이션 오프셋을 계산하기 위한 공식으로서 제공될 수 있다. 일 실시예에서, 허용되는 다수의 회전 각도들을 위한 매핑들은 이미지 버퍼 로케이션 오프셋 및 현재의 회전 각도에 의해 액세스 가능한 룩업 테이블을 사용해 제공될 수도 있다.

도 13은 적당한(예를 들어, 도 3B에 도시된) 후처리 프로그램을 통해 후처리 오브젝트(134)(예를 들어, 도 2 참고)에 구현될 수 있는 회전된 프레임을 발생시키기 위한 프로세스(1300)의 흐름도이다. 단계 1302에서는, 소정 로케이션에 기초해, 이미지 버퍼에서의 각각의 프레그먼트 로케이션과 픽셀 버퍼에서의 대응되는 픽셀 로케이션 사이의 매핑이 정의된다. 매핑은, 예를 들어, 렌더링 오브젝트의 초기화 동안, 한번 정의되고, 회전 파라미터들이 변하는 경우에만 업데이트될 수도 있다. 일 실시예에서는, 후처리 커맨드가 매핑을 공급하는데 사용되고; 다른 실시예에서는, 후처리 커맨드들이, 후처리 오브젝트가 적합한 매핑을 계산하거나 선택하는데 사용할 수 있는 파라미터들을 공급한다.

단계 1304에서는, 프레그먼트 데이터가 (여기에서 소스 로케이션이라고 하는) 이미지 버퍼 로케이션으로부터 판독되고, 단계 1306에서는, 프레그먼트 데이터가 처리되어 픽셀 값을 발생시킨다. 예를 들어, 합성 및/또는 LCD 오버드라이브 동작들을 포함하는 후처리 동작의 임의 유형이 단계 1306에 포함될 수도 있다. 일단 처리가 완료되고 나면, 단계 1308에서는, 소스 로케이션 및 단계 1302에서 정의된 매핑을 사용하는 것에 의해 픽셀 값을 위한 프레임 버퍼에서의 목적지 로케이션 이 판정된다. 단계 1310에서는, 픽셀 값이 목적지 로케이션에 기입된다. 단계 1312에서는, 더 많은 프레그먼트들이 계속해서 처리될 것인지의 여부가 판정된다. 그렇다면, 프로세스(1300)는 후속 프레그먼트를 처리하기 위해 단계 1304로 복귀하고; 현재 이미지를 위한 모든 프레그먼트들이 처리되었을 때, 프로세스(1300)는 종료한다(단계 1314).

프로세스(1300)는 예시적이라는 것과 변형들 및 변경들이 가능하다는 것을 알 수 있을 것이다. 순차적으로 설명된 단계들이 병렬로 실행될 수도 있고, 단계들의 순서가 달라질 수도 있으며, 단계들이 변경되거나 조합될 수도 있다. 예를 들어, 다수 프레그먼트들이 병렬로 처리될 수도 있다. 일부 실시예들에서는, 소스 로케이션들과 목적지 로케이션들 사이의 매핑이 일대일이 아닐 수도 있는데; 예를 들어, 회전된 이미지 또한 픽셀 어레이의 치수들에 적합하도록 축소 또는 확대될 수 있다. 축소 또는 확대는 수개의 프레그먼트 값들을 블렌딩하여 하나의 픽셀 값을 발생시키는 단계를 수반할 수도 있다. 1개의 프레그먼트 로케이션이 픽셀로의 매핑을 정의하기 위한 소스 로케이션으로 사용될 수 있기만 하다면, 프로세스(1300)는 이 경우에 대해 적응될 수 있다. 다른 실시예들에서, 매핑은, 각각의 픽셀 로케이션을 위해 사용될 하나 이상의 소스 로케이션들이 식별되도록 정의될 수도 있다.

합성 및 LCD 오버드라이브 동작들은 여기에서, 후처리 오브젝트에 구현될 수 있는 동작들의 일례들로서 사용된다. 이 일례들에 추가하여 또는 이 일례들 대신에 다른 동작들도 구현될 수 있으며; "개요 및 용어"의 서브섹션에서 일부 일례들 이 상술되었지만, 본 발명이 특정한 후처리 동작들로 제한되는 것은 아니다. 당업자들이라면, 바람직스럽게도, 정확한 거동을 위해 디스플레이 카덴스에서의 실행이 바람직스럽거나 필요한 임의 동작을 구현하기 위해 후처리 오브젝트가 사용될 수 있다는 것을 알 수 있을 것이다. 새로운 프레임들이 디스플레이 카덴스에서 발생될 수 있기만 하다면, 후처리 오브젝트에 포함되는 동작들의 수 및 복잡도(complexity)는 달라질 수도 있다.

후처리 프로그램들을 위한 소스들

상술된 바와 같이, 후처리 프로그램들은 그래픽 드라이버 프로그램에 의해 PP 커맨드 버퍼에 기입된다. 드라이버는 커맨드들을 직접적으로(예를 들어, 도 1의 실시예에서 커맨드들을 시스템 버스(106)를 통해 PP 커맨드 버퍼(129)의 메모리 로케이션으로 전달하는 것에 의해) 또는 간접적으로(예를 들어, 도 7을 참조하여 상술된 바와 같이 WRPP 커맨드를 렌더링 커맨드 버퍼(128)에 기입하는 것에 의해) 기입할 수도 있다.

이하에서는, 후처리 프로그램들을 위한 소스들이 설명될 것이다. 일부 실시예들에서, 그래픽 드라이버는 다양한 후처리 동작들을 구현하는 미리 정의된 프로그램 세그먼트들의 라이브러리로부터 후처리 프로그램들을 어셈블리한다. 그래픽 드라이버는, 애플리케이션 개발자들이 사용하고자 하는 후처리 동작들 및 임의의 관련 파라미터들을 애플리케이션 개발자들이 특정할 수 있게 하는 적당한 API(application program interface)를 제공할 수도 있다. API 자체는 일반적으로, 스캔 아웃-시간 처리를 제어하기 위한 전통적인 API들과 유사할 수 있지만, 그 래픽 드라이버내에서의 구현은 상이하다. 구체적으로, API 명령어들에 응답하여, 그래픽 드라이버는 라이브러리로부터 적절한 프로그램 세그먼트들을 선택하고, 세그먼트들을 완료된 프로그램으로 어셈블리(예를 들어, 상술된 인덱스-점검 및 점프 커맨드들과 같은 제어 커맨드들을 추가)하고, 프로그램을 PP 커맨드 버퍼에 기입하거나 적합한 WRPP 커맨드들을 렌더링 커맨드 스트림에 삽입한다.

다른 실시예들에서, 애플리케이션 개발자들은 "맞춤형(custom)" 후처리 프로그램들을 정의할 수도 있다. 예를 들어, 그래픽 드라이버는, 애플리케이션 또는 오퍼레이팅 시스템 프로그램으로부터 임의적인 후처리 프로그램 또는 프로그램 세그먼트를 수용하는 API를 제공할 수도 있다. 맞춤형 후처리 프로그램들을 기입하기 위한 명령어들 및/또는 제안들을 갖춘 개발자의 키트도 제공될 수 있다. 또 다른 실시예들에서는, 라이브러리 프로그램 세그먼트들과 맞춤형 프로그램 세그먼트들의 조합이 지원될 수도 있다.

상술된 실시예들에서, 그래픽 드라이버는 후처리 프로그램들을 PP 커맨드 버퍼에 기입하는 것으로 식별된다. 일부 실시예들에서, 그래픽 드라이버 프로그램은 하드웨어 및/또는 드라이버 프로그램이 실행되는 오퍼레이팅 시스템의 세부 사항들을 숨기는 추상적 레벨로 구현된다. 예를 들어, 리소스 관리자 프로그램이 그래픽 드라이버 프로그램과 시스템 하드웨어 컴포넌트들의 상호 작용들을 지원하기 위해 제공될 수도 있다. 리소스 관리자는 로우-레벨 하드웨어와 오퍼레이팅 시스템 프로그램들 및/또는 애플리케이션 프로그램들로부터의 처리 요청들에 응답하여 호출되는 오퍼레이팅-특정 기능성을 구현한다. 이러한 추상적인 추가 레벨로 인해, 리 소스 관리자의 상이한 구현을 제공함으로써, 동일한 드라이버 코드가 상이한 하드웨어 구성들에 적응될 수 있다. 리소스 관리자가 구현되는 경우, PP 커맨드 버퍼로의 후처리 프로그램들의 실제 기입은, 그것이 드라이버에 대해 투과적(transparent)이도록, 리소스 관리자에 의해 핸들링될 수 있다.

또 다른 실시예에서는, 종래의 스캔 아웃 제어 커맨드들이 드라이버에 의해 발행될 수 있다. 그러한 커맨드들은 GPU내의 적당한 커맨드 인터페이스 컴포넌트에 의해 수신되어 후처리 오브젝트를 위한 제어 구조들로 변경된다. 예를 들어, 스캔 아웃 커맨드의 수신시에, 커맨드 인터페이스 컴포넌트는 커맨드들 또는 파라미터들을 PP 커맨드 버퍼에 기입 또는 겹쳐쓰기할 수 있거나, 적당한 SELPP 및/또는 WRPP 커맨드들을 렌더링 커맨드 스트림에 삽입할 수 있다. 이와 같이, PP 커맨드 버퍼 및 후처리 오브젝트는 (리소스 관리자를 포함하는) 그래픽 드라이버에 대해 투과적일 수 있고, 변경되지 않은 종래의 그래픽 드라이버들에 본 발명이 사용될 수도 있다. GPU의 적당한 커맨드 인터페이스 컴포넌트에 의해 조작되는, PP 커맨드 버퍼 이외의, 제어 구조들이 후처리 오브젝트의 거동을 제어하는데 사용될 수도 있다는 것을 알 수 있을 것이다.

추가 실시예들

상술된 바와 같이, 본 발명의 실시예들은 GPU의 실행 코어에서 이용 가능한 대규모 처리 능력이 디스플레이 카덴스에서의 픽셀 처리를 위해 강화될 수 있게 한다. 더 나아가, 여기에서 설명되는 후처리 오브젝트들의 프로그램 가능성은, 수행될 수 있는 디스플레이 후처리의 양과 유형에 대해, 종래의 특수 목적 회로들에 의 해 실현될 수 있는 것보다 상당히 큰 호환성을 제공한다. 더 나아가, 본 발명의 일부 실시예들은, 칩 면적 및 전력 소비에서의 이점들을 제공하면서, 종래의 GPU들에서 특수 목적 후처리 회로의 양이 상당히 감소되거나 제거될 수 있게 한다.

특정 실시예들과 관련하여 발명이 설명되었지만, 당업자라면, 다수 변경들이 가능하다는 것을 알 수 있을 것이다. 예를 들어, 발명이, 임의의 특정 실행 코어 또는 컨택스트 관리 아키텍처로 제한되지 않는다. 또한, 후처리 동작들의 특정 일례들이 설명되었지만, 본 발명의 범위내에서, 여기에서 구체적으로 언급되지 않은 동작들을 포함하는, 임의 동작 또는 동작들의 조합이 구현될 수도 있다는 것을 이해할 수 있어야 한다.

여기에서의 설명은, 렌더링 오브젝트들 및 후처리 오브젝트들과 같은, 처리 오브젝트들을 참조한다. 이 컨택스트에서, "오브젝트"는 상태 및 거동 양상들의 엔티티를 의미하는 것으로 이해되어야 한다. 당업자들이라면, 다수 오브젝트들이 다양한 방법들로 멀티프로세서에서 구현될 수 있다는 것을 알 수 있을 것이다. 예를 들어, 상이한 오브젝트들이 적절하게 스위칭될 수 있게 하기 위해 컨택스트-스위칭 사양들의 단일 처리 엔진이 구현될 수 있다. 다른 방법으로는, 여기에서 언급되는 오브젝트들 중 어느 하나 또는 모두가 오브젝트의 상태 및 거동 양상들을 실현할 수 있는 별도의 처리 엔진들을 사용해 구현될 수도 있다.

더 나아가, 특정 하드웨어 및 소프트웨어 컴포넌트들을 참조하여 본 발명이 설명되었지만, 당업자들이라면, 하드웨어 및/또는 소프트웨어 컴포넌트들의 상이한 조합들이 사용될 수도 있다는 것과 여기에서 하드웨어로 구현되는 것으로 설명되는 특정 동작들이 소프트웨어로 구현될 수도 있고 또는 그 반대일 수도 있다는 것을 알 수 있을 것이다.

본 발명의 다양한 사양들을 통합하는 컴퓨터 프로그램들이 저장 및/또는 전송을 위한 다양한 컴퓨터 판독 가능 매체들에 인코딩될 수도 있는데; 적당한 매체들은 자기 디스크 또는 테이프, CD(compact disk) 또는 DVD(digital versatile disk)와 같은 광학 저장 매체들, 플래시 메모리 그리고, 인터넷을 포함하는, 다양한 프로토콜들을 따르는 유선, 광학, 및/또는 무선 네트워크들을 통한 전송에 적합한 캐리어 신호들을 포함한다. 프로그램 코드로써 인코딩된 컴퓨터 판독 가능 매체들은 호환 가능 장치와 패키징될 수 있거나 (예를 들어, 인터넷 다운로드를 통해) 다른 장치들로부터 별도로 제공될 수도 있다.

이와 같이, 특정 실시예들과 관련하여 발명이 설명되었지만, 발명은 다음의 청구항들의 범위내에 해당되는 모든 변경들 및 등가물들을 커버하기 위한 것이라는 것을 알 수 있을 것이다.

도 1은 본 발명의 실시예에 따른 컴퓨터 시스템의 하이레벨 블록도이다.

도 2는 본 발명의 실시예에 따른 그래픽 처리 서브시스템의 데이터 흐름도이다.

도 3a는 본 발명의 실시예에 따른 렌더링 커맨드 스트림을 예시한다.

도 3b는 본 발명의 실시예에 따른 후처리 프로그램을 예시한다.

도 4는 본 발명의 실시예에 따른 멀티프로세서의 컴포넌트들을 나타내는 블록도이다.

도 5는 본 발명의 실시예에 따른 조정 로직 프로세스의 흐름도이다.

도 6은 본 발명의 다른 실시예에 따른 멀티프로세서의 컴포넌트들을 나타내는 블록도이다.

도 7은, 본 발명의 실시예에 따른, 후처리 프로그램을 기입하기 위한 커맨드들을 갖춘 렌더링 커맨드 스트림을 예시한다.

도 8은, 본 발명의 실시예에 따른, 2개의 스캔 아웃 엔진들을 지원하는 멀티프로세서의 블록도이다.

도 9는 합성 이미지를 예시한다.

도 10은, 본 발명의 실시예에 따른, 합성 이미지들을 지원하는 멀티프로세서의 블록도이다.

도 11은, 본 발명의 실시예에 따른, 합성 이미지를 형성하기 위한 후처리 프로그램을 예시한다.

도 12는, 본 발명의 실시예에 따른, LCD 오버드라이브 값들을 발생시키기 위한 프로세스의 흐름도이다.

도 13은, 본 발명의 실시예에 따른, 이미지를 회전시키기 위한 프로세스의 흐름도이다.

Claims

그래픽 프로세서로서,

복수개의 오브젝트를 실행하도록 구성된 멀티프로세서 - 상기 복수개의 오브젝트는, 이미지 데이터를 발생시키기 위한 제1 시퀀스의 프로그램 명령어들을 실행하도록 구성된 렌더링 오브젝트(rendering object); 및 상기 이미지 데이터로부터 픽셀 데이터의 프레임을 발생시키기 위한 제2 시퀀스의 프로그램 명령어들을 실행하도록 구성된 후처리 오브젝트(post-processing object)를 포함하고, 상기 멀티프로세서는 상기 복수개의 오브젝트의 실행을 제어하도록 구성된 조정 유닛(arbitration unit)을 포함함 - , 및

발생된 픽셀 데이터의 프레임들을 등시에 디스플레이 포트로 전송하도록 구성되고 트리거 신호를 상기 조정 유닛으로 주기적으로 전송하도록 연결된 스캔 아웃 엔진(scanout engine)

을 포함하는 그래픽 프로세서.