KR20200118192A

KR20200118192A - 커맨드 스트림 최적화 및 향상을 위한 장치 및 방법

Info

Publication number: KR20200118192A
Application number: KR1020207026053A
Authority: KR
Inventors: 판 장; 샤오싱 주; 아르투로 카바레로; 구스타보 누니스; 오를리앙 샤노
Original assignee: 후아웨이 테크놀러지 컴퍼니 리미티드
Priority date: 2018-05-31
Filing date: 2019-05-31
Publication date: 2020-10-14
Also published as: WO2019228497A1; EP3740939A4; AU2019275720A1; EP3740939A1; US11837195B2; CN111465966B; KR102455820B1; US20210065657A1; CA3091602C; AU2019275720B2; CN111465966A; CA3091602A1

Abstract

컴퓨팅 디바이스에 의해 구현되는 방법은, 컴퓨팅 디바이스에서 실행되는 원래 스레드에 의해, 그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하는 단계 - 커맨드는 그래픽 인터페이스에 대한 호출임 -, 컴퓨팅 디바이스에서 실행되는 원래 스레드에 의해, 커맨드에 기초하여 커맨드 스트림을 구성하는 단계 - 커맨드 스트림은 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -, 및 컴퓨팅 디바이스에서 실행되는 커맨드 스트림 스레드에 의해, 커맨드 스트림을 실행하여 그래픽 애플리케이션의 프레임을 렌더링하는 단계를 포함한다.

Description

커맨드 스트림 최적화 및 향상을 위한 장치 및 방법

관련 출원들에 대한 상호 참조

본 출원은 Xiaoxing Zhu et. al.에 의해 2018년 8월 24일자로 "Apparatus and Method for Command Stream Optimization and Enhancement"라는 명칭으로 출원된 U.S. 가특허출원 제62/722,542호 및 Xiaoxing Zhu et. al.에 의해 2018년 5월 31일자로 "Command Stream Dynamic Reconstruction based Graphics Optimization and Enhancement"라는 명칭으로 출원된 U.S. 가특허출원 제62/678,726호의 이득의 이득을 주장하며, 두 가출원 모두 본 명세서에서 그 전문들이 마치 복사된 것처럼 참조로 포함된다.

발명의 분야

본 개시내용은 컴퓨터 그래픽 프로세싱 및 렌더링 분야에 관한 것이다. 특히, 본 개시내용은 그래픽들을 렌더링하기 위한 컴퓨팅 디바이스의 성능 및 전력 소비를 개선하는 것에 관한 것이다.

애플리케이션 마켓 플레이스들로부터 가장 자주 다운로드되는 애플리케이션들은 비디오 게임 애플리케이션들이다. 비디오 게임 애플리케이션들은 애플리케이션 마켓플레이스들의 최고 수입원이기도 하다. 시장 조사 데이터에 기초하면, 비디오 게임 애플리케이션들은 전체 연간 애플리케이션 마켓플레이스 수입의 거의 80 퍼센트(%)를 차지한다. 또한, 모바일 폰 사용자들의 50 % 이상이 게임 애플리케이션들을 매일 평균 1 시간을 초과하여 사용하는 데 소비한다.

그러므로 모바일 디바이스에서 비디오 게임을 하는 것을 위주로 하는 전반적인 사용자 경험은 사용자들이 어떤 폰들이 최고 품질의 비디오 게임들을 제공하고 어떤 비디오 게임 애플리케이션들을 마켓플레이스로부터 구매할지를 결정하는 방법에 영향을 준다. 전반적인 사용자 경험은 비디오 게임의 성능, 비디오 게임을 하는 동안 발생하는 전력 소비, 비디오 게임을 하는 동안 모바일 디바이스에 의해 방출되는 열, 비디오 게임의 오디오 품질 등과 같은 다양한 인자를 포함할 수 있다. 이러한 인자들 중, 비디오 게임의 프레임 레이트(frame rate)를 의미할 수 있는 비디오 게임의 성능 및 비디오 게임의 전력 소비는 비디오 게임을 할 때 전반적인 사용자 경험에 영향을 미치는 가장 중요한 인자이다.

본 개시내용의 제1 양태에 따르면, 컴퓨팅 디바이스에 의해 구현되는 방법이 제공된다. 방법은, 컴퓨팅 디바이스에서 실행되는 원래 스레드(original thread)에 의해, 그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하는 단계 - 커맨드는 그래픽 인터페이스에 대한 호출임 -, 컴퓨팅 디바이스에서 실행되는 원래 스레드에 의해, 커맨드에 기초하여 커맨드 스트림을 구성하는 단계 - 커맨드 스트림은 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -, 및 컴퓨팅 디바이스에서 실행되는 커맨드 스트림 스레드에 의해, 커맨드 스트림을 실행하여 그래픽 애플리케이션의 프레임을 렌더링하는 단계를 포함한다.

이와 같은 제1 양태에 따른 방법의 제1 구현에서, 커맨드 스트림은 원래 스레드에 의해 실행되는 렌더링 로직과 동시에 커맨드 스트림 스레드에 의해 실행된다.

이와 같은 제1 양태에 따른 방법의 제2 구현 또는 제1 양태의 임의의 선행 구현에서, 커맨드 스트림을 구성하는 단계는, 컴퓨팅 디바이스에 의해, 렌더링 로직으로부터 복수의 커맨드를 추출하는 단계, 및 컴퓨팅 디바이스에 의해, 렌더링 로직으로부터 추출된 복수의 커맨드를 조합하는 단계를 포함한다.

이와 같은 제1 양태에 따른 방법의 제3 구현 또는 제1 양태의 임의의 선행 구현에서, 커맨드 스트림 스레드에 의한 커맨드 스트림의 실행은 원래 스레드에 의한 게임 로직 업데이트 및 렌더링 로직의 실행과 인터리빙된다.

이와 같은 제1 양태에 따른 방법의 제4 구현 또는 제1 양태의 임의의 선행 구현에서, 컴퓨팅 디바이스에 의해, 커맨드 스트림 내의 복수의 커맨드에 대응하는 복수의 그래픽 인터페이스를 재해석하는 단계 - 복수의 그래픽 인터페이스의 재해석 단계는 애플리케이션별로 컴파일 시간 또는 런타임 중 적어도 하나 동안 맞춤화 가능하고 상호호환 가능함 -, 컴퓨팅 디바이스에 의해, 그래픽 데이터 및 커맨드 스트림 내의 복수의 커맨드 간의 데이터 종속성들을 포함하는 커맨드 스트림 정보를 결정하는 단계, 및 컴퓨팅 디바이스에 의해, 커맨드 스트림 정보를 컴퓨팅 디바이스의 메모리에 저장되는 커맨드 버퍼에 편성하고 저장하는 단계를 포함한다.

이와 같은 제1 양태에 따른 방법의 제5 구현 또는 제1 양태의 임의의 선행 구현에서, 컴퓨팅 디바이스에서 복원 및 실행되는 커맨드 스트림 스레드에 의해, 커맨드 버퍼로부터 커맨드를 페치함으로써 커맨드 스트림으로부터 커맨드를 검색하는 단계를 포함하고, 커맨드 버퍼는 적어도 하나의 메모리 블록을 포함한다.

이와 같은 제1 양태에 따른 방법의 제6 구현 또는 제1 양태의 임의의 선행 구현에서, 원래 스레드는 상기 컴퓨팅 디바이스의 제1 코어에서 실행되고, 커맨드 스트림 스레드는 컴퓨팅 디바이스의 제2 코어에서 실행된다.

이와 같은 제1 양태에 따른 방법의 제7 구현 또는 제1 양태의 임의의 선행 구현에서, 커맨드 스트림 스레드 또는 원래 스레드에 의해, 커맨드들을 실행하기 전에 커맨드 스트림 내의 커맨드들 중 적어도 하나를 수정하는 단계를 포함한다.

이와 같은 제1 양태에 따른 방법의 제8 구현 또는 제1 양태의 임의의 선행 구현에서, 원래 스레드 또는 커맨드 스트림 스레드 중 적어도 하나에 의해, 시각적 향상 커맨드를 커맨드 스트림에 삽입하는 단계를 포함하고, 시각적 향상 커맨드는 렌더링되는 프레임에 시각적 효과를 추가하는 것이다.

본 개시내용의 제2 양태에 따르면, 컴퓨팅 디바이스가 제공된다. 컴퓨팅 디바이스는, 커맨드 버퍼를 포함하는 메모리, 메모리에 결합된 제1 프로세서, 제1 프로세서에서 실행되는 원래 스레드 - 원래 스레드는 그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하고 - 커맨드는 그래픽 인터페이스에 대한 호출임 -, 커맨드 버퍼에 커맨드 스트림을 저장하도록 구성되고, 커맨드 스트림은 커맨드에 기초하여 구성되고, 커맨드 스트림은 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -, 및 프로세서에서 실행되고 그래픽 애플리케이션의 프레임을 렌더링하기 위해 커맨드 스트림을 실행하도록 구성되는 커맨드 스트림 스레드를 포함한다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제1 구현에서, 커맨드 스트림은 원래 스레드에 의해 실행되는 렌더링 로직과 동시에 커맨드 스트림 스레드에 의해 실행되고, 원래 스레드는 커맨드 스트림 스레드가 커맨드 스트림 내의 복수의 커맨드의 실행을 시작하기 전에 커맨드 버퍼에 저장되는 최소 개수의 커맨드들을 정의하는 프레임에 대한 임계치를 결정하고, 커맨드 버퍼에 저장된 커맨드들의 개수가 임계치를 충족할 때 커맨드 스트림 내의 복수의 커맨드를 실행하도록 추가로 구성된다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제2 구현 또는 제2 양태의 임의의 선행 구현에서, 커맨드 스트림은 게임 로직 업데이트 및 렌더링 로직의 실행과 인터리빙된다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제3 구현 또는 제2 양태의 임의의 선행 구현에서, 프레임에 대한 임계치는 원래 스레드에 대비한 커맨드 스트림 내의 커맨드들의 실행 타이밍 및 그래픽 애플리케이션의 이전 프레임에 대한 커맨드 스트림 내의 커맨드들의 개수에 기초하여 조정된다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제4 구현 또는 제2 양태의 임의의 선행 구현에서, 커맨드 버퍼는 복수의 메모리 블록으로 분할되고, 제1 메모리 블록은 커맨드에 대한 핸들 및 커맨드에 대한 파라미터를 저장하고, 제2 메모리 블록은 커맨드에 의해 프레임을 렌더링하기 위해 사용되는 그래픽 데이터를 저장한다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제5 구현 또는 제2 양태의 임의의 선행 구현에서, 커맨드 버퍼는 커맨드의 메모리 어드레스를 포함하고, 커맨드에 대해 복수의 구현이 저장될 수 있고, 구현들 중 하나는 커맨드 스트림 스레드에 의한 실행을 위해 선택될 수 있다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제6 구현 또는 제2 양태의 임의의 선행 구현에서, 커맨드 스트림은 복수의 커맨드를 포함하고, 원래 스레드는 커맨드들을 실행하기 전에 커맨드의 파라미터들을 변경하거나 중복 커맨드를 제거함으로써 커맨드 스트림 내의 복수의 커맨드 중 하나 이상을 재구성하도록 추가로 구성된다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제7 구현 또는 제2 양태의 임의의 선행 구현에서, 원래 스레드는 렌더링 로직으로부터 복수의 커맨드를 추출하고, 렌더링 로직으로부터 추출된 복수의 커맨드를 조합함으로써 커맨드 스트림을 구성하도록 구성된다.

이와 같은 제2 양태에 따른 컴퓨팅 디바이스의 제8 구현 또는 제2 양태의 임의의 선행 구현에서, 원래 스레드는 사용자 커맨드 또는 구성 파일 중 적어도 하나에 기초하여 커맨드 스트림 스레드를 개시할지를 결정하도록 추가로 구성된다.

본 개시내용의 제3 양태에 따르면, 컴퓨팅 디바이스가 제공된다. 컴퓨팅 디바이스는 컴퓨팅 디바이스에서 실행되는 원래 스레드 - 원래 스레드는 그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하고 - 상기 커맨드는 그래픽 인터페이스에 대한 호출임 -, 커맨드에 기초하여 커맨드 스트림을 구성하도록 구성되고, 커맨드 스트림은 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -, 및 그래픽 애플리케이션의 프레임을 렌더링하기 위해 커맨드 스트림을 실행하도록 구성되는, 컴퓨팅 디바이스에서 실행되는 커맨드 스트림 스레드를 포함한다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제1 구현에서, 원래 스레드는 커맨드 스트림을 선제적으로 수정하여 원래 스레드에 의해 관련 후속 커맨드들을 비동기 방식으로 실행하기 위해 후속적으로 사용되는 핸들들의 대형 풀(large pool)을 생성하도록 추가로 구성된다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제2 구현 또는 제3 양태의 임의의 선행 구현에서, 커맨드 스트림 내의 복수의 커맨드는 서로 상관된 하나 이상의 동기 커맨드를 포함하고, 원래 스레드는 복수의 동기 커맨드를 한 번에 함께 실행하도록 추가로 구성된다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제3 구현 또는 제3 양태의 임의의 선행 구현에서, 원래 스레드는 커맨드를 컴퓨팅 디바이스의 메모리의 커맨드 버퍼에 저장하도록 추가로 구성된다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제4 구현 또는 제3 양태의 임의의 선행 구현에서, 커맨드 버퍼는 커맨드의 메모리 어드레스를 포함한다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제5 구현 또는 제3 양태의 임의의 선행 구현에서, 원래 스레드는 렌더링 로직으로부터 복수의 커맨드를 추출하고, 렌더링 로직으로부터 추출된 복수의 커맨드를 조합함으로써 커맨드 스트림을 구성하도록 구성된다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제6 구현 또는 제3 양태의 임의의 선행 구현에서, 컴퓨팅 디바이스는 프로세서를 더 포함하고, 프로세서는 사용자 커맨드, 구성 파일 또는 검출 로직 중 적어도 하나에 기초하여 커맨드 스트림 스레드를 개시하고, 사용자 커맨드, 구성 파일 또는 검출 로직 중 적어도 하나에 기초하여 커맨드 스트림 스레드를 종료하도록 추가로 구성된다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제7 구현 또는 제3 양태의 임의의 선행 구현에서, 복수의 커맨드의 각각은 OPEN GRAPHICS LIBRARY(OPEN GL) 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)(API) 또는 OPEN GL EMBEDDED SYSTEMS(ES) API에 대한 호출을 포함한다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제8 구현 또는 제3 양태의 임의의 선행 구현에서, 복수의 커맨드의 각각은 컴퓨팅 디바이스의 게임 계층에서 구현된 인터페이스에 대한 호출을 포함한다.

이와 같은 제3 양태에 따른 컴퓨팅 디바이스의 제9 구현 또는 제3 양태의 임의의 선행 구현에서, 복수의 커맨드의 각각은 컴퓨팅 디바이스의 디바이스 드라이버에서 구현된 인터페이스에 대한 호출을 포함한다.

본 명세서에 개시된 실시예는 그래픽 애플리케이션들을 컴퓨팅 디바이스에서 증가된 프레임 레이트로 실행할 수 있게 하여, 그래픽 애플리케이션들을 탐색하는 동안 사용자 경험을 향상시킨다. 전형적으로, 그래픽 애플리케이션의 프레임 레이트를 증가시키면 컴퓨팅 디바이스에 의해 소비되는 전력의 증가를 초래하고, 이것은 사용자가 그래픽 애플리케이션들을 탐색하는 동안 컴퓨팅에서 방출되는 열을 또한 증가시킨다. 본 명세서에 개시된 실시예는 전력 소비의 증가를 초래하지 않으면서 그래픽 애플리케이션에 대한 프레임 레이트를 증가시킬 수 있게 한다.

이러한 특징들 및 다른 특징들은 첨부된 도면들 및 청구 범위와 함께 취해진 다음의 상세한 설명으로부터 보다 명확하게 이해될 것이다.

본 개시내용의 보다 완전한 이해를 위해, 이제 동일한 참조 번호가 동일한 부분을 나타내는 첨부 도면들 및 상세한 설명과 관련하여 취해진 다음의 간단한 설명이 참조된다.
도 1a 내지 도 1b는 본 개시내용의 다양한 실시예에 따른 커맨드 스트림 최적화 및 향상을 도시하는 다이어그램이다.
도 2는 본 명세서에 개시된 커맨드 스트림 최적화 및 향상을 위한 다양한 실시예를 지원하기에 적합한 컴퓨팅 디바이스의 개략도이다.
도 3은 컴퓨팅 디바이스에서 비디오 게임을 실행하는 동안 사용될 수 있는 다양한 계층을 보여주는 컴퓨팅 디바이스의 다른 실시예이다.
도 4는 비디오 게임 애플리케이션의 프레임들을 처리하고 렌더링할 때 비디오 게임 애플리케이션, 운영 체제(operating system)(OS) 및 플랫폼 계층, 더블 데이터 레이트(double data rate)(DDR) 및 GPU 사이의 데이터 흐름을 도시하는 다이어그램이다.
도 5는 본 개시내용의 다양한 실시예에 따른 프레임 렌더링 로직으로부터 커맨드들을 캡처하여 커맨드 스트림을 생성하는 방법을 도시하는 다이어그램이다.
도 6은 본 개시내용의 다양한 실시예에 따른 OPEN GL(OPEN GRAPHICS LIBRARY) API를 사용하여 컴퓨팅 디바이스에 의해 구현되는 커맨드 스트림 최적화 및 향상의 방법을 도시하는 다이어그램이다.
도 7은 다양한 실시예에 따른 컴퓨팅 디바이스에서 커맨드들이 어떻게 호출되는지를 도시하는 테이블이다.
도 8은 다양한 실시예에 따른 커맨드와 연관된 데이터를 저장하는 데 사용되는 메모리 레이아웃을 도시하는 다이어그램이다.
도 9는 본 개시내용의 다양한 실시예에 따른 향상되고 재구성된 커맨드 스트림을 생성하는 방법을 도시한다.
도 10은 본 개시내용의 다양한 실시예에 따른 연기된 커맨드 스트림 실행 모드(deferred command stream execution mode)를 도시하는 다이어그램이다.
도 11은 본 개시내용의 다양한 실시예에 따른 동기적 실행 모드(synchronous execution mode)를 도시하는 다이어그램이다.
도 12는 본 개시내용의 다양한 실시예에 따른 일괄처리 커맨드 스트림 실행 모드(batch command stream execution mode)를 도시하는 다이어그램이다.
도 13은 본 개시내용의 다양한 실시예에 따른 동기 커맨드들을 핸들링하는 일괄처리된 사전 생성 모드(batched pre-generation mode)의 다이어그램이다.
도 14는 본 개시내용의 다양한 실시예에 따른 동기 커맨드들을 핸들링하는 강력하게 상관된 커맨드들에 대한 일괄처리된 사전 캐싱 모드(batched pre-caching mode)의 다이어그램이다.
도 15는 본 명세서에서 개시된 커맨드 스트림 향상 및 최적화 기술들이 비디오의 프레임 레이트 및 비디오 게임의 전력 소비를 어떻게 개선하는지를 도시하는 다이어그램이다.
도 16은 본 명세서에 개시된 다양한 실시예에 따른 커맨드 스트림 최적화 및 향상의 방법을 도시하는 흐름도이다.
도 17은 본 명세서에 설명된 하나 이상의 방법을 구현하도록 구성된 장치를 도시한다.

하나 이상의 실시예의 예시적인 구현이 아래에 제공되지만, 개시된 시스템들 및/또는 방법들은 현재 알려졌거나 존재하는지에 관계없이, 임의의 개수의 기술들을 사용하여 구현될 수 있다는 것을 처음부터 이해해야 한다. 본 개시내용은 본 명세서에 도시되고 설명된 예시적인 설계들 및 구현들을 비롯하여 아래에서 도시된 예시적인 구현들, 도면들 및 기술들로 결코 제한되지 않아야 하며, 첨부의 청구항들의 범위 내에서 그 등가물들의 전체 범위와 함께 수정될 수 있다.

비디오 게임과 같은 표준 그래픽 애플리케이션은 연속적으로 렌더링되고 사용자 컨트롤들에 따라 빠르게 연이어 재생되는 정지 이미지들로 구성된다. 하나의 프레임은 이러한 이미지들 중 단일 프레임을 나타내고, 프레임 레이트는 비디오 게임이 새로운 프레임을 디스플레이하기 위해 얼마나 자주 업데이트되는지를 나타낸다. 프레임 레이트는 시뮬레이션, 움직임 및/또는 모션이 있는 새로운 프레임을 생성하기 위해 컴퓨팅 디바이스의 스크린상에서 보이는 이미지가 얼마나 자주 리플레시되는지를 반영할 수 있다. 프레임 레이트는 거의 대개는 초당 프레임(frames per second)(FPS)으로 측정된다. 사용자가 비디오 게임을 할 때, 그래픽 뒤처짐(graphical lag)으로서 낮은 프레임 레이트가 사용자에게 종종 출현할 수 있다.

프레임에 의해 디스플레이되는 그래픽들의 프레임 레이트, 해상도 및 복잡성에 대한 비디오 게임 산업 표준들이 빠르게 증가하고 있다. 현재, 비디오 게임의 산업 표준 프레임 레이트는 약 30 FPS 이다. 그러나 산업 표준 프레임 레이트는 빠르게 60 FPS로 이동하고 있다. 마찬가지로, 비디오 게임 스크린 해상도에 대한 산업 표준은 더 나은 이미지 품질을 제공하기 위해 720 픽셀에서 1080 픽셀로 변하고 있다.

그러나 비디오 게임의 프레임들에서 디스플레이되는 그래픽들의 프레임 레이트, 해상도 및 복잡도를 높이는 것은 프레임을 드롭시켜 불안정하게 하고 비디오 게임을 렌더링하는 컴퓨팅 디바이스의 전력 소비를 유발하는 계산 비용을 또한 증가시킨다. 즉, 사용자들은 프레임 레이트 및 해상도가 더 높은 비디오 게임들을 할 때 자기의 컴퓨팅 디바이스들(예를 들어, 모바일 디바이스)의 배터리 수명을 희생시키는 것이 전형적이다. 이러한 증가된 전력 소비는 또한 모바일 디바이스로부터 방출되는 열의 바람직하지 않은 증가로 이어질 수 있다.

컴퓨팅 디바이스에 의해 소비되는 전력을 줄이면서 게임의 프레임 레이트를 증가시키기 위해, 비디오 게임 애플리케이션과 같은 그래픽 애플리케이션들의 프레임들의 렌더링을 최적화하고 향상시키는 시스템들 및 방법들이 본 명세서에 개시된다. 실시예에서, 비디오 게임의 프레임의 렌더링은 컴퓨팅 디바이스의 상이한 코어들에서 각각 실행될 수 있는 적어도 2개의 상이한 스레드에 의해 분리되어 실행될 수 있다. 실시예에서, 게임 로직 업데이트들 및 렌더링 로직이 원래 스레드에서 계속 실행될 수 있는 동안 커맨드 스트림이 커맨드 스트림 스레드에서 실행될 수 있다. 커맨드 스트림은 하나 이상의 커맨드, 또는 프레임의 객체들 및 양상들을 렌더링하는 데 사용되는 하나 이상의 그래픽 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)(API)들에 대한 호출들을 포함한다. 실시예에서, 커맨드 스트림 내의 커맨드들은 비디오 게임의 프레임 레이트를 최적화하도록 수정될 수 있다. 실시예에서, 시각적 향상들 또는 효과들이 커맨드 스트림에 부가적으로 추가되어 렌더링되는 프레임의 해상도 또는 품질을 최적화할 수 있다.

도 1a 및 도 1b는 본 개시내용의 다양한 실시예에 따른 커맨드 스트림 최적화 및 향상을 도시하는 다이어그램들(100A 및 100B)이다. 특히, 도 1a 및 도 1b는 단일 스레드 렌더링(single-thread rendering)(103)을 사용하여 비디오 게임의 프레임들(105A-C)을 렌더링하는 예들, 및 다중 스레드 렌더링(multi-thread rendering)(106A-B)을 사용하여 비디오 게임의 프레임들(105A-C)을 렌더링하는 예를 도시한다. 단일 스레드 렌더링(103)은 컴퓨팅 디바이스의 단일 코어에서 실행되는 단일 스레드를 사용하여 비디오 게임의 프레임들(105A-C) 각각의 프로세싱 및 렌더링을 의미한다. 컴퓨팅 디바이스의 코어는 컴퓨팅 디바이스의 컴퓨팅 컴포넌트 또는 프로세싱 유닛을 의미한다. 컴퓨팅 디바이스의 추가 컴포넌트들은 아래에서 도 2 및 도 3과 관련하여 더 자세히 설명될 것이다. 다중 스레드 렌더링(106A-B)은 컴퓨팅 디바이스의 다수의 코어에서 실행되는 다수의 스레드를 사용하여 비디오 게임의 프레임들(105A-C) 각각의 프로세싱 및 렌더링을 의미한다.

프레임들(105A-C)의 프로세싱 및 렌더링은 전형적으로 3개의 상이한 유형의 로직: 게임 로직 업데이트들(110), 렌더링 로직(113) 및 커맨드 스트림(115)으로 분류될 수 있는 프레임 로직(107)을 포함한다. 게임 로직 업데이트들(110)은 그 특정 프레임(105A-C)에 대한 게임의 시뮬레이션을 서술하기 위해 사용되는 로직 또는 소프트웨어 컴포넌트들을 의미한다. 게임 로직 업데이트들(110)은 처리되고 렌더링되는 프레임(105A-C) 내의 객체들의 위치들, 프레임에 디스플레이되는 문자들, 문자들에 의해 사용되는 툴들, 설정 객체들 등과 같은 프레임(105A-C)의 컴포넌트들을 결정할 수 있다. 게임 로직 업데이트들(110)은 처리되고 렌더링되는 프레임(105A-C) 상에 디스플레이된 객체들 사이의 관계와 같은 프레임(105A-C)의 컴포넌트들 사이의 관계 또는 프록시들을 또한 포함할 수 있다.

게임 로직 업데이트들(110)의 시뮬레이션 결과들에 기초하여, 렌더링 엔진은 렌더링 로직(113) 및 커맨드 스팀(115)을 사용하여 수행될 수 있는 프레임(105A-C)의 실제 렌더링을 수행하기 위해 사용될 수 있다. 렌더링 엔진은 컴퓨팅 디바이스의 스크린에 텍스트들 및 이미지들을 그리는 소프트웨어이다. 기존의 렌더링 엔진의 예들은 UNITY, UNREAL ENGINE, COCOS, OGRE 등을 포함한다. 인식해야 하는 바와 같이, 임의의 렌더링 엔진은 렌더링 로직(113) 및 커맨드 스트림(115)을 처리하고 실행하여 비디오 게임을 위한 프레임(105A-C)을 렌더링하는 데 사용될 수 있다.

렌더링 엔진은 비디오 게임의 상이한 프레임들(105A-C) 상에 디스플레이되는 객체들 및 양상들을 렌더링하는 데 사용되는 표준 렌더링 로직(113)을 포함하거나 유지할 수 있다. 렌더링 엔진은 또한 프레임(105A-C)의 하나 이상의 컴포넌트를 렌더링하기 위해 호출되고 사용될 수 있는 커맨드들을 결정할 수 있다. 실시예에서, 커맨드들은 렌더링 엔진이 게임 로직 업데이트들(110)에 의해 식별된 컴포넌트에 기초하여 호출하기 위해 선택하는 그래픽 API들을 의미할 수 있다. 커맨드 스트림(115)은 프레임(105A-C)을 렌더링하는데 사용될 수 있는 렌더링 엔진에 의해 결정된 커맨드들의 집합을 의미한다. 따라서 커맨드 스트림(115)은 프레임(105A-C)의 컴포넌트들을 렌더링하기 위해 호출되는 커맨드들의 시퀀스 또는 그래픽 인터페이스들에 대한 호출들을 포함할 수 있다. 커맨드 스트림(115) 내의 커맨드들의 시퀀스는 프레임(105A-C)의 컴포넌트들 사이의 종속성 관계들에 기초하여 렌더링 엔진에 의해 결정되는 특정 순서로 유지될 수 있다.

커맨드 스트림(115) 및 렌더링 로직(113)이 도 1a에서 개별적으로 도시되어 있지만, 커맨드 스트림(115) 및 렌더링 로직(113)은 인터리빙될 수 있다. 도 1에 도시된 바와 같이, 렌더링 로직(113)은 커맨드들(270A-D)과 인터리빙되는 복수의 렌더링 로직(113A-E)을 포함할 수 있다. 실시예에서, 커맨드 스트림(115)을 구성하는 것은 도 5를 참조하여 아래에서 더 자세히 설명되는 바와 같이 렌더링 로직(113A-E)으로부터 커맨드들(270A-D)을 추출하는 것을 포함한다. 도 1a는 5개 부분의 렌더링 로직(113A-E)과 4개 부분의 커맨드들(270A-D) 만을 도시하지만, 로직(107)은 임의의 개수의 부분들의 렌더링 로직(113)과 커맨드들(270)을 포함할 수 있다는 것을 인식하여야 한다.

프레임(105A-C)에 대한 게임 로직 업데이트들(110), 렌더링 로직(113) 및 커맨드 스트림(115)을 결정한 후에, 그래픽 프로세싱 유닛(Graphical Processing Unit)(GPU) 커맨드들이 구성된 다음에 이어서 GPU로 전송되어 프레임(105A-C)의 실제 하드웨어 렌더링을 수행할 수 있다. 위에서 설명한 바와 같이, 커맨드들(270)은 그래픽 API들에 대한 호출들이고, GPU 커맨드들은 커맨드들(270)의 기능들에 대응하고 GPU에 의해 실행되는 어셈블리 언어 명령어들이다. GPU의 동작들은 도 4와 관련하여 아래에서 더 자세히 설명될 것이다.

컴퓨팅 디바이스가 단일 스레드 렌더링(103)을 사용할 때, 프레임들(105A-C) 각각에 대한 게임 로직 업데이트들(110), 렌더링 로직(113) 및 커맨드 스트림(115)을 실행하는 것에 관련되는, 프레임들(105A-C)의 프로세싱 및 렌더링은 전형적으로 컴퓨팅 디바이스의 단일 코어에서 실행되는 단일 스레드(본 명세서에서 원래 스레드(120)라고 지칭됨)에 의해 실행된다. 그러나, 도 1a에 도시된 바와 같이, 단일 스레드 렌더링(103)은 전형적으로 프레임(105A-C)을 60 FPS의 산업 표준 프레임 레이트(109)보다 낮은 프레임 레이트로 렌더링한다. 비디오 게임 또는 컴퓨팅 디바이스가 프레임들(105A-C)이 60 FPS라는 더 높은 프레임 레이트로 렌더링될 것을 요구하는 일부 경우에, 박스(121)에서 보는 바와 같이, 프레임들(105A-C)이 컴퓨팅 디바이스에 의해 디스플레이되기도 전에 프레임들(105A-C)이 드롭될 수 있다. 그래픽들에서, 프레임(105A-C)이 드롭될 때, 그 프레임(105)의 렌더링은 나중으로 연기되고, 이것은 평균 프레임 레이트를 떨어뜨리게 한다.

본 명세서에 개시된 실시예들은 프레임들(105A-C)을 60 FPS의 산업 표준 프레임 레이트(109)에 더 가까운 프레임 레이트로 렌더링하는 다중 스레드 렌더링(106A-B)에 관한 것이다. 도 1a에 의해 도시된 바와 같이, 다중 스레드 렌더링(106A)은 프레임 로직(107)에 기초하여 프레임(105A-C)을 렌더링하여 커맨드 스트림(115)을 생성하도록 실행되어야 하는 커맨드들 또는 그래픽 API 호출들을 결정하는 것을 수반한다. 커맨드 스트림(115)은 컴퓨팅 디바이스의 별개의 코어에서 실행되는 별개의 스레드(본 명세서에서 커맨드 스트림 스레드(125)으로 지칭됨)로 이전될 수 있고, 그래서 커맨드 스트림 스레드(125)는 커맨드 스트림(115)을 실행할 수 있다. 이러한 방식으로, 원래 스레드(120)는 게임 로직 업데이트들(110) 및 렌더링 로직(113)을 포함하는 게임 및 렌더링 로직(127)을 실행할 수 있는 반면, 커맨드 스트림 스레드(125)는 병렬로 커맨드 스트림(115)을 실행한다.

도 1a에 의해 도시된 바와 같이, 프레임(105A)은 게임 및 렌더링 로직(127A) 및 커맨드 스트림(115A)으로 분리될 수 있는 프레임 로직(107)을 실행함으로써 생성될 수 있다. 게임 및 렌더링 로직(127A)은 프레임(105A)을 렌더링하는데 사용되는 게임 로직 업데이트(110) 및 렌더링 로직(113)을 포함한다. 게임 및 렌더링 로직(127A)은 원래 스레드(120)에 의해 실행되도록 남아있을 수 있는 반면, 커맨드 스트림(115A)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다. 유사하게, 프레임(105B)은 게임 및 렌더링 로직(127B) 및 커맨드 스트림(115B)으로 분리될 수 있다. 게임 및 렌더링 로직(127B)은 원래 스레드(120)에 의해 실행되게 남아있을 수 있는 반면, 커맨드 스트림(115B)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다. 프레임(105C)은 유사하게 게임 및 렌더링 로직(127C) 및 커맨드 스트림(115C)으로 분리될 수 있다. 게임 및 렌더링 로직(127C)은 원래 스레드(120)에 의해 실행되도록 남아있을 수 있는 반면, 커맨드 스트림(115C)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다.

도 1b는 다중 스레드 렌더링(106B)가 프레임 로직(107)을 딱 2개의 스레드 대신에 3개의 별개 스레드(예를 들어, 원래 스레드(120), 렌더링 로직 스레드(175) 및 커맨드 스트림 스레드(125))에서 실행되도록 분할하는 것을 수반한다는 점을 제외하고는, 다중 스레드 렌더링(106A)과 유사한 다중 스레드 렌더링(106B)의 실시예를 도시한다. 도 1b에 도시된 바와 같이, 다중 스레드 렌더링(106A)은 프레임 로직(107)에 기초하여 프레임(105A-C) 프레임을 렌더링하기 위해 실행되어야 하는 렌더링 로직(113) 및 커맨드 스트림(115)을 결정하는 것을 수반한다. 실시예에서, 원래 스레드(120)는 렌더링 로직(113) 및 커맨드 스트림(115)에 대한 커맨드들을 결정한다. 렌더링 로직(113)은 컴퓨팅 디바이스의 별개의 코어에서 실행되는 렌더링 로직 스레드(175)로 이전될 수 있고, 그래서 렌더링 로직 스레드(175)는 렌더링 로직을 실행할 수 있다. 유사하게, 커맨드 스트림(115)은 컴퓨팅 디바이스의 제3 코어에서 또한 실행되는 커맨드 스트림 스레드(125)로 이전될 수 있고, 그래서 커맨드 스트림 스레드(125)가 커맨드 스트림(115)을 실행할 수 있다. 이러한 방식으로, 원래 스레드(120), 렌더링 로직 스레드(175) 및 커맨드 스트림 스레드(125)의 각각은 게임 로직 업데이트(110), 렌더링 로직(113) 및 커맨드 스트림(115)을 순차적이 아닌 병렬로 실행할 수 있다. 게임 로직 업데이트(110), 렌더링 로직(113) 및 커맨드 스트림(115)의 병렬 실행은 비디오 게임을 렌더링하는 컴퓨팅 디바이스의 프레임 레이트를 실질적으로 증가시킬 수 있게 한다.

도 1b에 의해 도시된 바와 같이, 프레임(105A)은 게임 로직 업데이트(110A), 렌더링 로직(113A) 및 커맨드 스트림(115A)으로 분리될 수 있는 프레임 로직(107)을 실행함으로써 생성될 수 있다. 게임 로직 업데이트(110A)는 원래 스레드(120)에 의해 실행되도록 남아있을 수 있는 반면, 렌더링 로직(113A)은 렌더링 로직 스레드(175)에 의해 실행되도록 렌더링 로직 스레드(175)로 이전된다. 유사하게, 커맨드 스트림(115A)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다. 프레임(105B)은 또한 게임 로직 업데이트(110B), 렌더링 로직(113B) 및 커맨드 스트림(115B)으로 분리될 수 있다. 게임 로직 업데이트(110B)는 원래 스레드(120)에 의해 실행되도록 남아있을 수 있는 반면, 렌더링 로직(113B)은 렌더링 로직 스레드(175)에 의해 실행되도록 렌더링 로직 스레드(175)로 이전된다. 유사하게, 커맨드 스트림(115B)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다. 프레임(105C)은 유사하게 게임 로직 업데이트(110C), 렌더링 로직(113C) 및 커맨드 스트림(115C)으로 분리될 수 있다. 게임 로직 업데이트(110C)는 원래 스레드(120)에 의해 실행되도록 남아있을 수 있는 반면, 렌더링 로직(113C)은 렌더링 로직 스레드(175)에 의해 실행되도록 렌더링 로직 스레드(175)로 이전된다. 유사하게, 커맨드 스트림(115C)은 커맨드 스트림 스레드(125)에 의해 실행되도록 커맨드 스트림 스레드(125)로 이전된다.

다중 스레드 렌더링(106A-B)에 관한 부가적인 상세한 설명들은 도 5 내지 도 15와 관련하여 아래에서 더 자세히 설명된다. 프레임들(105A-C)을 단일 스레드 렌더링(103)한 결과로서 생성된 프레임 레이트와 동일 프레임들(105A-C)을 다중 스레드 렌더링(106A-B)한 결과로서 생성된 프레임 간의 차이가 도 1a 및 도 1b에 도시된다. 구체적으로는, 도 1a는 원래 스레드(120)를 통한 게임 및 렌더링 로직(127)과 커맨드 스트림 스레드(125)를 통한 커맨드 스트림(115)의 병렬 실행이 전체 프레임(105A-C)을 훨씬 더 높은 프레임 레이트로 처리되고 렌더링될 수 있게 한다는 것을 보여준다. 유사하게, 도 1b는 원래 스레드(120)를 통한 게임 로직 업데이트(110), 렌더링 로직 스레드(175)를 통한 렌더링 로직(113), 및 커맨드 스트림 스레드(125)를 통한 커맨드 스트림(115)을 병렬 실행하는 것이 전체 프레임(105A-C)을 훨씬 더 빠른 프레임 레이트로 처리되고 렌더링될 수 있게 한다는 것을 보여준다.

도 1a 및 도 1b는 3개의 프레임(105A-C)만을 도시하지만, 비디오 게임은 임의의 개수의 프레임(105A-C)을 포함할 수 있다는 것을 인식하여야 한다. 프레임들(105A-C)이라는 용어는 이하에서 비디오 게임용 프레임들 중 하나 이상을 포함할 수 있는 프레임들(105)로서 지칭될 것이다. 다중 스레드 렌더링(106A-B)이라는 용어는 이하에서 다중 스레드 렌더링(106A) 또는 다중 스레드 렌더링(106B)을 나타낼 수 있는 다중 스레드 렌더링(106)으로 지칭될 것이다.

도 2는 본 명세서에 개시된 커맨드 스트림 최적화 및 향상을 위한 다양한 실시예를 지원하기에 적합한 컴퓨팅 디바이스(200)의 개략도이다. 컴퓨팅 디바이스(200)는 모바일 폰, 모바일 태블릿, 웨어러블 디바이스, 퍼스널 컴퓨터(personal computer)(PC), 랩톱 등과 같은 디바이스, 또는 사용자를 대신하여 비디오 게임과 같은 그래픽 애플리케이션들을 실행할 수 있는 다른 디바이스일 수 있다.

컴퓨팅 디바이스(200)는 포트들(210), 송수신기 유닛들(Tx/Rx)(220), 프로세서(230) 및 메모리(240)를 포함한다. 포트들(210)은 정보가 수신되고 송신되는 컴퓨팅 디바이스(200)의 엔드포인트들이다. 이러한 방식으로, 포트들(210)은 Tx/Rx(220)에 결합되고, Tx/Rx(220)는 송신기들, 수신기들 또는 이들의 조합일 수 있다. Tx/Rx(220)는 포트들(210)를 통해 데이터를 송신하고 수신할 수 있다. 프로세서(230)는 데이터를 처리하도록 구성된다. 메모리(240)는 본 명세서에 설명된 실시예들을 구현하기 위한 데이터 및 명령어들을 저장하도록 구성된다.

프로세서(230)는 2개 이상의 코어(233, 234, 및 237)를 포함하는 다중 코어 프로세서일 수 있다. 코어들(233, 234, 237)은 단일 칩 멀티프로세서 또는 단일 칩 패키지 상에 통합될 수 있다. 코어들(233, 234, 237)은 프로그램 명령어들을 독립적으로 판독하고 실행하는, 프로세서(230) 내의 독립적인 프로세싱 유닛들일 수 있다. 별개의 코어들(233, 234, 237)은 예를 들어, 동시에 상이한 스레드들을 실행함으로써 동시에 다수의 명령어들을 실행할 수 있다. 실행의 스레드는 제1 코어(233) 또는 제2 코어(234)에 의해 처리되는 프로그램 명령어들의 시퀀스를 의미한다. 도 2에 의해 도시된 바와 같이, 원래 스레드(120)는 제1 코어(233)에 의해 실행될 수 있고, 커맨드 스트림 스레드(125)는 제2 코어(234)에 의해 실행될 수 있으며, 렌더링 로직 스레드(175)는 제3 코어(237)에 의해 실행될 수 있다.

프로세서(230)(예를 들어, 각각의 코어들(233 및 234))는 포트들(210), Tx/Rx(220) 및 메모리(240)와 통신한다. 최적화 모듈(235)은 두 코어(233 및 234) 모두에 의해 본 명세서에서 논의되는 다양한 실시예를 구현하기 위한 명령어들을 실행하도록 구현된다. 예를 들어, 최적화 모듈(235)은, 원래 스레드(120)가 프레임 로직(107)의 게임 및 렌더링 로직(127) 부분을 실행할 수 있고, 반면에 커맨드 스트림 스레드(125)가 프레임 로직(107)의 커맨드 스트림(115) 부분을 실행하는, 프레임 로직(107)을 실행하도록 구성된다.

메모리(240)는 더블 데이터 레이트(double data rate)(DDR) 및/또는 정적 랜덤 액세스 메모리(static random-access memory)(SRAM)를 포함한다. DDR은 동기식 동적 랜덤 액세스 메모리(dynamic random access)(DRAM)의 고급 버전이며, 도 3을 참조하여 아래에서 더 자세히 설명되는 바와 같이 프로세서(230)와 그래픽 프로세싱 유닛 사이에 데이트를 반송하는 데 사용될 수 있다. 실시예에서, 메모리(240)는 디스크들, 테이프 드라이브들 또는 솔리드-스테이트 드라이브들 중 하나 이상을 포함하고 오버-플로우 데이터 저장 디바이스로서 사용되어, 프로그램들이 실행을 위해 선택될 때 그러한 프로그램들을 저장하고 프로그램 실행 중에 판독되는 명령어들 및 데이터를 저장하는 데 사용될 수 있다. 메모리(240)는 휘발성 및 비 휘발성일 수 있고 판독 전용 메모리(read-only memory)(ROM), 랜덤-액세스 메모리(random-access memory)(RAM), TCAM(ternary content-addressable memory) 및 정적 랜덤-액세스 메모리(static random-access memory)(SRAM)일 수 있다. 메모리(240)는 캐시를 더 포함할 수 있다.

도 2에 의해 도시된 바와 같이, 메모리(240)는 커맨드들(270), 커맨드 스트림(115), 임계치(280), 커맨드 버퍼(285) 및 프레임들(105)을 포함한다. 커맨드 스트림(115) 및 프레임들(105)은 도 1a 및 도 1b를 참조하여 위에서 설명된다. 커맨드들(270)은 프레임(105)의 프로세싱 및 렌더링 동안 호출될 수 있는 그래픽 API들을 의미한다. 커맨드 버퍼(285)는 프레임(105)에 대해 결정된 커맨드들(270)이 저장되는 메모리(240)의 캐시일 수 있다. 임계치(280)는 커맨드 스트림 스레드(125)가 커맨드 스트림(115)의 실행을 시작하기 전에 커맨드 버퍼(285)에 저장된 최소 개수의 커맨드들(270)에 대응하는 값이며, 이는 도 12를 참조하여 아래에서 더 자세히 설명될 것이다.

도 3은 도 3에 도시된 컴퓨팅 디바이스(300)가 컴퓨팅 디바이스(300)에서 비디오 게임을 실행하는 동안 사용될 수 있는 계층들(303, 306, 309 및 311)을 도시한다는 점을 제외하고는, 컴퓨팅 디바이스(200)와 유사한 컴퓨팅 디바이스(300)의 다른 실시예이다. 컴퓨팅 디바이스(300)는 하드웨어 및 칩 계층(303), 운영 체제(OS) 및 플랫폼 계층(306), 게임 엔진 계층(309), 및 게임 계층(303)을 포함한다.

하드웨어 및 칩 계층(303)은 컴퓨팅 디바이스(300)를 위한 전자 회로들 및 부품들을 갖는 마이크로칩인 시스템 온 칩(system on chip)(SOC)(315)을 포함할 수 있다. SOC(315)는 중앙 프로세싱 유닛(central processing unit)(CPU)(318), GPU(321) 및 더블 데이터 레이트(DDR)(323)를 포함할 수 있다. CPU(318)는 다수의 코어(233 및 234)를 포함하는 프로세서(230)와 유사할 수 있다. GPU(321)는 그래픽 프로세싱 및 렌더링을 위한 계산 프로세싱 유닛이다. DDR(323)은 동기식 동적 랜덤 액세스 메모리(DRAM)의 고급 버전이다. DDR(323)은 CPU(318) 및 GPU(321)와 함께 사용되어 CPU(318)와 GPU(321) 사이에서 데이터를 반송할 수 있다. 본 명세서에 개시된 커맨드 스트림 최적화 및 향상의 실시예들은 도 4를 참조하여 아래에서 추가로 논의되는 바와 같이, SOC(315)의 CPU(318), GPU(321) 및 DDR(323)에 의해 구현될 수 있다.

네트워크 컴포넌트들(325), 디스플레이(327), 디스크(328), 터치 스크린(329) 및 오디오 스피커/마이크로폰(345)은 비디오 게임의 실행 및 비디오 게임의 사용자 경험과 관련된 하드웨어 컴포넌트들일 수 있다. 그러나, 네트워크 컴포넌트들(325), 디스플레이(327), 디스크(328), 터치 스크린(329) 및 오디오 스피커/마이크로폰(345)은 본 명세서에 개시된 커맨드 스트림 최적화 및 향상의 실시예들에 의해 영향을 받지 않는다.

OS 및 플랫폼 계층(306)은 하나 이상의 그래픽 API(330), 그래픽 드라이버들(331), 합성기(compositor)(332), 동적 전압 및 주파수 스케일러(dynamic voltage and frequency scaler)(DVFS)(333), 스케줄러(344), 열 제어기(335) 및 하나 이상의 디바이스 드라이버(336)를 포함한다. 하나 이상의 그래픽 API(330)는 커맨드들(270)에 대응할 수 있고 게임 엔진 계층(309)에 의해 호출되어 프레임(105)의 컴포넌트들을 렌더링하는 API일 수 있다. 그래픽 드라이버들(331)은 하드웨어 및 칩 계층(303)에 있는 컴포넌트들과 통신하는 데 사용되는 컴퓨팅 디바이스(300)에서 실행되는 OS 용으로 작성된 소프트웨어이다. 합성기(332)는 DDR(323)로부터 프레임(105)을 검색한 다음 프레임(105)을 컴퓨팅 디바이스(300)의 디스플레이(327) 상에 디스플레이하는 소프트웨어이다. DVFS(333)는 컴퓨팅 디바이스(300)의 CPU(318), GPU(321) 및 DDR(323)의 전력 및 속도 설정들을 조정하는 데 사용되는 소프트웨어이다. 스케줄러(334)는 컴퓨팅 디바이스(300)에서 발생하는 다양한 기능 및 이벤트의 실행 순서를 관리하는 소프트웨어이다. 열 제어기(335)는 컴퓨팅 디바이스(300)의 온도를 검출한 다음 하드웨어 및 칩 계층(303) 컴포넌트들을 조정하여 컴퓨팅 디바이스(300)의 온도를 조정하는 소프트웨어일 수 있다. 디바이스 드라이버들(336)은 컴퓨팅 디바이스(300)에 부착된 디바이스들을 제어하는 소프트웨어 또는 프로그램들이다.

게임 엔진 계층(309)은 렌더링 엔진의 일부이고 렌더링 엔진에 의해 프레임(105)을 처리하고 렌더링하기 위해 사용되는 소프트웨어 컴포넌트들을 포함할 수 있다. 예를 들어, 게임 엔진 계층(309)은 게임 및 렌더링 로직 업데이트들(110)에 의해 식별된 프레임(105)의 컴포넌트들을 비디오 게임에 의해 호출되는 커맨드들(270)로 변환하도록 구성될 수 있다. 게임 엔진 계층(309)은 물리 엔진(377), 장면들/객체들(338), 렌더러(339) 및 이벤트들/스크립트들(340)을 포함할 수 있다. 물리 엔진(377)은 컴퓨터 그래픽들, 비디오 게임들 및 영화의 영역들에서 사용되는 (충돌 감지를 비롯한) 강체 역학들, 연체 역학들 및 유체 역학들과 같은 특정 물리적 시스템들의 대략적인 시뮬레이션을 제공하는 소프트웨어이다. 장면들/객체들(338)은 게임이 장면에 렌더링되는 객체들을 서술하고 관리하기 위해 사용하는 로직 유닛들을 포함할 수 있으며, 여기서 장면은 다수의 객체(예를 들어, 캐릭터들, 건물들, 발사(fire)들, 나무들 등)를 포함할 수 있다. 게임은 또한 다수의 장면(예를 들어, 훈련장들, 사이트 A, 사이트 B 등)을 포함할 수 있다. 렌더러(339)는 프레임(105)을 실제로 렌더링하는 렌더링 엔진의 소프트웨어일 수 있다. 이벤트들/스크립트들(340)은 게임이 게임 엔진 계층(309)과 통신하기 위해 동적으로 사용할 수 있는 시스템을 포함할 수 있다. 이벤트들은 예를 들어 시작, 재생, 종료되는 애니메이션, 시야 안팎으로 움직이는 객체들 등과 같이 게임 중에 발생하는 이벤트들을 의미한다. 스크립트는 예를 들어 장면으로부터 장애의 제거, 조명 조건들 또는 파라미터들의 업데이트 등과 같이 이벤트들에 반응하는 게임에 의해 정의된 로직을 의미한다.

게임 계층(311)은 계정들(341), 시뮬레이션/인공 지능(artificial intelligence)(AI)(342), 레벨 디자인(343) 및 자산들/자원들(344)과 같은 특정 비디오 게임과 관련된 데이터를 포함할 수 있다. 계정들(341)은 게임 계층(311)과 연관된 비디오 게임의 다양한 사용자의 계정들을 의미할 수 있다. 시뮬레이션/AI(342)는 비디오 게임의 다양한 프레임(105)에 대한 시뮬레이션 및 AI를 포함한다. 레벨 디자인(343)은 비디오 게임의 다양한 레벨에 관한 데이터를 포함할 수 있다. 자산들/자원들(344)은 비디오 게임에 특유할 수 있는 프레임들(105)에 포함된 객체들의 특정 자산들 또는 자원들에 관한 데이터를 포함할 수 있다. 예를 들어, 자산들/자원들(344)은 객체의 모양, 객체의 질감, 객체의 재료 또는 객체의 일반적인 모습을 정의하는 3차원(three dimensional)(3D) 메시들일 수 있다.

구현 동안, 이러한 계층들(303, 306, 309 및 311) 각각의 컴포넌트들은 사용자 입력에 기초하여 비디오 게임의 실행 동안 하나 이상의 프레임(105)을 처리하고 렌더링하도록 개시될 수 있다. 하나의 실시예에서, 커맨드 스트림 최적화 및 향상은 도 4를 참조하여 아래에서 더 자세히 설명되는 바와 같이, OS 및 플랫폼 계층(306)에 의해 수행될 수 있다. 일부 경우에, 게임 엔진 계층(309) 및 그래픽 드라이버들(664)은 본 명세서에 개시된 커맨드 스트림 최적화 및 향상 메커니즘들을 구현하도록 변경되지 않는다.

하나의 실시예에서, 커맨드 스트림 최적화 및 향상의 실시예들은 계층(303, 306, 309, 또는 311)이 렌더링 로직(113)으로부터의 커맨드들(270)을 캡처하고, 커맨드들(270)을 커맨드 버퍼(285)에 저장하여 커맨드 스트림(115)을 생성하고, 커맨드 스트림(115) 내의 커맨드들(270)을 재구성한 다음, 커맨드 스트림 스레드(125)에서 커맨드 스트림(115)을 실행하도록 구성되는 한 계층들(303, 306, 309 및 311) 중 임의의 계층에 의해 수행될 수 있다. 예를 들어, 커맨드 스트림 최적화 및 향상의 실시예들은 사용자 모드 드라이버(하나 이상의 디바이스 드라이버(336)), 게임 엔진 계층(309)에서 실행되는 게임 엔진, 또는 게임 계층(311)에서 실행되는 애플리케이션 자체에 의해 수행될 수 있다. 실시예에서, 커맨드 스트림(115) 내의 복수의 커맨드(270) 각각은 컴퓨팅 디바이스(300)의 게임 계층(311)에서 구현된 인터페이스에 대한 호출을 포함한다. 실시예에서, 커맨드 스트림(115) 내의 복수의 커맨드(270) 각각은 컴퓨팅 디바이스(300)의 게임 엔진 계층(309)에서 구현된 인터페이스에 대한 호출을 포함한다.

일부 경우에, 커맨드 스트림 최적화 및 향상의 실시예들이 드라이버 레벨(하나 이상의 디바이스 드라이버(336))에서 수행될 때, 렌더링 로직(113)으로부터 커맨드들(270)을 캡처하고 커맨드들(270)을 커맨드 버퍼(285)에 저장하는 단계들은 드라이버들(하나 이상의 디바이스 드라이버(336))가 렌더링 로직(113)으로부터 커맨드들(270)을 캡처하고 커맨드들(270)을 커맨드 버퍼(285)에 저장하는 캡처 및 저장 단계들에 필요한 정보를 이미 저장하고 있기 때문에 매우 단순화될 수 있다. 예를 들어, 하나 이상의 디바이스 드라이버는 렌더링 로직(113)으로부터 커맨드들(270)을 캡처하고, 커맨드들(270)을 커맨드 버퍼(285)에 저장하여 커맨드 스트림(115)을 생성하고, 커맨드 스트림(115) 내의 커맨드들(270)을 재구성한 다음, 커맨드 스트림 스레드(125)에서 커맨드 스트림(115)을 실행하는 단계들이 모두 동일한 계층들(303, 306, 309 또는 311)에서 구현될 필요가 없는 실시예를 수행하도록 구성될 뿐일 수 있다.

도 4는 비디오 게임 애플리케이션(403)의 프레임들(105)을 처리하고 렌더링할 때 비디오 게임 애플리케이션(403), OS 및 플랫폼 계층(306), DDR(323) 및 GPU(321) 사이의 데이터 흐름을 도시하는 다이어그램(400)이다. 데이터 흐름은 특정 프레임(105)에 대한 게임 로직 업데이트(110) 및 렌더링 로직(113)의 실행(406)으로부터 시작될 수 있다. 위에서 설명한 바와 같이, 게임 로직 업데이트(110)는 프레임(105)에 디스플레이될 객체들 및 양상들과 같은 프레임(105)의 컴포넌트들을 결정하며, 렌더링 로직(113)은 프레임(105)을 렌더링할 기본 렌더링 기능들을 수행한다. 렌더링 로직(113)을 수행하는 동안, 프레임(150)의 컴포넌트들을 렌더링하기 위해 호출되어야 하는 그래픽 API들(330)에 대한 호출들과 같은 커맨드들(270)이 결정될 수 있다. 게임 로직 업데이트(110) 및 렌더링 로직(113)의 실행(406)은 컴퓨팅 디바이스(200 또는 300)의 제1 코어(233)의 원래 스레드(120)에 의해 수행될 수 있다. 제1 코어(233)의 원래 스레드(120)는 또한 프레임(105)을 렌더링하기 위해 호출할 커맨드들(270)을 결정할 수 있다.

이 시점에서, 그래픽 시스템 런타임(410)은 렌더링 엔진에 의해 결정된 커맨드들(270)에 기초하여 커맨드 스트림 최적화 및 향상의 실행(406)을 시작할 수 있다. 실시예에서, 그래픽 시스템 런타임(410)은 프레임 로직(107)으로부터 커맨드들(270)을 캡처하여(예를 들어, 결정하여) 커맨드 스트림(115)을 생성할 수 있다. 커맨드들(270) 각각은 예를 들어 메모리(240)의 캐시에 일시적으로 저장될 수 있다. 커맨드들(270)은 이어서 커맨드 스트림 스레드(125)가 커맨드 스트림(115)의 커맨드들(270)을 실행할 수 있도록 제2 코어(234)로 전송될 수 있다. 실시예에서, 커맨드 스트림 스레드(125)는 게임 및 렌더링 로직(127)을 실행하는 원래 스레드(120)와 실질적으로 병렬로 커맨드 스트림(115)을 실행할 수 있으며, 이것은 프레임(105)을 처리하고 렌더링하는 데 필요한 시간의 양을 감소시키고 따라서 비디오 게임의 프레임 레이트를 증가시킨다.

도 9를 참조하여 아래에서 추가로 논의되는 바와 같이, 커맨드 스트림(115) 내의 커맨드들(270)은 커맨드들(270)의 중복성들 및 파라미터들에 기초하여 수정될 수 있다. 커맨드 스트림(115) 내의 커맨드들(270)의 이러한 수정들은 비디오 게임의 프레임 레이트를 더 증가시키고 비디오 게임의 전력 소비를 더 감소시킬 수 있다.

게임 및 렌더링 로직(127)을 커맨드 스트림(115)으로부터 분리하여 게임 및 렌더링 로직(127)과 커맨드 스트림(115)이 상이한 스레드들(120 및 125)에 의해 실행(다중 스레드 렌더링(106A))되도록 한 후에, 데이터 흐름은 사용자 모드 드라이버(413)의 호출을 계속할 수 있다. 유사하게, 게임 로직 업데이트(110), 렌더링 로직(113) 및 커맨드 스트림(115)을 프레임 로직(107)으로부터 분리하여 게임 로직 업데이트(110), 렌더링 로직(113) 및 커맨드 스트림(115)이 상이한 스레드들에 의해 실행(다중 스레드 렌더링(106B))되도록 한 후에, 데이터 흐름은 사용자 모드 드라이버(413)의 호출을 계속할 수 있다. 사용자 모드 드라이버(413)는 캡처 및 캐시된 커맨드들(270) 각각에 대한 그래픽 API들(330)의 실제 구현의 매칭(예를 들어, 코드)을 저장할 수 있다. 예를 들어, 사용자 모드 드라이버(413)는 캐시된 커맨드들(270)에 대응하는 소프트웨어 코드를 식별한다. 실시예에서, 사용자 모드 드라이버(413)는 제2 코어(234)의 커맨드 스트림 스레드(125)에 의해 실행될 수 있다. 커맨드들은 커맨드를 호출하는 데 사용될 수 있는 데이터 전송 및 GPU 커맨드 변환을 수행하는 사용자 모드 드라이버(413) 쪽으로 호출될 수 있다. GPU 커널 모드 드라이버(416)는 데이터를 CPU(318)의 메모리(240)로부터 GPU(321)로 복사하도록 구성될 수 있다. DDR(323)은 커맨드들(270)에 대응하는 GPU 커맨드들(419) 및 비디오 게임 애플리케이션(403)과 연관된 자산들/자원들(344)과 같은 임의의 데이터 및 자원들(421)을 저장할 수 있다. GPU(321)는 DDR(323)로부터 GPU 커맨드들(419) 및 데이터 및 자원들(421)에 액세스할 수 있다.

GPU(321)는 데이터 및 자원들(421)을 사용하여 GPU 커맨드들(419)을 실행할 수 있고 프레임(105)을 렌더링하기 위해 버텍스 셰이딩(vertex shading)(424) 및 프래그먼트 셰이딩(fragment shading)(427)과 같은 다른 그래픽 프로세싱 단계들을 수행할 수 있다. 버텍스 셰이딩(424)은 프레임(105)에 의해 디스플레이된 다양한 객체의 위치 설정 정보를 식별하고 정해주는 것과 관련된다. 프래그먼트 셰이딩(427)은 프레임(105)의 각 픽셀의 컬러를 결정하고 정해주는 것과 관련된다. 도 4와 관련하여 버텍스 셰이딩(424) 및 프래그먼트 셰이딩(427)만 설명되지만, 렌더링 프로세스 동안 GPU(321)에 의해 다른 유형들의 계산들, 결정들 또는 그래픽 향상들이 수행될 수 있다는 것을 인식하여야 한다. 그 다음에 객체들은 프레임 버퍼(430)로 렌더링될 수 있고, 프레임 버퍼는 GPU 메모리에 저장된 다음 커널 드라이버(416)에 의해 DDR(323)에 복사된다. 합성기(332)는 DDR(323)의 프레임 버퍼(430)로부터 콘텐츠를 포착한 다음 프레임(105)을 디스플레이(327) 상에 렌더링할 수 있다.

위에 도시된 데이터 흐름에 기초하여, CPU(318) 상의 대부분의 작업 부하는 게임 로직 업데이트(110), 렌더링 로직(113) 및 커맨드들(270)의 실행에서 비롯된다. GPU(321) 상의 작업 부하는 거의 전적으로 그래픽 렌더링에서 비롯된다. DDR(323)은 CPU(318)와 GPU(321) 사이의 데이터 브리지이며, DDR(323)은 CPU(318)와 GPU(321)의 성능과 효율성에 직접적으로 기여한다. 따라서, SOC(315)의 전력 소비는 주로 CPU(318), GPU(321) 및 DDR(323)에서 비롯된다.

예를 들어, 게임 X가 60 FPS에서 1080 픽셀의 해상도로 작동한다고 가정한다. 이 경우, CPU(318) : GPU(321) : DDR(323)의 전력 소비 분배 비율은 각각 58 % : 25 % : 16 % 이다. 동시에, SOC(315) 전력 소비는 전체 컴퓨팅 디바이스(300)의 전력 소비의 50 %를 차지한다. 그래픽 시스템 런타임(410)에 의해 구현되는 본 명세서에 개시된 실시예들은 부가적인 시각 효과들 및 향상들을 프레임(105)에 추가하는 플랫폼을 제공하면서 작업 부하를 줄이고 작업 부하 분배를 변경함으로써 프레임 레이트(본 명세서에서 성능이라고도 함) 및 SOC(315)상의 전력 소비를 개선한다.

도 5는 본 개시내용의 다양한 실시예에 따른 프레임 렌더링 로직(170)으로부터 커맨드들(270)을 캡처하여 커맨드 스트림(115)을 생성하는 방법(500)을 도시하는 다이어그램이다. 화살표(501)는 단일의 원래 스레드(120) 및 스왑 버퍼(swap buffer)(503)에 의해 실행되는 프레임 로직(107)을 도시한다. 화살표(501)로 도시된 프레임 로직(107)은 게임 로직 업데이트(110), 렌더링 로직(113A-D) 및 커맨드들(270A-C)을 포함한다. 스왑 버퍼(503)는 렌더링 로직(113A-D) 및 커맨드들(270A-C)의 실행을 완료하면 프레임(105)의 렌더링을 마무리한 다음 렌더링된 프레임을 GPU(321)로 전송하도록 구성될 수 있다.

도 5에 도시된 바와 같이, 렌더링 로직(113A-D)은 커맨드들(270A-C) 사이에 산발적으로 위치된다. 이것은 렌더링 엔진이 프레임(105)을 한 번에 렌더링하는 데 사용되게 커맨드들(270)을 결정하지 않기 때문일 수 있습니다. 대신에, 렌더링 엔진은 전형적으로 하나 이상의 계산을 수행한 다음(예를 들어, 렌더링 로직(113A-D)을 수행한 다음) 제1 커맨드(270A)를 결정하고, 그리고 나서 다시 하나 이상의 계산을 수행한 다음 제2 커맨드(270B)을 결정하는 것 등을 수행한다. 프레임(105)을 렌더링하기 위해 호출되어야 하는 커맨드들(270A-C)은 순차적으로 결정된다.

화살표(502)는 커맨드들(270A-C)이 프레임 로직(107)으로부터 결정된 후에, 원래 스레드(120)에 의해 실행되었을 커맨드들(270A-C)이 프레임 로직(107)으로부터 제거될 수 있다는 것을 보여준다. 예를 들어, 커맨드들(270A-C)에 대응하는 그래픽 API들은 렌더링 로직(113)으로부터 추출될 수 있다. 실시예에서, 커맨드들(270A-C)은 커맨드들(270A-C)이 커맨드 스트림 스레드(125)에 의해 실행될 수 있도록 커맨드 버퍼(285)에 저장되거나, 캐시될 수 있다.

화살표(504)는 렌더링 로직(113A-D)이 게임 로직 업데이트(110)의 끝에 연결되고 첨부될 수 있다는 것을 보여준다. 게임 로직 업데이트(110) 및 연결된 렌더링 로직(113A-D)은 원래 스레드(120)에 의해 실행될 수 있다.

실시예에서, 커맨드들(270A-C)은 커맨드 버퍼(285)로부터 검색되고 수집되어 커맨드 스트림(115)을 생성할 수 있다. 예를 들어, 커맨드 스트림(115)은 커맨드들(270A-C)에 대응하는 추출된 그래픽 API들을 조합함으로써 생성될 수 있다. 커맨드들(270A-C)이 프레임 로직(107)에 기초하여 결정된 순서는 커맨드 스트림(115)에서 유지된다. 실시예에서, 커맨드들(270)은 커맨드들이 프레임 로직(107)으로부터 캡처된 것과 동일한 순서로 커맨드 스트림(115)에서 정렬되어 렌더링 엔진에 의해 결정된 커맨드들(270)의 시퀀스를 보존한다. 실시예에서, 커맨드 스트림(115) 내의 커맨드들(270)은 본질적으로 커맨드 스트림(115)을 재구성하도록 수정될 수 있으며, 이것은 도 9를 참조하여 아래에서 더 자세히 설명될 것이다. 이것은 렌더링 엔진에 의해 결정된 커맨드들(270)의 순서를 변경할 수 있지만, 다른 커맨드들(270)의 순서는 그러지 않는다면 커맨드 스트림(115) 내의 모든 커맨드들(270)의 실행의 기본적인 효과가 동일하게 유지되도록 변경되지 않은 채 유지될 수 있다.

도 5에 의해 도시된 바와 같이, 커맨드 스트림(115)은 게임 로직 업데이트(110)가 실행된 이후 언젠가 그리고 렌더링 로직(113D)의 완료 이전 언젠가의 시간(515)에서 실행을 시작할 수 있다. 이러한 방식으로, 커맨드 스트림(115)은 렌더링 로직(113A-D)의 일부의 실행과 병렬로 (또는 동시에) 커맨드 스트림 스레드(125)에서 실행을 시작할 수 있다. 또한, 커맨드 스트림(115)의 실행은 게임 로직 업데이트(110) 및 렌더링 로직(113A-D)의 실행과 비동기적이다. 예를 들어, 커맨드 스트림(115)의 실행은 게임 로직 업데이트(110) 및 렌더링 로직(113A-D)의 실행과 분리되고 별도로 실행된다. 일부 경우에, 커맨드 스트림(115)의 커맨드들(270)에 관련하여 게임 로직 업데이트(110) 및 렌더링 로직(113A-D)의 순차적인 순서는 여전히 유지될 수 있다. 게임 및 렌더링 로직(127)을 실행하는 타이밍에 대비하여 커맨드 스트림(115)을 실행하는 타이밍에 관한 더 상세한 사항은 아래에서 도 10 내지 도 14를 참조하여 설명된다.

실시예에서, 프레임 렌더링 로직(170)으로부터 커맨드들(270)을 캡처하여 커맨드 스트림(115)을 생성하는 방법(500)은 그래픽 애플리케이션의 실행 중에 개시될 수 있다. 실시예에서, 사용자는 비디오 게임과 같은 그래픽 애플리케이션의 실행 전에 또는 실행 중에 다중 스레딩(106A 또는 106B)을 가능하게 할 옵션을 제공받을 수 있고, 이에 따라 렌더링 로직(113)으로부터 커맨드들(270)을 추출하고, 커맨드들(270)을 조합하여 커맨드 스트림(115)을 생성하는 방법(500)을 개시할 수 있다.

실시예에서, 특정 그래픽 애플리케이션에 대한 구성 파일이 컴퓨팅 디바이스(200)에 설치될 수 있고, 구성 파일은 그래픽 애플리케이션이 다중 스레딩(106A 또는 106)을 사용하여 실행되는지를 표시할 수 있다. 이러한 방식으로, 특정 그래픽 애플리케이션에 대한 구성 파일은 렌더링 로직(113)으로부터 커맨드들(270)을 추출하고 커맨드들(270)을 조합하여 그래픽 애플리케이션을 렌더링할 커맨드 스트림(115)을 생성하는 방법(500)을 개시할지를 표시한다.

실시예에서, 컴퓨팅 디바이스(200)는 그래픽 애플리케이션의 런타임 동안, 컴퓨팅 디바이스(200)가 단일 스레드 렌더링(103)과 다중 스레드 렌더링(106A 또는 106B) 사이를 자동으로 스위칭하게 구성되도록 검출 로직으로 구성될 수 있다. 예를 들어, 컴퓨팅 디바이스(200)는 특정 유형들의 그래픽 애플리케이션들에 대해 단일 스레드 렌더링(103)을 사용하도록 구성될 수 있고, 컴퓨팅 디바이스(200)는 다른 더 복잡한 유형들의 그래픽 애플리케이션들에 대해 다중 스레드 렌더링(106A 및 106B)을 사용하도록 구성될 수 있다. 실시예에서, 컴퓨팅 디바이스(200)는 단일 그래픽 애플리케이션에 대해 단일 스레드 렌더링(103)과 다중 스레드 렌더링(106A 또는 106B) 사이에서 앞뒤로 스위칭하도록 구성된다. 컴퓨팅 디바이스(200)가 이러한 스위칭을 앞뒤로 수행하도록 구성되는 방법의 예가 아래에서 도 6을 참조하여 설명된다.

도 6은 본 개시내용의 다양한 실시예에 따른 OPEN GL(OPEN GRAPHICS LIBRARY) API를 사용하여 컴퓨팅 디바이스(200 또는 300)에 의해 구현되는 커맨드 스트림 최적화 및 향상의 방법(600)을 도시하는 다이어그램이다. 원래 스레드(120)는 GLCONTEXT(606), 제1 그래픽 데이터(609A), 제1 커맨드(270A), 제1 동기 커맨드(611A), 제2 그래픽 데이터(609B), 제2 커맨드(270B) 및 제2 동기 커맨드(611B)의 계산, 결정 또는 실행을 포함할 수 있다. GLCONTEXT(606)는 프레임(105)을 렌더링하기 위한 다양한 커맨드(270)의 실행에 기초하여, 상태들 또는 데이터를 저장하고 유지하는 OPEN GL을 위한 환경이다. OPEN GL은 OPEN GL 임베디드 시스템(OPEN GL embedded system)(ES)들이 OPEN GL의 임베디드 버전인 데스크톱 플랫폼 상의 그래픽 API를 의미한다. OPEN GL ES는 주로 모바일 컴퓨팅 디바이스들(200)에서 사용된다. 제1 및 제2 그래픽 데이터(609A-B)는 자산들/자원들(344) 및 데이터 및 자원들(421)과 유사한, 프레임(105)의 렌더링과 연관된 임의의 데이터일 수 있다. 제1 및 제2 커맨드들(270A-B)은 2개의 상이한 OPENGL API들에 대한 호출들일 수 있다. 아래에서 더 자세히 설명되는 바와 같이, 제1 및 제2 동기 커맨드들(611A-B)은 동기 커맨드들(611A-B)이 다른 커맨드들(270) 또는 렌더링 로직(113)에 의해 나중에 사용될 필요가 있는 데이터를 출력하기 때문에 비동기적으로 실행될 수 없는 커맨드들(270)을 의미할 수 있다.

실시예에서, 초기화 스레드(603)는 커맨드 스트림 동적 재구성(command stream dynamic reconstruction)(CDSR) 컨텍스트(613)를 초기화할 수 있으며, CDSR 컨텍스트(613)는 다양한 커맨드(270)의 구현에 기초하여 CDSR 컨텍스트(613)가 상태들 또는 데이터를 또한 저장한다는 점에서 GLCONTEXT(606)와 유사할 수 있다. 실시예에서, CDSR 컨텍스트(613)는 전형적으로 ANDROID 플랫폼에서 실행되는 기존의 GL HOOKS 메커니즘을 확장함으로써 구현될 수 있다. CSDR 컨텍스트(613)는 GL HOOKS 테이블과 같은 것에 기초한 약간의 수정이 있는 채로 GLCONTEXT(606)로부터 상속된다.

CSDR 컨텍스트(613)가 생성되면, 프레임(105)을 처리하고 렌더링하기 위한 커맨드 스트림들(115)을 최적화하고 향상하는 프로세스가 시작될 수 있다. 실시예에서, 최적화 모듈(235)은 CSDR 컨텍스트(613)에 로드되고 설치된 다음 커맨드 스트림 스레드(125)에 의해 실행될 수 있다. 최적화 모듈(235)은 커맨드 스트림(115)을 생성하고, 커맨드 스트림(125)을 재구성하고, 커맨드 스트림(115)에 시각적 향상을 추가하고, 커맨드 스트림 스레드(125)에 의해 커맨드 스트림(115)을 실행하도록 구성될 수 있다.

실시예에서, 화살표(617)로 도시된 바와 같이, 커맨드 스트림 스레드(125)가 생성되어야 하는 때를 결정하는 타겟 프로세스가 식별될 수 있다. 일단 커맨드 스트림(115)이 생성되면, 커맨드 스트림 스레드(125)는 커맨드 버퍼(285)에 저장된 커맨드들(270)을 실행하기 시작할 수 있다. 화살표(619)로 도시된 바와 같이, 커맨드들(270)이 실행될 때 커맨드 스트림 스레드(125)가 GLCONTEXT(606)의 상태를 업데이트할 수 있도록 GLCONTEXT(606)가 커맨드 스트림 스레드(125)로 전송될 수 있다.

화살표(621)로 도시된 바와 같이, 커맨드들(270A-B)은 원래 스레드(120)로부터 캡처되고 제거될 수 있으며, 커맨드 버퍼(285)에 순차적으로 캐시되어 커맨드 스트림(115)을 생성할 수 있다. 커맨드 스트림 스레드(125)는 원래 스레드(120) 대신에 커맨드 스트림 스레드(125)에 의한 실행을 위해 커맨드 버퍼(285)로부터의 커맨드들(270)을 페치할 수 있다. 화살표(623)로 도시된 바와 같이, 그래픽 데이터(609A-B)는 또한 원래 스레드(120)로부터 캡처되고 제거되며, 커맨드 스트림 스레드(125)가 필요에 따라 그래픽 데이터(609A-B)를 페치하여 커맨드들(270A-B)을 실행하도록 캐시될 수 있다.

다양한 유형 또는 범주의 커맨드들(270)이 있을 수 있다. 예를 들어, 한 유형의 커맨드(270)는 단순히 GLCONTEXT(606)에 상태를 설정한다. 다른 유형의 커맨드(270)는 텍스처 버텍스들을 DDR(323)로부터 GPU(321)로 이전하는 것과 같은 그래픽 데이터(609A-B)의 이전에 사용된다. 다른 유형의 커맨드(270)는 데이터 또는 상태들의 소비자인 GPU(321)에게 커맨드(270), 데이터 및/또는 상태들을 사용하여 최종 객체들을 프레임(105)에 그리도록 명령하는 그리기 호출(draw call)이다.

이러한 커맨드들(270) 중 일부는 동기적인 커맨드들(270)(본 명세서에서 동기 커맨드들(611A-B)이라고도 함)일 수 있다. 동기 커맨드들(611A-B)은 후속 커맨드들(270) 또는 동기 커맨드(611A-B)의 출력 또는 상태 변경을 사용하는 렌더링 로직(113)을 고려하지 않고 다른 스레드(예를 들어, 커맨드 스트림 스레드(125))로 단순히 이동되지 않을 수 있다. 화살표 (624)로 도시된 바와 같이, 이러한 동기 커맨드들(611A-B)은 커맨드들(270)이 캡처되고 캐시되는 방식과 유사하게 캡처되고 캐시될 수 있다. 그러나, 아래에서 도 11, 도 14 및 도 15를 참조하여 더 자세히 설명되는 바와 같이, 원래 스레드(120)의 실행은 원래 스레드(120)가 실행을 계속하기 전에 동기 커맨드(611A-B)가 페치되고 실행되기를 기다려야 할 수 있다. 이 경우, 화살표(625)로 도시된 바와 같이, 원래 스레드(120)가 실행을 계속하기 전에 동기 커맨드(611A-B)의 실행에 기초하여 상태 또는 데이터가 원래 스레드(120)에서 복원될 수 있다.

CSDR 메커니즘이 턴 오프되어야 한다고 결정될 때, 최종의 업데이트된 GLCONTEXT(606)는 화살표(629)로 도시된 바와 같이 원래 스레드(120)로 다시 전송될 수 있다. 커맨드 스트림 스레드(125)는 화살표(632)로 도시된 바와 같이 커맨드 스트림 스레드(125)를 사용하여 프레임(105)을 렌더링하기 위한 다른 타겟 프로세스가 식별될 때까지 이 시점에서 슬립 상태로 들어가거나 종료될 수 있다. 모든 프로세싱 및 렌더링은 원래 스레드(120)에서 재개될 수 있다.

도 7은 다양한 실시예에 따른 컴퓨팅 디바이스(200 또는 300)에서 커맨드들(270)이 어떻게 호출되는지를 도시하는 테이블(700)이다. 실시예에서, 커맨드 스트림 스레드(125)는 테이블(700)을 사용하여 커맨드들(270)을 호출할 수 있다.

테이블(700)은 커맨드 테이블(705) 및 구현 테이블(710)을 포함한다. 커맨드 테이블(705)은 그래픽 API들(330)에 대한 호출들인 하나 이상의 커맨드(270)의 디폴트 구현들을 저장할 수 있다. 커맨드들은 또한 커맨드들(270)의 메모리 어드레스들(720)과 같은 더 적은 양의 데이터를 저장할 수 있다. 일부 실시예에서, 커맨드 테이블(705)은 커맨드(270)와 연관된 다른 적은 양의 데이터를 저장할 수 있다. 커맨드의 식별자는 테이블(700)의 오프셋에 의해 추론될 수 있다.

실시예에서, 커맨드 테이블(705)은 다양한 그래픽 API(330)에 대한 디폴트 OPEN GL 구현들을 포함할 수 있다. 다중 스레드 렌더링(106A-B)을 가능하게 하는 커맨드들(270)의 CSDR 구현들(730), 여기서 실제 구현들(730)은 커맨드(270)에 대응하는 API를 구현하는 데 사용되는 소프트웨어 코드를 말한다. 구현들(730)은 커맨드(270)의 메모리 어드레스(720)에 따라 저장된다. 커맨드 테이블은 다중 스레드 렌더링(106A-B)을 가능하게 하는 커맨드들(270)의 CSDR 구현들(730)을 포함하는 구현 테이블(710)을 포함하도록 확장될 수 있다. CSDR 구현들(730)은 커맨드(270)에 대응하는 API를 구현하는 데 사용되는 소프트웨어 코드를 의미한다. 구현들(730)은 커맨드(270)의 메모리 어드레스(720)에 따라 저장된다. CSDR 구현들(730)은 원래 설계와의 호환성을 유지하기 위해 수정될 수 있고 또한 최상의 성능을 가진 CSDR 구현들에 적응 가능할 수 있다. 일부 실시예에서, 커맨드 스트림 스레드(125)는 특정 커맨드(270)에 대해 저장된 구현들(730) 중 하나를 선택하도록 구성될 수 있다.

도 7에 도시된 바와 같이, 커맨드 테이블(705)은 4개의 상이한 커맨드(270)에 대한 엔트리들을 포함하고, 여기서 이러한 커맨드들(270) 중 하나는 동기 커맨드(611A)이다. 커맨드(270A)에 대한 엔트리는 커맨드(270A)의 구현(730A)의 메모리 어드레스(720A)를 포함한다. 커맨드(270B)에 대한 엔트리는 커맨드(270B)의 구현(730B)의 메모리 어드레스(720B)를 포함한다. 커맨드(270C)에 대한 엔트리는 커맨드(270C)의 구현(730)의 메모리 어드레스(720C)를 포함한다. 커맨드(270D)에 대한 엔트리는 커맨드(270D)의 구현(730D)의 메모리 어드레스(720D)를 포함한다. 메모리 어드레스(720A-D)는 구현(730)(예를 들어, 특정 커맨드(270)와 연관된 코드 또는 소프트웨어 컴포넌트)이 저장되는 메모리 위치의 엔트리 포인트를 의미할 수 있다. 커맨드 테이블(705)은, 도 5에서 단지 4개의 커맨드(270)에 대한 데이터가 도시되어 있지만, (동기 커맨드들(611)을 비롯한) 임의의 개수의 커맨드들(270)과 연관된 데이터를 가리키는 포인터들을 포함할 수 있다.

대응하는 구현 테이블(710)은 커맨드들(270A-B, D) 및 동기 커맨드(611A)를 비롯한 많은 상이한 커맨드들(270)에 대한 엔트리들을 포함한다. 도 7에 의해 도시된 바와 같이, 구현 테이블(710)은 커맨드들(270) 각각에 대한 구현들(730)을 저장하고, 여기서 구현들(730)은 커맨드(270)의 실행과 연관된 모든 소프트웨어 컴포넌트(예를 들어, 코드, 알고리즘들, 변수들, 객체들, 라이브러리들, 클래스들, 다른 API들 등)를 포함할 수 있다.

실시예에서, 커맨드들(270A-D)에 대응하는 그래픽 API들(330)은 컴퓨팅 디바이스(200)에 의해 재해석될 수 있다. 예를 들어, 커맨드 스트림 스레드(125)는 특정 커맨드(270)에 대해 저장된 구현들(730) 중 하나를 선택하도록 구성될 수 있다. 실시예에서, 그래픽 데이터 및 커맨드 스트림(115) 내의 커맨드들(270A-D) 사이의 데이터 종속성들을 포함하는 커맨드 스트림 정보가 결정될 수 있다. 실시예에서, 커맨드 스트림 정보는 빠른 메모리 기입 동작들에 따라 컴퓨팅 디바이스(200)의 메모리(240)에 저장된 커맨드 버퍼(285)에 편성되고 저장될 수 있다.

실시예에서, 테이블(700)을 사용하는 것은 구현 테이블(710)을 정적 메모리에 저장하는 동안 커맨드 테이블(705)을 임시 캐시에 저장하는 특성 때문에 더 효율적이고 더 적은 자원들을 소비한다. 테이블(700)의 커맨드들(270)은 구현들(730)의 포인터들을 변경함으로써 쉽게 수정될 수 있다. 그러므로 캡처 커맨드들(270)의 다른 방식들에 비해 테이블(700)을 사용하는 오버헤드는 낮다.

예로서, GL HOOKS는 GL HOOKS가 다양한 그래픽 API 구현들을 가리키는 포인터들을 저장한다는 점을 제외하고는 테이블(700)과 유사한 테이블이다. 이러한 방식으로, 테이블(700)은 많은 ANDROID 디바이스에 의해 그래픽 렌더링을 위해 사용되는 GL HOOKS 테이블에 대한 확장으로서 사용될 수 있다. 이것은 GLCONTEXT(또는 스레드) 세분성(granularity) 측면에서 런타임 시 상이한 최적화 구현들과 게임 특정 오버라이드 사이에서 스위칭하는 유연성을 가능하게 하면서 런타임 검사들 및 분기들의 필요성을 피하고 런타임 오버헤드를 최소화(거의 0으로)할 수 있다.

도 8은 다양한 실시예에 따른 (동기 커맨드들(611)을 비롯한) 커맨드들(270)과 연관된 데이터를 저장하는 데 사용되는 커맨드 버퍼(285)의 메모리 레이아웃(800)을 도시하는 다이어그램이다. 메모리 레이아웃(800)은 논리적 및 물리적으로 분리되지만 동일한 컴퓨팅 디바이스(200 또는 300)에 위치할 수 있는 2개의 미리 할당된 메모리 블록(803 및 806)을 보여준다. 메모리 블록(803)은 다양한 커맨드들(270A-C)에 대한 커맨드 핸들들(809A-C), 커맨드들(270A-C)을 실행하는 데 사용되는 하나 이상의 파라미터들(810A-C) 및 메모리 어드레스들(812A-C) 어드레스와 같은 크기가 더 작은 콘텐츠를 저장한다. 메모리 블록(806)은 프레임(105)을 렌더링하기 위해 실행될 커맨드들(270)에 대한 실제 커맨드 그래픽 데이터(815A-C)와 같이 크기가 더 큰 콘텐츠를 저장한다. 인식해야 하는 바와 같이, 메모리 블록(803)은 크기가 작고 프레임(105)을 렌더링하기 위해 결정된 커맨드들(270)과 연관된 다른 콘텐츠를 저장할 수 있다. 유사하게, 메모리 블록(806)은 크기가 더 크고 프레임(105)을 렌더링하기 위해 결정된 커맨드들(270)과 연관된 다른 콘텐츠를 저장할 수 있다.

커맨드 핸들들(809A-C)은 커맨드(270)와 연관된 식별자들 또는 이름들일 수 있으며, 시스템이 32 비트 시스템 또는 64 비트 시스템인지에 따라 각각 32 비트 값 또는 64 비트 값일 수 있다. 파라미터들(810A-C)은 커맨드(270)를 실행하는 데 사용되는 1 내지 6개의 파라미터를 포함할 수 있고 전형적으로 길이가 4 바이트 내지 8 바이트일 수 있다. 메모리 어드레스(812A-C)는 대응하는 커맨드 그래픽 데이터(815A-C)가 메모리 블록(806)에 저장되는 곳의 처음을 가리키는 포인터들일 수 있다.

도 8에 도시된 바와 같이, 메모리 블록(803)은 커맨드(270A)에 대한 커맨드 핸들러(809A), 커맨드(270A)에 대한 하나 이상의 파라미터(810A) 및 (메모리 블록(806)에 저장된) 대응하는 커맨드 그래픽 데이터(815A)에 대한 메모리 어드레스(812A)를 포함한다. 메모리 블록(803)은 또한 커맨드(270B)에 대한 커맨드 핸들러(809B), 커맨드(270B)에 대한 하나 이상의 파라미터(810B), 및 (메모리 블록(806)에 저장된) 대응하는 커맨드 그래픽 데이터(815B)에 대한 메모리 어드레스(812B)를 포함한다. 메모리 블록(803)은 커맨드(270C)에 대한 커맨드 핸들러(809C), 커맨드(270C)에 대한 하나 이상의 파라미터(810C) 및 (메모리 블록(806)에 저장된) 대응하는 커맨드 그래픽 데이터(815C)에 대한 메모리 어드레스(812C)를 더 포함한다.

커맨드들(270)이 프레임 렌더링 로직으로부터 캡처될 때, 커맨드들(270)은 기입 동작(853)을 사용하여 커맨드 버퍼(285)의 메모리 블록들(803 및 806)에 추가될 수 있다. 커맨드 스트림 스레드(125)가 메모리 블록들(803 및 806)로부터 커맨드들(270)을 페치되거나 검색할 때, 커맨드들(270)은 기입 동작(850)을 사용하여 페치되거나 검색될 수 있다.

이러한 메모리 블록들(803 및 806)의 맞춤형 데이터 구조는 동적 메모리 할당 및 관리의 메모리 단편화(memory fragmentation) 및 런타임 오버헤드를 최소화하는 데 도움이 된다. 메모리 블록들(803 및 806)의 사용은 또한 원래 스레드(120) 및 커맨드 스트림 스레드(125) 둘 다에 대한 메모리 액세스 지역성(memory access locality) 및 캐시 최적화를 최대화하는 데 도움이 된다. 일부 경우에, 메모리 블록들(803 및 806)의 사용은 기입들 및 판독들이 캐시 최적화를 최대화하기 위해 순차적으로 수행되는 것을 보장하는 데 도움이 된다. 메모리 블록들(803 및 806)은 프레임들(105) 전체에 걸쳐 재사용되어, 런타임 메모리 관리를 피할 수 있다. 커맨드 스트림 버퍼들(285)에 대한 경합을 피하기 위해 다중 프레임 버퍼 설계가 사용될 수 있다. 커맨드들(270), 파라미터들(810) 및 그래픽 데이터(815)에 대한 버퍼들을 분리하는 것은 또한 커맨드들(270) 및 파라미터들(810)에 대한 버퍼들의 압축성을 보장한다.

도 9는 본 개시내용의 다양한 실시예에 따른 향상되고 재구성된 커맨드 스트림(115)을 생성하는 방법(900)을 도시한다. 방법(900)은 커맨드들(270)을 캡처하고 커맨드 스트림(115A)을 생성하는 것으로 시작하며, 커맨드 스트림은 커맨드들(270)이 프레임 렌더링 스레드(107)로부터 캡처되는 순서대로 커맨드들(270)을 포함한다.

단계(903)에서, 커맨드 스트림(115A) 내의 커맨드들(270)은 커맨드들(270)이 커맨드들(270)을 사용하여 프레임(105)을 렌더링하는 동안 프레임 레이트를 증가시키고 및/또는 소비되는 전력을 감소시킬 목적으로 수정될 수 있는지를 결정하기 위해 분석될 수 있다. 일부 경우에, 커맨드들(270) 사이의 중복성들이 식별될 수 있다. 중복 커맨드들(270)은 커맨드 스트림(270)으로부터 제거될 수 있다.

일부 경우에, 커맨드들(270)에 대한 일부 파라미터(810)는 파라미터들(810)이 불필요하게 프레임 레이트를 감소시키고 그 비디오 게임에 대한 전력 소비를 증가시키는 정도까지 불필요하게 높게 설정된다. 예를 들어, DDR 주파수는 DDR(323)에서 얼마나 많은 데이터 전송이 발생하는지를 의미한다. 전형적으로, DDR 주파수가 높을수록 컴퓨팅 디바이스(200 또는 300)에 의해 소비되는 전력이 더 많다. 데이터는 전형적으로 DDR(323)과 GPU(321) 사이에서 전송되고, 그래서 DDR(323)과 GPU(321) 사이에서는 높은 대역폭의 데이터 전송이 있을 수 있다. 일부 경우에, 프레임(105)을 렌더링하기 위한 커맨드들(270)은 필연적이지 않을 수 있고 DDR 주파수를 증가시킬 (그 때문에 전력 소비를 증가시킬) 매우 높은 해상도를 프레임 버퍼에 명시하는 파라미터(810)를 가질 수 있다. 렌더링되는 프레임(105)의 동일한 품질 또는 실질적으로 동일한 품질을 유지하면서 프레임(105)의 해상도가 감소될 수 있는지에 대해 결정이 이루어질 수 있다. 만일 그렇다면, 특정 커맨드(270)에 대해 프레임(105)의 해상도와 관련된 파라미터(810)가 감소될 수 있다.

실시예에서, 컴퓨팅 디바이스(200 또는 300)는 동일한 품질 또는 실질적으로 동일한 품질의 프레임(105)을 여전히 렌더링하면서 커맨드들(270)에 대한 파라미터들(810)이 조정될 수 있는(예를 들어, 감소될 수 있는) 유사한 패턴들을 결정하도록 구성될 수 있다. 이러한 파라미터들(810)의 변경은 프레임(105)의 렌더링이 DDR(323)과 GPU(321) 사이에서 더 적은 대역폭을 소비하고 컴퓨팅 디바이스(200 또는 300)에서 더 적은 메모리를 사용할 수 있게 할 수 있다.

일부 경우에, 커맨드들(270)은 심지어 커맨드 스트림(115A)에 삽입될 수도 있다. 커맨드 스트림(115A)의 수정은 커맨드들(270)을 삽입하고, 중복 커맨드들(270)을 삭제하고, 커맨드들(270) 중 하나 이상에 대한 파라미터들(810)을 변경함으로써 재구성된 커맨드 스트림(115B)을 생성한다.

단계(906)에서, 커맨드 스트림(115B)을 사용하여 렌더링되는 프레임(105)에 부가적인 향상들 또는 시각 효과들이 적용될 수 있다. 예를 들어, 시각 효과들(예를 들어, 음영, 컬러, 밝기, 이미지의 픽셀들의 텍스처 등)과 관련된 부가적인 커맨드들(270) 또는 API들이 마지막 커맨드(270) 이후에 커맨드 스트림(115)에 추가되거나 삽입될 수 있다. 이러한 부가적인 시각 효과들은 커맨드 스트림 스레드(125)에 의해 프레임(105)에 대해 렌더링될 수 있다. 이러한 시각 효과들을 커맨드 스트림에 추가하면, 향상되고 재구성된 커맨드 스트림(115B)이 생성될 수 있다.

도 10은 본 개시내용의 다양한 실시예에 따른 연기된 커맨드 스트림 실행 모드(1000)를 예시하는 다이어그램이다. 연기된 커맨드 스트림 실행 모드(1000)에서, 원래 스레드(120)는 프레임(105)을 렌더링하는데 사용되어야 하는 커맨드들(270)을 결정할 수 있다. 커맨드들(270)은 (방법(900)을 참조하여 설명된 커맨드 스트림(115B)과 유사할 수 있는) 커맨드 스트림(115)을 생성하는 방법(1000)에 따라 재구성되고 향상될 수 있다. 도 5와 관련하여 앞에서 설명된 바와 같이, 커맨드들(270)은 게임 로직 업데이트(110) 및 하나 이상의 렌더링 로직(113)를 포함할 수 있는, 프레임(105)의 초기 처리 단계 동안 다양한 시간에서 결정될 수 있다.

도 10에 의해 도시된 바와 같이, (게임 로직 업데이트(110) 및 프레임(105A)을 렌더링하는 데 사용되는 모든 렌더링 로직(113)을 포함하는) 게임 및 렌더링 로직(127)은 프레임(105A)을 렌더링하는 데 사용되어야 하는 커맨드들(270)이 캡처되고 커맨드 버퍼(285)에서 캐시되어 커맨드 스트림(115)을 생성하기 이전에 원래 스레드(120)에 의해 완전히 실행될 수 있다. 프레임(105A)에 대해 커맨드 스트림(115)이 생성되고 메모리 블록들(803 및 806)을 사용하여 도 8에 도시된 바와 유사한 방식으로 저장된 후에, 커맨드 스트림 스레드(125)는 커맨드 버퍼(285)(예를 들어, 메모리 블록들(803 및 806))로부터 커맨드들(270)을 검색하여 커맨드들(270)을 실행할 수 있다. 실시예에서, 커맨드들(270)은 테이블(700)을 사용하여 호출될 수 있다.

실시예에서, 연기된 커맨드 스트림 실행 모드(1000)는 2개의 상이한 프레임들(105)이 동시에 처리되고 렌더링될 수 있게 한다. 도 10에 의해 도시된 바와 같이, 커맨드 스트림 스레드(125)가 커맨드 스트림(115)의 커맨드들(270)을 실행하는 동안, 원래 스레드(120)는 다른 프레임(105B)에 대한 (게임 로직 업데이트(110) 및 프레임(105B)을 렌더링하는 데 사용되는 모든 렌더링 로직(113)을 포함하는) 제1 프레임(105)에 대한 게임 및 렌더링 로직(127)을 시작할 수 있다. 일부 경우에, 연기된 커맨드 스트림 실행 모드(1000)는 원래 스레드(120)가 프레임 로직(107)으로부터 커맨드들(270)을 캡처할 때 프레임(105)의 프로세싱 및 렌더링 시에 지연을 야기할 수 있다. 이러한 지연은 일괄처리 커맨드 스트림 실행 모드에서 설명되며, 이것은 도 12를 참조하여 아래에서 더 자세히 설명된다.

도 11은 본 개시내용의 다양한 실시예에 따른 동기 커맨드 스트림 실행 모드(1100)를 도시하는 다이어그램이다. 동기 커맨드 스트림 실행 모드(1100)는 동기 커맨드들(611)이 프레임(105)을 처리하고 렌더링하는 데 사용되는 것으로 선택될 때 사용될 수 있다. 위에서 설명한 바와 같이, 동기 커맨드(611)는 실행될 때, 어떤 상태를 초래하거나 또는 원래 스레드(120)에 의해 나중에 사용되는 데이터를 출력하는 커맨드(270)이다. 동기 커맨드(611)가 커맨드 스트림 스레드(125)에서 실행되는 동안, 원래 스레드(120)는 전형적으로 동기 커맨드(611)의 실행에 기초하여 상태가 복원되기를 기다리거나 또는 데이터가 수신되기를 기다린다.

예를 들어, void glGenTextures(GLsizei n, GLuint * textures)(GL 텍스처 커맨드(GL Textures Command))는, 호출될 때 동기 커맨드(611)로 간주될 수 있는, OPEN GL 임베디드 시스템(ES) 그래픽 API일 수 있다. GL 텍스처 커맨드는 나중에 호출자에 의해 추가 그래픽들을 수행하기 위해 사용되는 한 세트의 텍스처 이름들을 생성하는 API이다. 일부 경우에, 원래 스레드(120)는 커맨드 스트림 스레드(125)가 GL 텍스처 커맨드를 실행한 후에 텍스처 이름들을 수신해야 할 수 있다. 이 경우, 원래 스레드(120)는 원래 스레드(120)의 실행을 계속하기 전에 커맨드 스트림 스레드(125)가 GL 텍스처 커맨드를 완전히 실행하고 커맨드 스트림 스레드(125)로부터 텍스처 이름들을 수신하기를 기다릴 수 있다.

도 11에 도시된 예에서, 커맨드 스트림 부분(115A1)이 커맨드 스트림 부분(115A1)의 끝에 동기 커맨드(611)를 포함하기 때문에 프레임(105)을 렌더링하기 위한 커맨드 스트림(115)은 부분들(115A1 및 115A2)로 분할된다고 가정한다. 유사하게, 게임 및 렌더링 로직(127) 또한 2개의 게임 및 렌더링 로직 부분(127A1 및 127A2)으로 분할될 수 있는데, 왜냐하면 게임 및 렌더링 로직 부분(127A1)의 일부인 일부 렌더링 로직(113)이 동기 커맨드(611)가 상태를 복원하거나 또는 출력을 다시 원래 스레드(120)로 반환하기를 기다릴 수 있기 때문이다. 많은 경우에, 두 부분(127A1 및 127A2)으로 분할되는 로직은 실제로 프레임(105)에 대한 렌더링 로직(113)이다.

도 11에 의해 도시된 바와 같이, 원래 스레드(120)는 렌더링 로직(113)이 동기 커맨드(611)가 실행되기를 기다리기 시작할 때까지 게임 및 렌더링 로직(127)을 계속 실행할 수 있다. 이 시점에서, 커맨드 스트림 스레드(125)는 커맨드 버퍼(285)로부터 하나 이상의 커맨드(270) 및 동기 커맨드(611)를 검색한 다음 커맨드들(270) 및 동기 커맨드(611)를 실행할 수 있다. 동기 커맨드(611)의 실행을 완료한 후에, 커맨드 스트림 스레드(125)는 원래 스레드(120)가 제2 게임 및 렌더링 로직 부분(127A2)의 실행을 진행할 수 있도록 상태 또는 데이터를 원래 스레드(120)로 다시 반환할 수 있다. 도 11에 의해 도시된 바와 같이, 제2 게임 및 렌더링 로직 부분(127A2)이 실행을 완료한 후에, 커맨드 스트림 스레드(125)는 도 10의 연기된 커맨드 스트림 실행 모드(1000)에 대해 위에서 설명된 것과 유사한 방식으로 프레임(105)을 렌더링하는 데 사용되는 커맨드들(270)의 실행을 시작할 수 있다.

원래 스레드(120)는 동기 커맨드들(611)의 실행으로부터 데이터 또는 상태를 기다릴 때 하나 이상의 지연을 겪을 수 있다. 이러한 지연들은 도 13 및 도 14를 참조하여 아래에서 설명되는 바와 같이 다양한 동기 커맨드 핸들링 방법들을 사용하는 것으로 설명될 수 있다.

도 12는 본 개시내용의 다양한 실시예에 따른 일괄처리 커맨드 스트림 실행 모드(1200)를 도시하는 다이어그램이다. 연기된 커맨드 스트림 실행 모드(1000)와 관련하여 위에서 논의된 바와 같이, 연기된 커맨드 스트림 실행 모드(1000)에는 프레임(105)을 렌더링하기 위해 호출되어야 하는 모든 커맨드(270)가 결정되기를 기다리고 커맨드 스트림 스레드(125)가 커맨드 스트림(115)으로부터 커맨드들(270)을 실행하기 시작하기 전에 모든 게임 및 렌더링 로직(127)이 실행되기를 기다리는 것이 수반된다. 그러므로 원래 스레드(120)가 프레임(105)을 렌더링하기 위해 호출되어야 하는 모든 커맨드(270)을 결정하는 때와 커맨드 스트림 스레드(125)가 커맨드 스트림(115)으로부터 커맨드들(270)을 실행하기 시작하는 때 사이에는 지연이 있다.

일괄처리 커맨드 스트림 실행 모드(1200)는 프레임(107)에 대한 게임 및 렌더링 로직(127)의 실행을 완료하기 전에 커맨드 스트림(115) 내의 커맨드들(270)의 실행을 개시함으로써 이러한 지연을 감소시킨다. 실시예에서, 임계치(280)는 컴퓨팅 디바이스(200 또는 300)에 미리 구성될 수 있는데, 여기서 임계치(280)는 커맨드 스트림 스레드(125)가 커맨드 버퍼(285)로부터의 커맨드들(270)의 실행을 시작하기 전에 커맨드 버퍼(285)에 캡처되고 저장될 수 있는 최소 개수의 커맨드(270)를 정의한다. 실시예에서, 커맨드 스트림 스레드(125)는 적어도 임계치(280) 개수의 커맨드들(270)이 프레임 로직(107)으로부터 캡처되고 커맨드 버퍼(285)에 추가된 후에 커맨드 버퍼(285)로부터 커맨드들(270)의 실행을 시작할 수 있다.

도 12에 의해 도시된 바와 같이, 일괄처리 커맨드 스트림 실행 모드(1200)는 연기된 커맨드 스트림 실행 모드(1000)를 구현할 때의 커맨드 스트림 스레드(125)가 커맨드들(270)의 실행을 시작할 때보다 훨씬 더 일찍 커맨드 스트림 스레드(125)가 커맨드들(270)의 실행을 시작할 수 있게 한다. 일부 경우에, 커맨드 스트림 스레드(125)는 게임 및 렌더링 로직(127)이 실행을 완료하기 전에 커맨드 버퍼(285)에 존재하는 프레임(105)에 대한 모든 커맨드(270)를 실행할 수 있다. 이 경우, 커맨드 스트림 스레드(125)는 먼저 커맨드 스트림(115A1)의 제1 부분을 실행한 다음, 커맨드 스트림 스레드(125)가 커맨드 버퍼(285)에 임계치(280) 개수의 커맨드들(270)이 포함되기를 다시 기다리는 슬립 모드로 들어갈 수 있다. 커맨드 버퍼(285)가 적어도 임계치(280) 개수의 커맨드들(270)을 포함하는 것으로 결정된 후에, 커맨드 스트림 스레드(125)는 제2 부분의 커맨드 스트림(115A2)의 일부인 커맨드 버퍼(285)로부터의 커맨드들(270)의 실행을 시작하도록 개시된다.

원래 스레드(120)에서 커맨드들(270)을 결정하는 것과 커맨드 스트림 스레드(125)에서 커맨드들을 실행하는 것 사이에 발생하는 지연을 더 감소시키는 일괄처리 커맨드 스트림 실행 모드(1200)의 다른 변형들이 있을 수 있다. 그러한 한 가지 변형은 적응형 일괄처리 커맨드 스트림 실행 모드일 수 있으며, 이 모드는 임계치(280)가 렌더링되는 프레임들(105)의 유형들 및/또는 프레임(105)에 대해 호출되는 커맨드들(207)의 유형들에 따라 조정될 수 있다는 점을 제외하고는 일괄처리 커맨드 스트림 실행 모드(1200)와 유사하다. 실시예에서, 임계치(280)는 비디오 게임의 이전 프레임(105)을 렌더링하는 데 사용된 커맨드들(270)의 개수에 기초하여 프레임(105)에 대해 초기에 설정될 수 있다. 예를 들어, 비디오 게임의 프레임(105B)에 대한 커맨드 버퍼(285a)에 대한 임계치(280)는 이전 프레임(105B)을 렌더링하는 데 사용된 커맨드들(270)의 개수의 50 %로 설정될 수 있다. 이 실시예에서, 임계치(280)는 이전 프레임들(105)의 렌더링에 사용되는 커맨드들(270)의 개수에 기초하여 조정(예를 들어, 증가 또는 감소)될 수 있다. 일부 실시예에서, 원래 스레드(120)가 프레임(105)을 완료하는 때와 커맨드 스트림 스레드(125)가 커맨드 스트림(115)의 실행을 완료하는 때 사이에는 갭이 있을 수 있다. 이러한 갭은 지연으로 정의된다. 이러한 적응형 일괄처리 커맨드 스트림 실행 모드에서, 임계치(280)는 프레임(105A)에 대해 사용된 커맨드들(270)의 개수의 50 %로서 시작할 수 있다. 렌더링 프레임(105A)의 끝에서, 갭(예를 들어, 5 밀리 초)이 이전 프레임을 렌더링할 때 발생한 갭(예를 들어, 4 밀리 초)으로부터 더 커졌는지를 결정하기 위해 갭이 검사될 수 있다. 갭이 증가되면, 임계치(280)는 예를 들어 40 %로 감소될 수 있다. 갭이 가능한 한 최소화될 때까지 다음 프레임(105B)에 대해 동일한 검사들이 수행될 수 있다. 반대 방향으로, 커맨드 스트림 스레드(125)가 너무 많은 조각으로 분할될 때, 이것은 임계치(280)가 다음 프레임(105C)에서 더 커져야 한다는 표시일 수 있다. 임계치를 동적으로 조정함으로써, 게임 및 렌더링 로직(127)이 실행을 완료하는 시간과 커맨드 스트림(115)이 실행을 완료하는 시간 사이의 갭이 최소화된다.

일괄처리 커맨드 스트림 실행 모드(1200)의 다른 변형은 조밀한 다음 일괄처리 커맨드 스트림 실행 모드(tight following batch command stream execution mode)일 수 있다. 조밀한 다음 일괄처리 커맨드 스트림 실행 모드에서, 임계치(280)는 본질적으로 1에 가깝게 설정되어, 커맨드(270)가 커맨드 버퍼(285)에 추가될 때마다 커맨드 스트림 스레드(125)가 그 커맨드(270)를 실행한다. 실시예에서, 커맨드 스트림 스레드(125)는 커맨드 버퍼(285)를 주기적으로 폴링하여 임의의 커맨드들(270)이 프레임(105)에 대해 실행되기를 기다리고 있는지를 결정한 다음 그 후에 커맨드 버퍼(285) 내의 커맨드들(270)를 실행할 수 있다. 이러한 방식으로, 커맨드 스트림 스레드(125)가 슬립 모드로 들어갈 기회가 상당히 감소되어 커맨드 스트림 스레드(125)가 지속적으로 활성화되도록 한다. 이것은 프레임(105)을 렌더링하는 데 사용되는 것으로 결정된 임의의 커맨드들(270)이 가능한 한 빨리 실행되는 것을 보장할 수 있다.

실시예에서, 컴퓨팅 디바이스(200 또는 300)는 비디오 게임 또는 프레임(105)을 렌더링해야 하는데 가장 잘 어울리는 실행 모드에 기초하여 런타임 시 연기된 커맨드 스트림 실행 모드(1000), 동기 커맨드 스트림 실행 모드(1100), 일괄처리 커맨드 스트림 실행 모드(1200), 적응형 일괄처리 커맨드 스트림 실행 모드 또는 조밀한 다음 커맨드 스트림 실행 모드를 사용할지를 결정할 수 있다. 실시예에서, 컴퓨팅 디바이스(200 또는 300)는 동일한 비디오 게임 내의 상이한 프레임들(105)에 대해 이러한 실행 모드들 사이에서 스위칭하여 비디오 게임에 대한 정확성과 성능 사이에서 최상의 균형을 달성할 수 있다.

실시예에서, 이러한 실행 모드들 중 임의의 실행 모드를 필수적으로 턴 오프하고 커맨드 스트림 스레드(125)의 사용을 디스에이블하기 위해 폴백 메커니즘(fallback mechanism)이 또한 사용될 수 있다. 이 경우, 비디오 게임의 프레임들(105)은 도 1을 참조하여 설명된 단일 스레드 렌더링 메커니즘(103)을 사용하여 렌더링될 수 있다.

도 13은 본 개시내용의 다양한 실시예에 따른 동기 커맨드들(611)을 핸들링하는 일괄처리된 사전 생성 모드(batched pre-generation mode)(1300)의 다이어그램이다. 도 11과 관련하여 위에서 설명한 바와 같이, 동기 커맨드들(611)은 원래 스레드(120)에서 다양한 유형의 로직의 실행을 지연시킴으로써 비디오의 프레임 레이트를 손상시킬 수 있다. 일괄처리된 사전 생성 모드(1300)는 동기 커맨드들(611)을 실행할 때 발생하는 지연을 최소화하기 위해 사용될 수 있는 메커니즘의 예이다.

일괄처리된 사전 생성 모드(1300)는 비디오 게임을 대신하여, 이름들 또는 식별자들과 같은 핸들들을 생성하는 데 사용되는 동기 커맨드들(611)에 적용될 수 있다. 이러한 유형들의 동기 커맨드들의 예들은 glGenBuffers, glGenTextures, glCreateProgram, glCreateShader, glMapBuffer 등과 같은 그래픽 API들(330)을 포함한다. 이들 유형의 커맨드들은 전형적으로 프레임(105)을 렌더링하는 프로세스를 통해 산발적으로 호출된다. 예를 들어, 박스(1301)에 도시된 바와 같이, 동기 커맨드들(611A-B)은 핸들들을 생성하는 데 사용되고 단일 프레임(105)을 렌더링하는 동안 두 번 호출될 수 있다. 동기 커맨드들(611A-B)은 커맨드 스트림 스레드(125)가 동기 커맨드들(611A-B)을 실행하고 생성된 핸들들을 원래 스레드(120)로 다시 반환하기 까지 원래 스레드(120)를 두 번 대기(대기(1303) 및 대기(1306))시키는 결과를 초래할 수 있다. 도 13에 도시된 바와 같이, 동기 커맨드들(611A-B)은 또한 프레임(105)에 대한 게임 및 렌더링 로직(127)의 실행이 3개의 부분(127A-C)으로 분할되게 할 수 있다.

박스(1302)는 동기 커맨드들(611A-B)을 사용하여 프레임(105)에 대한 프레임 렌더링 프로세스에 적용되는 사전 생성 모드(1300)를 도시한다. 박스(1302)에 도시된 바와 같이, 원래 스레드(120)가 동기 커맨드(611)가 호출되어야 한다고 식별할 때에 기초하여 동기 커맨드(611A-B)를 산발적으로 호출하는 대신에, 사전 생성 모드(1300)에는 이러한 동기 커맨드들(611)을 예비적으로 실행하여 핸들들의 대형 풀(large pool)(1309)을 사전 생성하는 것이 수반된다. 핸들들의 풀(1309)은 원래 스레드(120)에 의해 나중에 사용될 수 있다. 핸들들의 풀(1309)은 컴퓨팅 디바이스(200 또는 300)에 의해 저장될 수 있고, 원래 스레드(120)가 동기 커맨드(611A-B)를 호출하기로 결정할 때 원래 스레드(120)가 대신 풀(1309)에 액세스하여 그 시간에 필요한 핸들들을 검색하는 방식으로 원래 스레드(120)에 의해 액세스될 수 있다.

박스(1302)에 도시된 바와 같이, 커맨드 스트림 스레드(125)는 핸들들의 풀(1309)이 생성될 때까지 제1 시점에서 반복적으로 동기 커맨드(611A)를 예비 실행한다. 이어서, 원래 스레드(120)는 원래 스레드(120)가 동기 커맨드(611)에 대한 호출이 이루어져야 한다고 결정할 때까지 게임 및 렌더링 로직(127)을 실행한다. 이 시점에서, 원래 스레드(120)는 핸들들의 풀(1309)로부터 핸들(1307)을 대신 수신할 수 있다. 동일한 방식으로, 원래 스레드(120)는 원래 스레드(120)가 핸들들의 풀(1309)로부터의 핸들을 필요로 하는 다음 시간까지 게임 및 렌더링 로직(127B)을 계속 실행할 수 있다. 핸들(1308)은 핸들들의 풀(1309)로부터 검색될 수 있고 원래 스레드(120)는 실행을 계속할 수 있다. 이어서, 예를 들어, 대형 풀(1309)이 사용되지 않은 핸들들의 최소 임계치 개수보다 낮을 때, 커맨드 스트림 스레드(125)는 이러한 제2 시점에서 동기 커맨드(611B)를 다시 한번 예비적으로 실행하여 핸들들의 풀(1309)을 다시 채울 수 있다.

도 13에서는 핸들들의 생성을 수반하는 동기 커맨드(611A-B)에 적용되는 이와 같은 일괄처리 사전 생성 모드(1300)만을 도시하지만, 일괄처리 사전 생성 모드(1300)는 비디오 게임에 의해 사용되는 식별자들 또는 이름들을 생성하는 임의의 동기 커맨드(611A-B)에 적용될 수 있음을 인식하여야 한다. 또한, 커맨드 스트림(115)은, 이를테면 미리 결정된 스케줄에 기초하여, 임의의 시점에서 임의의 이유로 동기 커맨드들(611A-B)을 선제적으로 실행할 수 있다는 것을 인식하여야 한다.

도 14는 본 개시내용의 다양한 실시예에 따른 동기 커맨드들(611)을 핸들링하는 일괄처리된 사전 캐싱 모드(batched pre-caching mode)(1400)의 다이어그램이다. 일괄처리된 사전 캐싱 모드(1400)는 일괄처리된 사전 캐싱 모드(1400)가 서로 상관되어 빈번히 함께 그룹화되는 동기 커맨드들(611)에 적용된다는 점을 제외하고는 일괄처리된 사전 생성 모드(1300)와 유사하다. 이러한 유형들의 동기 커맨드들(611)의 예들은 셰이더 셋업(shader setup) API들인 glGetProgramiv, glGetProgramBinary, glGetUniformBlockIndex 등과 같은 그래픽 API들(330)을 포함한다. 이러한 유형의 커맨드들(611)은 전형적으로 프레임(105)을 렌더링하는 프로세스의 처음부터 끝까지 산발적으로 호출된다. 동기 커맨드들(611A-B)이 커맨드 스트림 스레드(125)가 동기 커맨드들(611A-B)을 실행하고 생성된 데이터를 원래 스레드(120)로 다시 반환하기 까지 원래 스레드(120)를 두 번 대기(대기(1303) 및 대기(1306))시키는 결과를 초래할 수 있다는 점에서 박스(1401)는 박스(1301)와 유사하다. 그러나, 박스(1401)에서, 동기 커맨드(611A) 및 동기 커맨드(611B)는 상관되고 빈번히 함께 실행되거나 또는 연속적으로 함께 그룹화되는 상이한 동기 커맨드들(611)일 수 있다.

박스(1402)는 동기 커맨드들(611A-B)을 사용하여 프레임(105)에 대한 프레임 렌더링 프로세스에 적용되는 일괄처리된 사전 캐싱 모드(1400)를 보여준다. 일괄처리된 사전 캐싱 모드(1400)를 구현할 때, 전형적으로 대략 동일한 시간에 실행되지만 별도로 실행되는 동기 커맨드들(611A-B)이 대신에 함께 그룹화되고 한 번 실행되어 상관된 모든 동기 커맨드들(611A-B)을 실행하는 결과로 생기는 데이터의 적어도 일부분에 대해 원래 스레드가 단 한번 대기(대기(1303))하도록 해야 한다. 이러한 데이터는 데이터(1406)로서 캐시될 수 있고 필요에 따라 원래 스레드(120)에 의해 나중에 액세스될 수 있다.

박스(1402)로 도시된 바와 같이, 원래 스레드(120)는 데이터(1406)가 검색될 수 있도록 상관된 동기 커맨드들(611A-B) 중 적어도 하나가 실행되어야 한다고 원래 스레드(120)가 결정할 때까지 게임 및 렌더링 로직(127A)의 실행을 계속한다. 이 시점에서, 결정된 동기 커맨드(611A)뿐만 아니라 관련된 다른 모든 동기 커맨드(611A-B)가 실행될 수 있다. 이 시간 동안, 원래 스레드(120)는 동기 커맨드(611)의 실행에 기초하여 데이터가 생성되고 반환되기를 대기(대기(1303))할 수 있다. 모든 동기 커맨드(611A-B)의 실행에 의해 생성된 데이터는 데이터(1406)에 캐시될 수 있다. 원래 스레드(120)는, (1403)에서, 이러한 상관된 동기 커맨드들(611A-B) 중 하나가 데이터가 검색될 수 있도록 실행되어야 한다고 다시 결정될 때까지 게임 및 렌더링 로직(127B)의 실행을 계속할 수 있다. 그러나, 동기 커맨드(611B)를 다시 실행하고 결과를 기다리는 대신, 원래 스레드(120)는 즉시 데이터(1406)에 액세스하여 게임 및 렌더링 로직(127C)의 실행을 계속하는 데 필요한 데이터를 검색할 수 있다.

실시예에서, 동기 커맨드들 사이의 상관은 비디오 게임에 특유할 수 있다. 예를 들어, 커맨드들(270)은 일부 유형의 커맨드들(270)이 함께 발생할(예를 들어, 실행될) 가능성이 높은 패턴들을 따를 수 있다. 이러한 방식으로, 분석이 선제적으로 수행되어 게임이 게임의 프레임들(105)을 렌더링하기 위해 사용할 수 있는 커맨드들(270)을 결정할 수 있다. 함께 상관되는 커맨드들(270)은 일괄처리된 사전 캐싱 모드(1400)와 관련 있는 커맨드들(270)이다. 이 실시예에서, 이러한 상관들은 컴퓨팅 디바이스(200 또는 300)에 의해 식별될 수 있고 동기 커맨드들(611) 사이의 식별된 상관들에 기초하여 이러한 비디오 게임들을 렌더링하 동안 일괄처리된 사전 캐싱 모드(1400)가 적용될 수 있도록 한다.

동기 커맨드들(611)을 실행할 때 발생하는 지연을 최소화하기 위해 다른 메커니즘들이 사용될 수 있다. 예를 들어, 일괄처리된 사전 전역 캐싱 모드(batched pre-global caching mode)가 사용될 수 있는데, 일괄처리된 사전 전역 캐싱 모드는 이 모드가 게임 및 렌더링 로직(127) 또는 커맨드 스트림(115)을 실행하기 전에 캐시 내에 많은 전역 상태들, 변수들 또는 데이터를 선제적으로 캐시한다는 점을 제외하고는, 일괄처리된 사전 생성 모드(1300) 및 일괄처리된 사전 캐싱 모드(1400)와 유사하다. 캐시된 전역 상태들, 변수들 또는 데이터는 전형적으로 동기 커맨드들(611)을 산발적으로 호출함으로써 생성된다. 그러나, 본 명세서에 개시된 일괄처리된 사전 전역 캐싱 모드는 이러한 전역 상태들, 변수들 및 데이터를 캐시에 수집하고 저장하여 동기 커맨드들(611)이 산발적으로 호출될 필요가 없도록 한다.

도 15는 본 명세서에서 개시된 커맨드 스트림 향상 및 최적화 기술들이 비디오 게임의 프레임 레이트 및 비디오 게임의 전력 소비를 어떻게 개선하는지를 도시하는 다이어그램(1500)이다. 전형적으로, 섹션(1501)에 의해 도시된 바와 같이, 컴퓨팅 디바이스(200 또는 300)가 단일 스레드 렌더링(103)을 사용할 때, 컴퓨팅 디바이스(200 또는 300)는 각 프레임(105)의 프로세싱 및 렌더링 후에 15 %의 시간 갭(1503)을 구현한다.

컴퓨팅 디바이스(200 또는 300)가 다중 스레드 렌더링(106)을 사용하여 본 명세서에 개시된 커맨드 스트림 향상 및 최적화 기술들을 구현할 때, 프레임(105)의 렌더링(예를 들어, 게임 및 렌더링 로직(127) 및 커맨드 스트림(115)의 실행)은 더 빠르게 수행된다. 그러므로 각 프레임(105)의 프로세싱 및 렌더링 이후에 15 %의 시간 갭(1503)이 있는 대신, 각 프레임(105)의 프로세싱 및 렌더링 이후에 프레임(105) 사이에는 35 %의 시간 갭(1506)이 존재할 수 있다. 실시예에서, CPU(318)의 DVFS(333)와 같은 주파수 기계는 CPU 주파수를 감소시켜서 프레임들(105) 사이에 15 % 시간 갭(1503)을 구현하는 것으로 되돌아 가도록 구성될 수 있다. CPU 주파수의 이러한 감소는 프레임들을 생성하는 동안 컴퓨팅 디바이스(200 또는 300)에 의해 소비되는 전력의 감소를 추가적으로 가져온다.

커맨드 스트림 향상 및 최적화의 실시예들은 다양한 다른 유형의 상황들에서 사용될 수 있다. 예를 들어, 커맨드 스트림 향상 및 최적화의 실시예들은 중복 커맨드들(270)을 줄이기 위해 사용될 수 있다. 일부 렌더링 엔진들은 GL 상태 캐시들에서 완전히 최적화되지 않으며 많은 중복 GL API 호출들을 가질 수 있다. 내부 전역 GL 상태 캐시(internal global GL state cache)는 중복 커맨드들(270)을 제거하는 데 사용될 수 있으며, 이것은 또한 API 호출 오버헤드를 감소시킨다.

커맨드 스트림 향상 및 최적화의 실시예들은 또한 커맨드 스트림(115) 내부에서 기능성이 동등한 커맨드들(270)을 변환하는 데 사용될 수 있다. 예를 들어, GP API 호출 시퀀스는 커맨드 스트림(115)의 동등한 기능성을 유지하면서 조정될 수 있다. 이것은 상태 스위치들을 줄이고 GPU(321)에서 실행 효율성을 향상시킬 수 있다.

커맨드 스트림 향상 및 최적화의 실시예들은 또한 렌더링 파라미터들(810) 및 메모리 대역폭을 조정하기 위해 사용될 수도 있다. 프레임 버퍼들의 편성, 텍스처 포맷들, 모델의 세부 사항의 수준, 밉맵(mipmap)들 및 텍스처의 필터 모드가 조정될 수 있다. 조정들은 프레임들(105)의 시각적 품질에 미치는 영향들을 평가한 이후에 게임별로 수행될 수 있다. 이러한 조정들은 DDR(323) 대역폭 및 GPU(321) 작업 부하를 감소시킬 수 있고, 이것은 비디오 게임을 실행하는 동안 컴퓨팅 디바이스(200 또는 300)의 성능 및 전력 소비를 개선한다.

도 16은 본 명세서에 개시된 다양한 실시예에 따른 커맨드 스트림 최적화 및 향상의 방법(1600)을 도시하는 흐름도이다. 방법(1600)은 코어들(233, 234 및 237) 각각에서 실행되는 최적화 모듈(235)에 의해 구현될 수 있다. 방법(1600)은 비디오 게임과 같은 그래픽 애플리케이션의 프레임이 렌더링되어야 할 때 구현될 수 있다.

단계(1603)에서, 그래픽 애플리케이션의 프레임(105)을 렌더링하는 데 사용되는 커맨드(270)가 결정될 수 있다. 예를 들어, 컴퓨팅 디바이스(200)의 제1 코어(233)에서 실행되는 원래 스레드(120)는 프레임(105)을 렌더링하는 데 사용되는 커맨드(270)를 결정할 수 있다. 커맨드(270)는 OPEN GL ES API와 같은 그래픽 API(330)에 대한 호출이다.

단계(1606)에서, 커맨드(270)에 기초하여 커맨드 스트림(115)이 생성될 수 있다. 커맨드 스트림(115)은 프레임(105)을 렌더링하는데 사용되는 복수의 커맨드(270)이다. 컴퓨팅 디바이스(200)의 제1 코어(233)에서 실행되는 원래 스레드(120)는 커맨드 스트림(115)을 생성한다.

단계(1609)에서, 커맨드 스트림(115)이 실행되어 그래픽 애플리케이션의 프레임(105)을 렌더링한다. 예를 들어, 제2 코어(234)에서 실행되는 커맨드 스트림 스레드(125)는 커맨드 스트림(115)을 실행하여 프레임(105)을 렌더링한다.

도 17은 본 명세서에 설명된, 예를 들어 방법(1600)과 같은 하나 이상의 방법을 구현하도록 구성된 장치(1700)를 도시한다. 장치(1700)는 결정 수단(1703), 생성 수단(1706) 및 실행 수단(1709)을 포함한다. 결정 수단(1706)은 원래 스레드(120)에 의해, 그래픽 애플리케이션의 프레임(105)을 렌더링하는 데 사용되는 커맨드(270)를 결정하기 위한 수단을 포함하며, 여기서 커맨드(270)는 그래픽 API에 대한 호출이다. 생성 수단(1706)은 원래 스레드(120)에 의해, 커맨드(270)에 기초하여 커맨드 스트림(115)을 생성하기 위한 수단을 포함하며, 여기서 커맨드 스트림(115)은 프레임(105)을 렌더링하는데 사용되는 복수의 커맨드(270)를 포함한다. 실행 수단(1709)은 커맨드 스트림 스레드(125)에 의해, 그래픽 애플리케이션의 프레임(105)을 렌더링하는 커맨드 스트림(115)을 실행하기 위한 수단을 포함한다.

본 개시내용에서 여러 실시예가 제공되었지만, 개시된 시스템들 및 방법들은 본 개시내용의 사상 또는 범위를 벗어나지 않고 많은 다른 특정 형태로 구현될 수 있다는 것을 이해해야 한다. 본 예들은 제한적인 것이 아니라 예시적인 것으로 간주되어야 하며, 의도는 본 명세서에서 제공된 세부 사항들로 제한되지 않는다. 예를 들어, 다양한 요소 또는 컴포넌트가 조합되거나 다른 시스템에 통합될 수 있고, 또는 특정의 특징이 생략되거나 구현되지 않을 수 있다.

또한, 다양한 실시예에서 개별적으로 또는 별도로 설명되고 예시된 기술들, 시스템들, 서브시스템들 및 방법들은 본 개시내용의 범위를 벗어나지 않고 다른 시스템들, 모듈들, 기술들 또는 방법들과 조합되거나 통합될 수 있다. 결합된 것으로 도시되거나 논의된 다른 항목들은 직접 결합될 수 있거나 또는 간접적으로 결합되거나 전기적, 기계적으로 또는 다른 방식으로든 일부 인터페이스, 디바이스 또는 중간 컴포넌트를 통해 통신할 수 있다. 변경들, 대체들 및 변동들의 다른 예들이 관련 기술분야의 통상의 기술자에 의해 확인될 수 있고 본 명세서에 개시된 사상 및 범위를 벗어나지 않고 이루어질 수 있다.

Claims

컴퓨팅 디바이스에 의해 구현되는 방법으로서,
컴퓨팅 디바이스에서 실행되는 원래 스레드(original thread)에 의해, 그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하는 단계 - 상기 커맨드는 그래픽 인터페이스에 대한 호출임 -;
상기 컴퓨팅 디바이스에서 실행되는 상기 원래 스레드에 의해, 상기 커맨드에 기초하여 커맨드 스트림을 구성하는 단계 - 상기 커맨드 스트림은 상기 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -; 및
상기 컴퓨팅 디바이스에서 실행되는 커맨드 스트림 스레드에 의해, 상기 커맨드 스트림을 실행하여 상기 그래픽 애플리케이션의 상기 프레임을 렌더링하는 단계
를 포함하는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항에 있어서,
상기 커맨드 스트림은 상기 원래 스레드에 의해 실행되는 렌더링 로직과 동시에 상기 커맨드 스트림 스레드에 의해 실행되는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 또는 제2항에 있어서,
상기 커맨드 스트림을 구성하는 단계는,
상기 컴퓨팅 디바이스에 의해, 상기 렌더링 로직으로부터 상기 복수의 커맨드를 추출하는 단계; 및
상기 컴퓨팅 디바이스에 의해, 상기 렌더링 로직으로부터 추출된 상기 복수의 커맨드를 조합하는 단계
를 포함하는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제3항 중 어느 한 항에 있어서,
상기 커맨드 스트림 스레드에 의한 상기 커맨드 스트림의 실행은 상기 원래 스레드에 의한 게임 로직 업데이트 및 렌더링 로직의 실행과 인터리빙되는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제4항 중 어느 한 항에 있어서,
상기 컴퓨팅 디바이스에 의해, 상기 커맨드 스트림 내의 상기 복수의 커맨드에 대응하는 복수의 그래픽 인터페이스를 재해석하는 단계 - 상기 복수의 그래픽 인터페이스의 상기 재해석 단계는 애플리케이션별로 컴파일 시간 또는 런타임 중 적어도 하나 동안 맞춤화 가능하고 상호호환 가능함 -;
상기 컴퓨팅 디바이스에 의해, 그래픽 데이터 및 상기 커맨드 스트림 내의 상기 복수의 커맨드 간의 데이터 종속성들을 포함하는 커맨드 스트림 정보를 결정하는 단계; 및
상기 컴퓨팅 디바이스에 의해, 상기 커맨드 스트림 정보를 상기 컴퓨팅 디바이스의 메모리에 저장되는 커맨드 버퍼에 편성하고 저장하는 단계
를 포함하는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제5항 중 어느 한 항에 있어서,
상기 컴퓨팅 디바이스에서 복원 및 실행되는 상기 커맨드 스트림 스레드에 의해, 커맨드 버퍼로부터 상기 커맨드를 페치함으로써 상기 커맨드 스트림으로부터 상기 커맨드를 검색하는 단계를 더 포함하고, 상기 커맨드 버퍼는 적어도 하나의 메모리 블록을 포함하는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제6항 중 어느 한 항에 있어서,
상기 원래 스레드는 상기 컴퓨팅 디바이스의 제1 코어에서 실행되고, 상기 커맨드 스트림 스레드는 상기 컴퓨팅 디바이스의 제2 코어에서 실행되는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제7항 중 어느 한 항에 있어서,
상기 방법은 상기 커맨드 스트림 스레드 또는 상기 원래 스레드에 의해, 상기 커맨드들을 실행하기 전에 상기 커맨드 스트림 내의 상기 커맨드들 중 적어도 하나를 수정하는 단계를 더 포함하는, 컴퓨팅 디바이스에 의해 구현되는 방법.
제1항 내지 제8항 중 어느 한 항에 있어서,
상기 원래 스레드 또는 상기 커맨드 스트림 스레드 중 적어도 하나에 의해, 시각적 향상 커맨드를 상기 커맨드 스트림에 삽입하는 단계를 더 포함하고, 상기 시각적 향상 커맨드는 렌더링되는 상기 프레임에 시각적 효과를 추가하는 것인, 컴퓨팅 디바이스에 의해 구현되는 방법.
컴퓨팅 디바이스로서,
커맨드 버퍼를 포함하는 메모리;
상기 메모리에 결합된 제1 프로세서,
상기 제1 프로세서에서 실행되는 원래 스레드 - 상기 원래 스레드는,
그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하고 - 상기 커맨드는 그래픽 인터페이스에 대한 호출임 -;
상기 커맨드 버퍼에 커맨드 스트림을 저장하도록 구성되고, 상기 커맨드 스트림은 상기 커맨드에 기초하여 구성되고, 상기 커맨드 스트림은 상기 프레임들을 렌더링하는 데 사용되는 복수의 커맨드를 포함함 -; 및
상기 프로세서에서 실행되고 상기 그래픽 애플리케이션의 상기 프레임을 렌더링하기 위해 상기 커맨드 스트림을 실행하도록 구성되는 커맨드 스트림 스레드
를 포함하는, 컴퓨팅 디바이스.
제10항에 있어서,
상기 커맨드는 상기 원래 스레드에 의해 실행되는 렌더링 로직과 동시에 상기 커맨드 스트림 스레드에 의해 실행되고, 상기 원래 스레드는,
상기 커맨드 스트림 스레드가 상기 커맨드 스트림 내의 복수의 커맨드의 실행을 시작하기 전에 상기 커맨드 버퍼에 저장되는 최소 개수의 커맨드들을 정의하는 상기 프레임에 대한 임계치를 결정하고;
상기 커맨드 버퍼에 저장된 상기 커맨드들의 개수가 상기 임계치를 충족할 때 상기 커맨드 스트림 내의 상기 복수의 커맨드를 실행하도록
추가로 구성되는, 컴퓨팅 디바이스.
제10항에 있어서,
상기 커맨드 스트림은 게임 로직 업데이트 및 렌더링 로직의 실행과 인터리빙되는, 컴퓨팅 디바이스.
제11항에 있어서,
상기 프레임에 대한 상기 임계치는 상기 원래 스레드에 대비한 상기 커맨드 스트림 내의 상기 커맨드들의 실행 타이밍 및 상기 그래픽 애플리케이션의 이전 프레임에 대한 상기 커맨드 스트림 내의 커맨드들의 개수에 기초하여 조정되는, 컴퓨팅 디바이스.
제10항 내지 제13항 중 어느 한 항에 있어서,
상기 커맨드 버퍼는 복수의 메모리 블록으로 분할되고, 제1 메모리 블록은 상기 커맨드에 대한 핸들 및 상기 커맨드에 대한 파라미터를 저장하고, 제2 메모리 블록은 상기 커맨드에 의해 상기 프레임을 렌더링하기 위해 사용되는 그래픽 데이터를 저장하는, 컴퓨팅 디바이스.
제10항 내지 제14항 중 어느 한 항에 있어서,
상기 커맨드 버퍼는 상기 커맨드의 메모리 어드레스를 포함하고, 상기 커맨드에 대해 상기 복수의 구현이 저장될 수 있고, 상기 구현들 중 하나는 상기 커맨드 스트림 스레드에 의한 실행을 위해 선택될 수 있는, 컴퓨팅 디바이스.
제10항 내지 제15항 중 어느 한 항에 있어서,
상기 커맨드 스트림은 복수의 커맨드를 포함하고, 상기 원래 스레드는 상기 커맨드들을 실행하기 전에 상기 커맨드의 상기 파라미터들을 변경하거나 중복 커맨드를 제거함으로써 상기 커맨드 스트림 내의 상기 복수의 커맨드 중 하나 이상을 재구성하도록 추가로 구성되는, 컴퓨팅 디바이스.
제10항 내지 제16항 중 어느 한 항에 있어서,
상기 원래 스레드는,
상기 렌더링 로직으로부터 상기 복수의 커맨드를 추출하고,
상기 렌더링 로직으로부터 추출된 상기 복수의 커맨드를 조합함으로써
상기 커맨드 스트림을 구성하도록 구성되는, 컴퓨팅 디바이스.
제10항 내지 제17항 중 어느 한 항에 있어서,
상기 원래 스레드는 사용자 커맨드 또는 구성 파일 중 적어도 하나에 기초하여 상기 커맨드 스트림 스레드를 개시할지를 결정하도록 추가로 구성되는, 컴퓨팅 디바이스.
컴퓨팅 디바이스로서,
상기 컴퓨팅 디바이스에서 실행되는 원래 스레드 - 상기 원래 스레드는,
그래픽 애플리케이션의 프레임을 렌더링하는 데 사용되는 커맨드를 결정하고 - 상기 커맨드는 그래픽 인터페이스에 대한 호출임 -;
상기 커맨드에 기초하여 커맨드 스트림을 구성하도록 구성되고, 상기 커맨드 스트림은 상기 프레임을 렌더링하는데 사용되는 복수의 커맨드를 포함함 -; 및
상기 그래픽 애플리케이션의 상기 프레임을 렌더링하기 위해 상기 커맨드 스트림을 실행하도록 구성되는, 상기 컴퓨팅 디바이스에서 실행되는 커맨드 스트림 스레드
를 포함하는, 컴퓨팅 디바이스.
제19항에 있어서,
상기 원래 스레드는 상기 커맨드 스트림을 선제적으로 수정하여 상기 원래 스레드에 의해 관련 후속 커맨드들을 비동기 방식으로 실행하기 위해 후속적으로 사용되는 핸들들의 대형 풀(large pool)을 생성하도록 추가로 구성되는, 컴퓨팅 디바이스.
제19항 또는 제20항에 있어서,
상기 커맨드 스트림 내의 상기 복수의 커맨드는 서로 상관된 하나 이상의 동기 커맨드를 포함하고, 상기 원래 스레드는 복수의 동기 커맨드를 한 번에 함께 실행하도록 추가로 구성되는, 컴퓨팅 디바이스.
제19항 내지 제21항 중 어느 한 항에 있어서,
상기 원래 스레드는 상기 커맨드를 상기 컴퓨팅 디바이스의 메모리의 커맨드 버퍼에 저장하도록 추가로 구성되는, 컴퓨팅 디바이스.
제19항 내지 제22항 중 어느 한 항에 있어서,
상기 커맨드 버퍼는 상기 커맨드의 메모리 어드레스를 포함하는, 컴퓨팅 디바이스.
제19항 내지 제23항 중 어느 한 항에 있어서,
상기 원래 스레드는,
상기 렌더링 로직으로부터 상기 복수의 커맨드를 추출하고,
상기 렌더링 로직으로부터 추출된 상기 복수의 커맨드를 조합함으로써
상기 커맨드 스트림을 구성하도록 구성되는, 컴퓨팅 디바이스.
제19항 내지 제24항 중 어느 한 항에 있어서,
상기 컴퓨팅 디바이스는 프로세서를 더 포함하고, 상기 프로세서는,
사용자 커맨드, 구성 파일 또는 검출 로직 중 적어도 하나에 기초하여 상기 커맨드 스트림 스레드를 개시하고,
사용자 커맨드, 구성 파일 또는 검출 로직 중 적어도 하나에 기초하여 상기 커맨드 스트림 스레드를 종료하도록
추가로 구성되는, 컴퓨팅 디바이스.
제19항 내지 제25항 중 어느 한 항에 있어서,
상기 복수의 커맨드의 각각은 OPEN GRAPHICS LIBRARY(OPEN GL) API 또는 OPEN GL EMBEDDED SYSTEMS(ES) API 중 적어도 하나에 대한 호출을 포함하는, 컴퓨팅 디바이스.
제19항 내지 제26항 중 어느 한 항에 있어서,
상기 복수의 커맨드의 각각은 상기 컴퓨팅 디바이스의 게임 계층에서 구현된 인터페이스에 대한 호출을 포함하는, 컴퓨팅 디바이스.
제19항 내지 제27항 중 어느 한 항에 있어서,
상기 복수의 커맨드의 각각은 상기 컴퓨팅 디바이스의 게임 엔진 계층에서 구현된 인터페이스에 대한 호출을 포함하는, 컴퓨팅 디바이스.
제19항 내지 제28항 중 어느 한 항에 있어서,
상기 복수의 커맨드의 각각은 상기 컴퓨팅 디바이스의 디바이스 드라이버에서 구현된 인터페이스에 대한 호출을 포함하는, 컴퓨팅 디바이스.