KR20240063163A - 업스케일러 작업을 위한 플랫폼 리소스 선택 - Google Patents

Abstract

플랫폼 리소스들을 이용하여 업스케일러 작업을 복합 처리하는 것은, 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하는 것 - 상기 복수의 플랫폼 리소스들에는 하나 이상의 그래픽 처리 장치(GPU) 및 하나 이상의 가속 처리 장치(APU)가 포함됨 -; 상기 업스케일링 작업의 방식에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 플랫폼 리소스들 중 하나 이상에 동적으로 할당하는 것; 및 상기 작업 부하가 할당된 상기 플랫폼 리소스들에 의해 상기 업스케일링 작업의 상기 작업 부하를 처리하는 것을 포함한다.

Description

업스케일러 작업을 위한 플랫폼 리소스 선택

컴퓨팅 시스템은 대개의 경우에는 명령어들을 검색 및 실행하고 실행된 명령어들의 결과들을 적합한 위치에 저장하거나 전산 결과를 출력할 수 있는 다수의 프로세싱 리소스(예를 들어, 하나 이상의 프로세서)를 포함한다. 처리 리소스(예를 들어, 중앙 처리 장치(CPU) 또는 그래픽 처리 장치(GPU))는, 예를 들어 데이터(예를 들어, 하나 이상의 피연산자)에 대한 논리 연산을 수행함으로써 명령어들을 실행하는 데 사용될 수 있는, 산술 논리 유닛(ALU) 회로부, 부동 소수점 유닛(FPU) 회로부, 및/또는 조합 논리 블록과 같은 다수의 기능 유닛을 포함할 수 있다. 예를 들어, 기능 유닛 회로부는 다수의 논리 연산을 통해 피연산자에 대한 덧셈, 뺄셈, 곱셈, 및/또는 나눗셈과 같은 산술 연산을 수행하는 데 사용될 수 있다.

이러한 컴퓨터 시스템에서 실행되는 애플리케이션에는 특정 작업 부하를 실행하기 위해 특정 처리 리소스를 선택할 수 있는 기회가 제공될 수 있다. 예를 들어, CPU와 하나 이상의 GPU를 포함하는 컴퓨팅 시스템에서, 애플리케이션은 애플리케이션 작업 부하를 실행하기 위해 특정 프로세서를 선택할 수 있다. 애플리케이션은 컴퓨팅 시스템의 운영 체제에 질의하여 컴퓨팅 시스템에 상주하는 처리 리소스를 결정할 수 있다. 한 예에서, 멀티미디어 재생 애플리케이션은 운영 체제에 미디어 재생이 가능한 디바이스 목록을 질의하고, 예를 들어, 비디오 재생 작업 부하를 실행하기 위한 특정 GPU를 선택할 수 있다.

도 1은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 제공하기 위한 예시적인 시스템의 블록선도를 설명한다.
도 2는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(200)의 추가 블록선도를 설명한다.
도 3a는 본 발명의 일부 구현예에 따른 것으로, 클라이언트-서버 할당(alloc)을 위한 예시적인 상위 레벨 시스템의 추가 블록선도를 설명한다.
도 3b는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 서버 모드에서 플랫폼 리소스 라이브러리로 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 3c는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 라이브러리를 이용하여 클라이언트 모드에서 동적 할당 서비스를 제공하기 위한 예시적인 시스템(325)의 추가 블록선도를 설명한다.
도 4는 본 개시의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 제공하기 위해 사용자 모드에서 플랫폼 리소스 라이브러리를 이용하기 위한 예시적인 시스템의 블록선도를 설명한다.
도 5a는 본 개시내용의 일부 구현예에 따른 것으로, 오디오 잡음 저감(ANR)을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 5b는 본 개시내용의 일부 구현예에 따른 것으로, 비디오 사전 프로세싱을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 5c는 본 개시내용의 일부 구현예에 따른 것으로, 비디오 녹화/스트리밍을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 5d는 본 개시내용의 일부 구현예에 따른 것으로, 사후 프로세싱 및 스케일을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 6은 본 개시내용의 일부 구현예에 따른 것으로, 업스케일링 작업의 복합 처리를 위한 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템의 추가 블록선도를 설명한다.
도 7은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 예시적인 방법을 예시하는 흐름도를 설명한다.
도 8은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다.
도 9는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다.
도 10은 본 개시내용의 구현예에 따른 것으로, 런타임 동안 플랫폼 리소스 후보를 업데이트하는 예시적인 방법을 예시하는 흐름도를 설명한다.
도 11은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 이용하여 렌더링된 프레임의 업스케일링 작업을 복합 처리하는 예시적인 방법을 예시하는 흐름도를 설명한다.
도 12는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 이용하여 렌더링된 프레임의 업스케일링 작업을 복합 처리하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다.
도 13은 본 개시내용의 일부 구현예에 따른 것으로, 작업 부하 할당이 다양한 방식으로 수행되는, 업스케일링 작업을 복합 처리하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다.

앞서 지적한 바와 같이, 컴퓨터 시스템에서 실행되는 애플리케이션에는 특정 작업 부하를 실행하기 위해 특정 처리 리소스를 선택할 수 있는 기회가 제공될 수 있다. 일부 시나리오에서는, 애플리케이션이 실행을 위해 작업 부하를 할당할 준비가 되면, 애플리케이션은 먼저 운영 체제에 질의하여 어느 처리 리소스가 이용 가능한지를 결정한다. 예를 들어, 작업 부하가 그래픽(예를 들어, 게임용 그래픽 렌더링) 또는 멀티미디어 작업 부하(예를 들어, 멀티미디어 재생)인 경우, 애플리케이션은 컴퓨팅 장치에 GPU가 존재하는지 여부를 먼저 결정할 수 있다. 일부 컴퓨팅 장치에는 GPU가 두 개 이상 있을 수 있다. 예를 들어, 컴퓨팅 장치는 통합된 CPU 및 GPU를 포함하는 동시에 개별 GPU(즉, 별도의 칩에)도 포함할 수 있다. 또한, 애플리케이션은, 예를 들어 GPU가 지원하는 비디오 코덱이 어떤 것인지를 결정하여, 작업 부하를 배치할 곳을 결정할 수 있다. 예를 들어, 스트리밍 미디어 서비스 플레이어는 소스 해상도, 비트 전송률, 코덱, 디스플레이 해상도, 프레임 속도 등의 측면에서 특정 작업 부하(예를 들어, 영화)를 설명할 수 있고, 작업 부하를 실행할 수 있는 프로세서 리소스에 대해 운영 체제에 질의할 수 있다. 운영 체제는 작업 부하를 실행할 수 있는 능력을 갖는 GPU를 식별함으로써 응답할 수 있다. 애플리케이션은 운영 체제의 응답에 기반하여 GPU를 선택하고 해당 GPU에 작업 부하를 할당할 수 있다. 예를 들어, 통합 GPU는 일반적으로 개별 GPU보다 적은 전력을 소비하므로 애플리케이션은 작업 부하를 통합 GPU에 할당할 수 있다. 이는 컴퓨팅 장치가 배터리 전원으로 작동할 때 특히 중요할 수 있다.

그러나 운영 체제가 컴퓨팅 장치의 능력에 대한 정보를 제공할 때에는 시스템의 런타임 동작에 대한 통찰력 없이 그렇게 한다. 즉, 운영 체제는 통합 GPU의 비디오 코덱이 얼마나 바쁜지 알 수 없다. 애플리케이션이 화상 회의 애플리케이션과 같은 다른 비디오 작업 부하도 실행할 수 있는 통합 GPU에 작업 부하를 배치하기로 결정한 경우, 통합 GPU의 비디오 코덱이 초과 구독될 수 있다. 즉, 애플리케이션과 운영 체제에는 프로세서 리소스의 실제 런타임 활용에 대한 가시성이 없으므로 컴퓨팅 장치가 작업 부하에 대해 예상되는 사용자 경험을 전할 수 있는지를 알 수 없다.

또한, 운영 체제는 실제 플랫폼 리소스(예를 들어, 하드웨어) 능력 및 제한 사항을 완전히 이해하지 못한다. 실제로, 일부 플랫폼 리소스 능력은 운영 체제가 밝혀낼 수 없다. 따라서, 애플리케이션을 처리하는 데 가장 적합하거나 최적인 리소스가 아닌 플랫폼 리소스에 애플리케이션이 할당될 수 있다.

또한, 이미지 프레임을 정의하는 데이터는 일반적으로 프레젠테이션을 위해 다양한 크기로 스케일링된다. 즉, 이미지 스케일링은 디지털 이미지의 재스케일링을 지칭한다. 업스케일링 또는 "해상도 향상"은 저해상도 입력으로부터 고해상도 이미지를 생성하는 프로세스이다. 업스케일링은 더 높은 해상도의 디스플레이에 이미지를 표시한다. 예를 들어, 비디오 스트림으로부터의 사진이나 프레임(예를 들어, 이미지)은 낮은 해상도에서 높은 해상도로 업스케일링된다. 그런 다음 그 업스케일링된 이미지가 디스플레이에 표시되어 그 이미지가 전체 디스플레이를 채우게 될 수 있다. 업스케일링과 관련된 과제들 중 하나는 사용자 기본설정과 함께 플랫폼 리소스 능력, 가용성, 및 제한 사항을 고려하지 않고 플랫폼 리소스를 포괄적이고 철저하게 이용하는 것이다. 또한, 업스케일링 작업의 방식은 처리 효율성과 전력 소비에 부정적인 영향을 미칠 수 있다.

따라서, 본 개시내용에 따른 구현예는, 애플리케이션 또는 기타 작업 부하 개시자가 성능 능력 및 활용도 지표에 기반하여 작업 부하를 실행하기 위해 복수의 플랫폼 리소스들 중 하나 이상을 선택하기 위해 플랫폼 리소스 추천을 수신할 수 있는, 플랫폼 리소스 추천 서비스를 위한 메커니즘을 제공한다.

한 구현예는 플랫폼 리소스를 추천하는 방법에 관한 것이다. 상기 방법은 작업 부하 개시자로부터 플랫폼 리소스 후보에 대한 요청을 수신하는 단계를 포함한다. 상기 방법은 또한 복수의 플랫폼 리소스의 요청과 성능 능력과 활용도 지표에 기반하여 하나 이상의 플랫폼 리소스 후보를 식별하는 단계를 포함하며, 여기서 복수의 플랫폼 리소스에는 하나 이상의 GPU 및 하나 이상의 가속 처리 장치(APU)가 포함된다. APU는 광의의 표현으로 간주된다는 점을 유의해야 한다. 예를 들어, APU는 기존 CPU, 기존 GPU, 소프트웨어, 및/또는 이들의 조합에 비해 가속화된 방식으로 그래픽 처리 작업, 데이터 병렬 작업, 또는 중첩 데이터 병렬 작업을 가속화하는 것과 연관된 기능 및 계산을 수행하는 하드웨어 및/또는 소프트웨어의 임의의 협력 컬렉션을 지칭한다. 예를 들어, APU는 CPU와 GPU 둘 다로 기능할 수 있는 처리 장치(예를 들어, 처리 칩/디바이스)이다. 또한, APU는 범용 CPU 외부에서 하나 이상의 계산 유형을 가속화하는 데 사용되는 추가 처리 기능을 포함하는 칩이다. 한 구현예에서, APU는 GPU, FPGA, 기계 학습 프로세서, 디지털 신호 프로세서(DSP), 및 오디오/사운드 프로세서와 동일한 다이에 통합된 범용 CPU, 또는 기타 처리 장치를 포함할 수 있고, 따라서 전력 소비를 줄이면서 이러한 장치들 간의 데이터 전송 속도를 향상시킨다. 일부 구현예에서, APU는 비디오 처리 및 기타 애플리케이션별 가속기들을 포함할 수 있다.

GPU는 컴퓨터, 워크스테이션, 게임 콘솔, 및 유사한 디지털 처리 장치를 위한 그래픽 및 비디오 렌더링 디바이스이다. GPU는 일반적으로 컴퓨터 CPU에 대한 코프로세서 컴포넌트로 구현되고, 애드인 카드(예를 들어, 비디오 카드), 코프로세서의 형태로 제공되거나 컴퓨터 마더보드나 기타 디바이스에 직접 통합되는 기능으로 제공될 수 있다. GPU는 개별 GPU일 수 있다.

상기 방법은 또한 식별된 하나 이상의 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하는 단계를 포함한다. 이 명세서에 사용된 '동적' 또는 '동적으로'라는 용어는 동작이 정적으로 실행되는 것이 아닌 비동기식, 주문형 방식으로 실행되는 것을 나타내는 데 사용된다. 이 예에서, '제공'은 시스템 운영 중을 포함해 언제든지 플랫폼 리소스 후보를 식별하여 작업 부하 개시자에게 제공할 수 있다는 점에서 동적으로 실행된다고 말한다. 이러한 방식으로, 리소스 후보를 현재 활용도에 대한 지식 없이 정적으로 식별하는 것이 아니라 실시간 현재 활용도 및 시스템 구성에 기반하여 식별할 수 있다.

일부 구현예에서, 상기 방법은 또한 식별된 하나 이상의 플랫폼 리소스 후보를 복수의 플랫폼 리소스의 비성능 능력 및 성능 제한에 기반하여 동적으로 제공하는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 플랫폼 리소스 라이브러리 내의 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 수집하는 단계를 포함한다.

일부 구현예에서, 상기 방법은 또한 작업 부하 개시자로부터의 플랫폼 리소스 추천에 대한 요청에 기반하여 복수의 플랫폼 리소스 각각에 대한 검색 불가능한 성능 능력, 성능 제한, 및 이력 성능 데이터를 결정하기 위해 플랫폼 리소스 라이브러리에서 찾는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 작업 부하의 시작 또는 런타임 동안 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 모니터링하는 단계를 포함한다.

일부 구현예에서, 상기 방법은 또한 작업 부하의 런타임 동안, 업데이트된 플랫폼 리소스 후보를, 복수의 플랫폼 리소스의 조정된 성능 능력 및 조정된 활용도 지표에 기반하여 동적으로 제공하는 단계를 포함한다.

일부 구현예에서, 상기 방법은 또한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 각각의 순위를 매기는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 중 하나 이상 각각에 대해 작업 부하를 실행하기 위한 활용도 영향을 예측하는 단계를 포함한다. 성능 능력은 복수의 플랫폼 리소스의 작업 모드, 복수의 플랫폼 리소스들 간의 상호 연결 능력, 복수의 플랫폼 리소스의 전력 능력; 및 주변 장치 능력을 포함할 수 있다. 또한, 복수의 프로세서 리소스는 로컬 메모리, 시스템 메모리, 하나 이상의 주변 장치, 디스플레이 제어기, 버스 인터페이스 제어기, 메모리 서브시스템 제어기를 포함할 수 있다. 또한, GPU는 개별 GPU일 수 있다.

다른 구현예는 플랫폼 리소스 후보를 제공하는 장치에 관한 것이다. 상기 장치는 컴퓨터 프로세서, 컴퓨터 프로세서에 동작 가능하게 결합된 컴퓨터 메모리를 포함하고, 컴퓨터 메모리는, 컴퓨터 프로세서에 의해 실행될 때 상기 장치로 하여금 작업 부하 개시자로부터 플랫폼 리소스 추천에 대한 요청을 하게 하는, 컴퓨터 프로그램 명령어들을 내장한다. 요청은 작업 부하 개시자로부터의 작업 부하에 대한 설명을 포함할 수 있다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 복수의 플랫폼 리소스의 성능 능력 및 활용도 지표를 분석하게 하며, 복수의 플랫폼 리소스는 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 식별된 하나 이상의 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하게 한다. 일 양태에서, 작업 부하 개시자는 한 세트의 프로파일링된 작업 부하들을 제공하고, 플랫폼 리소스의 능력 또는 사용자 설정에 맞는/일치하는 작업 부하 유형을 선택한다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 작업 부하 개시자로부터의 플랫폼 리소스 추천에 대한 요청에 기반하여 복수의 플랫폼 리소스 각각에 대한 검색 불가능한 성능 능력, 성능 제한, 및 이력 성능 데이터를 결정하기 위해 플랫폼 리소스 라이브러리에서 찾게 한다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 작업 부하의 시작 또는 런타임 동안 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 모니터링하게 한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금, 작업 부하의 런타임 동안, 업데이트된 플랫폼 리소스 후보를 복수의 플랫폼 리소스의 조정된 성능 능력 및 조정된 활용도 지표에 기반하여 동적으로 제공하게 한다.

컴퓨터 프로그램 명령어는 또한 장치로 하여금 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 각각의 순위를 매기게 한다. 컴퓨터 프로그램 명령어는 또한 장치로 하여금 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 중 하나 이상 각각에 대해 작업 부하를 실행하기 위한 활용도 영향을 예측하게 한다.

또 다른 구현예는 플랫폼 리소스 후보를 제공하는 컴퓨터 프로그램 제품에 관한 것이다. 컴퓨터 프로그램 제품은 컴퓨터 판독 가능 매체에 배치되며, 실행될 때 컴퓨터로 하여금 작업 부하 개시자로부터 플랫폼 리소스 추천에 대한 요청을 수신하게 하는 컴퓨터 프로그램 명령어들을 포함한다. 요청은 작업 부하 개시자로부터의 작업 부하에 대한 설명을 포함할 수 있다. 즉, 설명은 한 세트의 프로파일링된 작업 부하들을 포함할 수 있고, 작업 부하 개시자가 플랫폼 리소스의 능력 및 사용자 설정에 맞는/일치하는 작업 부하 유형을 선택할 수 있게 하기 위한 것이다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 복수의 플랫폼 리소스의 성능 능력 및 활용도 지표를 분석하게 하며, 복수의 플랫폼 리소스는 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 식별된 하나 이상의 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하게 한다.

한 구현예는 플랫폼 리소스들을 이용하여 복합 처리하는 방법에 관한 것이다. 상기 방법은 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스를 식별하는 단계를 포함하며, 복수의 플랫폼 리소스는 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 상기 방법은 또한 적어도 업스케일링 작업의 방식에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계를 포함한다. 상기 방법은 또한 작업 부하를 동적으로 할당하는 것에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 의해 업스케일링 작업의 작업 부하를 처리하는 단계를 포함한다.

일부 구현예에서, 상기 방법은 또한 사용자 기본설정에 기반하여 업스케일링 작업의 방식을 선택하는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 방식을 선택하는 단계를 포함한다.

일부 구현예에서, 상기 방법은 또한 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 사용자 기본설정에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 업스케일링 작업의 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스의 제1 플랫폼 리소스와 제2 플랫폼 리소스 사이에 동적으로 할당하는 단계를 포함한다. 일부 구현예에서, 상기 방법은 또한 업스케일링 작업의 방식, 사용자 기본설정, 및 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하는 단계를 포함한다.

또 다른 구현예는 플랫폼 리소스들을 이용하여 복합 처리하는 장치에 관한 것이다. 상기 장치는 컴퓨터 프로세서, 컴퓨터 프로세서에 동작 가능하게 결합된 컴퓨터 메모리를 포함하고, 컴퓨터 메모리는 그 안에 컴퓨터 프로그램 명령어들이 내장되고, 컴퓨터 프로그램 명령어들은 컴퓨터 프로세서에 의해 실행될 때 장치로 하여금 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하게 하고, 복수의 플랫폼 리소스는 하나 이상의 그래픽 처리 장치(GPU) 및 하나 이상의 가속 처리 장치(APU)를 포함한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 적어도 업스케일링 작업의 방식에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 작업 부하를 동적으로 할당하는 것에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 의해 업스케일링 작업의 작업 부하를 처리하게 한다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 사용자 기본설정에 기반하여 업스케일링 작업의 방식을 선택하게 한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 방식을 선택하게 한다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 사용자 기본설정에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 장치로 하여금 업스케일링 작업의 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스의 제1 플랫폼 리소스와 제2 플랫폼 리소스 사이에 동적으로 할당하게 한다.

컴퓨터 프로그램 명령어들은 또한 장치로 하여금 업스케일링 작업의 방식, 사용자 기본설정, 및 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하게 한다.

또 다른 구현예는 플랫폼 리소스들을 이용하여 복합 처리를 위한 컴퓨터 프로그램 제품에 관한 것이다. 컴퓨터 프로그램 제품은 컴퓨터 판독 가능 매체에 배치되고 컴퓨터 프로그램 명령어들을 포함하고, 컴퓨터 프로그램 명령어들은 실행될 때 컴퓨터로 하여금 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하게 하고, 복수의 플랫폼 리소스들은 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 적어도 업스케일링 작업의 방식에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 작업 부하를 동적으로 할당하는 것에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 의해 업스케일링 작업의 작업 부하를 처리하게 한다.

컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 사용자 기본설정에 기반하여 업스케일링 작업의 방식을 선택하게 한다. 컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 방식을 선택하게 한다.

컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 사용자 기본설정에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스 중 하나 이상에 동적으로 할당하게 한다. 컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 업스케일링 작업의 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 업스케일링 작업의 작업 부하를 복수의 플랫폼 리소스의 제1 플랫폼 리소스와 제2 플랫폼 리소스 사이에 동적으로 할당하게 한다.

컴퓨터 프로그램 명령어들은 또한 컴퓨터로 하여금 업스케일링 작업의 방식, 사용자 기본설정, 및 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하게 한다.

본 개시내용에 따른 구현예들이 도 1을 시작으로 하여 더 상세히 설명될 것이다. 본 명세서 및 도면 전체에 걸쳐 같은 도면 부호는 같은 요소를 지칭한다. 도 1은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스(예를 들어, 동적 할당 서비스)를 제공하는 예시적인 시스템(100)의 블록선도를 설명한다. 도 1의 예시적인 시스템(100)은 랩톱 또는 데스크톱 개인용 컴퓨터와 같은 컴퓨팅 장치, 서버, 스마트폰 또는 태블릿과 같은 모바일 기기, 게임 콘솔 등에서 구현될 수 있다. 예시적인 시스템(100)은 2개의 GPU(104, 134)를 포함하지만, 당업자라면 본 개시내용의 정신에서 벗어남이 없이 다른 시스템이 더 많은 GPU를 포함할 수 있거나 다른 유형의 가속 처리 장치를 사용할 수 있다는 것을 이해할 수 있을 것이다.

도 1의 예에서, 예시적인 시스템(100)은 CPU(106)와 GPU(104)(본원에서는 "통합 GPU"로 지칭됨)를 통합한 APU(102)를 포함한다. CPU(106)와 통합 GPU(104)는 동일한 칩에 구현될 수 있고, 따라서 다수의 컴포넌트 및 인터페이스, 예컨대 시스템 메모리(160), 메모리 컨트롤러(114), 및 시스템 메모리(160)에 액세스하기 위한 직접 메모리 어드레싱(DMA) 엔진(118)과 같은 인터페이스; 개인 컴퓨팅 인터페이스 익스프레스(PCIe) 인터페이스(116)와 같은 버스 인터페이스; 및 네트워크 인터페이스, 범용 직렬 버스(USB) 인터페이스, 하드 디스크 드라이브(HDD), 및 솔리드스테이트 드라이브(SSD) 인터페이스와 같은 영구 저장 인터페이스와 같은 도 1에 도시되지 않은 기타 인터페이스 및 어댑터 등을 공유할 수 있다. CPU(106)는 하나 이상의 코어(108)(즉, 실행 엔진), 캐시 구조체(도시되지 않음), 파이프라인 컴포넌트(이 또한 도시되지 않음) 등을 포함한다. CPU(106) 및 다른 공유 컴포넌트는 고속 온-칩 통신 패브릭(도시되지 않음)을 통해 GPU(104)에 연결된다.

도 1의 예시적인 시스템(100)에서, 통합 GPU(104)는 많은 병렬 처리 유닛(도시되지 않음)을 갖는 다수의 단일 명령 다중 데이터(SIMD) 처리 코어(112)를 포함하는 GPU 계산 엔진(110)을 포함한다. GPU 계산 엔진(110)은 또한 기하학적 구조 프로세서, 래스터라이저, 그래픽 커맨드 프로세서, 하드웨어 스케줄러, 비동기식 계산 엔진, 캐시, 데이터 공유 등과 같은 도 1에 도시되지 않은 다른 컴포넌트를 포함한다. 도 1의 예에서, 통합 GPU(104)는 또한, 예컨대 가속 비디오 인코딩 및 디코딩을 위한 비디오 인코더/디코더(120)(즉 "코덱"), 가속 오디오 인코딩 및 디코딩을 위한 오디오 코덱(122), 가속 디스플레이 프로세싱을 위한 디스플레이 제어기(124), 및 가속 보안 프로토콜 시행 및 컴플라이언스를 위한 보안 프로세서(126)와 같은, 애플리케이션 특정 집적 회로 또는 기능적 논리 블록의 형태의 하드웨어 가속기를 포함한다.

도 1의 예에서, APU(102)는 PCIe 상호 연결(190)과 같은 상호 연결을 통해 개별 GPU(134)(dGPU)와 통신한다. APU(102)의 PCIe 인터페이스(116)와 dGPU(134)의 PCIe 인터페이스(146)는 PCIe 상호 연결(190)을 통해 통신한다. 일부 예에서, APU(102) 및 dGPU(134)는 동일한 기판(예를 들어, 인쇄 회로 기판)에 구현될 수 있다. 다른 예에서, dGPU(134)는 APU(102)의 기판과는 별개인 비디오 또는 그래픽 카드에 구현된다.

통합 GPU(104)와 마찬가지로, 도 1의 예의 dGPU(134)는 많은 병렬 처리 장치(도시되지 않음)를 갖는 다수의 SIMD 처리 코어(142)를 포함하는 GPU 실행 엔진(140)(예를 들어, "GPU 계산 엔진)을 포함한다. GPU 계산 엔진(140)은 또한 기하학적 구조 프로세서, 래스터라이저, 그래픽 커맨드 프로세서, 하드웨어 스케줄러, 비동기식 계산 엔진, 캐시, 데이터 공유 등과 같은 도 1에 도시되지 않은 다른 컴포넌트를 포함한다. 도 1의 예에서, dGPU(134)는 또한, 예컨대 가속 비디오 인코딩 및 디코딩을 위한 비디오 인코더/디코더(150)(즉 "코덱"), 가속 오디오 인코딩 및 디코딩을 위한 오디오 코덱(152), 가속 디스플레이 프로세싱을 위한 디스플레이 제어기(154), 및 가속 보안 프로토콜 시행 및 컴플라이언스를 위한 보안 프로세서(156)와 같은, 애플리케이션 특정 집적 회로 또는 기능적 논리 블록의 형태의 하드웨어 가속기를 포함한다. dGPU(134)는 또한 그래픽 메모리(180)(예를 들어, 로컬 메모리)에 액세스하기 위한 메모리 컨트롤러(144) 및 DMA 엔진(148)을 포함한다. 일부 예에서, 메모리 제어기(144) 및 DMA 엔진(148)은 시스템 메모리(160)의 공유 부분에 액세스하도록 구성된다.

도 1의 예시적인 시스템(100)에서, 시스템 메모리(160)(예를 들어, 동적 랜덤 액세스 메모리(DRAM))는 전술한 프로세서 리소스(즉, APU 및 개별 GPU 및 이들의 구성 컴포넌트)에 대한 장치 드라이버(166)와 인터페이스하는 운영 체제(164)를 호스팅한다. 시스템 메모리(160)는 또한 하나 이상의 애플리케이션(162)을 호스팅한다. 본 개시내용과 관련하여, 하나 이상의 애플리케이션은 그래픽 애플리케이션, 멀티미디어 애플리케이션, 비디오 편집 애플리케이션, 화상 회의 애플리케이션, 고성능 컴퓨팅 애플리케이션, 기계 학습 애플리케이션, 또는 통합 GPU(104) 및 dGPU(134)의 병렬 특성 및/또는 그래픽 및 비디오 기능을 활용하는 기타 애플리케이션일 수 있다. 하나 이상의 애플리케이션(162)은 운영 체제(164)로의 호출에 의해 통합 GPU(104) 또는 개별 GPU(또는 이 둘의 조합)에 할당되는 작업 부하(예를 들어, 그래픽 렌더링 작업 부하, 오디오/비디오 전환 작업 부하, 미디어 재생 작업 부하, 기계 학습 작업 부하 등)를 생성한다. 당업자는 하나 이상의 애플리케이션이 다양한 작업 부하 유형을 생성하는 다양한 추가 애플리케이션 유형일 수 있다는 것을 이해할 것이며, 여기서는 이들 모두가 식별되지 않는다는 것을 이해할 것이다. 그러나, 본 개시내용 내에서의 애플리케이션 유형 및 작업 부하 유형에 대한 특정 언급이 애플리케이션 유형 및 작업 부하 유형을 여기서 식별된 것으로 제한하는 것으로 해석되어서는 안 된다.

시스템 메모리(160)는 또한 리소스 관리자(170)를 호스팅하며, 리소스 관리자는 애플리케이션(162)과 같은 작업 부하 개시자로부터의 작업 부하에 대한 설명을 포함하는 요청을 수신하고, 하나 이상의 GPU 및 하나 이상의 APU를 포함하는 복수의 플랫폼 리소스에 대한 성능 능력과 활용도 지표(utilization metric)를 분석하고, 성능 능력 및 활용도 지표에 기반하여 작업 부하를 실행하게끔 복수의 플랫폼 리소스들 중 하나 이상을 선택하도록 예를 들어 애플리케이션(162)과 같은 작업 부하 개시자에게 플랫폼 리소스 추천을 동적으로 제공한다. 일부 예에서, 리소스 관리자(170)는, 유형의 컴퓨터 판독 가능 매체에 저장되며 프로세서에 의해 실행될 때 시스템(100)으로 하여금 전술한 단계들뿐만 아니라 아래에 설명되는 리소스 관리자에 의해 수행되는 다른 단계들 및 작업들을 수행하게 하는, 컴퓨터 실행 가능 명령어로 구현된다.

리소스 관리자는 애플리케이션이 작업 부하를 특정 GPU에 할당하기 전에 애플리케이션(162)이 리소스 관리자(170)로부터 플랫폼 리소스 추천을 요청할 수 있게 하는 API(172)를 포함할 수 있다. 이러한 맥락에서, 작업 부하 할당 추천은 작업 부하를 어디에(즉, 어느 GPU에) 배치해야 하는지(즉, 작업 부하 실행을 위해 어디에 배치해야 하는지)에 대한 추천이다. 플랫폼 리소스 추천은 시스템(100)에서의 다양한 플랫폼 리소스의 성능 능력 및 활용도 지표에 기반하며, 시스템(100)에서의 플랫폼 리소스 추천 각각에 대한 검색 불가능한 성능 능력 및 성능 제한에 기반할 수도 있다.

일부 예에서, 리소스 관리자(170)는 시스템(100)에서의 플랫폼 리소스의 런타임 성능 능력 및 활용도 지표의 현재 값에 기반하여 시스템(100)에서의 플랫폼 리소스에 대한 작업 부하의 최적 플랫폼 리소스 추천을 결정하는 것과 관련된 하나 이상의 정책(176)을 해석하는 정책 엔진(174)을 포함한다. 그런 다음 플랫폼 리소스 추천은 애플리케이션(162)으로 반환되고, 그러면 애플리케이션(162)은 그것을 이용하여 작업 부하를 배치할 장소를 결정할 수 있다. 다양한 구현예에서, 리소스 관리자(170)는 드라이버(166)와 통신하여 활용도 지표의 값을 얻거나, 다른 메커니즘에 의해 활용도 지표의 값을 얻는다. 이러한 예에서, 드라이버(166)는 특정 프로세서 리소스에 대한 활용도 모니터와, 리소스 관리자에 활용도 지표 값을 제공하기 위한 인터페이스를 포함할 수 있다.

다양한 구현예에서, 리소스 관리자(170)는 플랫폼 리소스 추천에서 플랫폼 리소스 할당에 대한 추천을 제공할 수 있다. 플랫폼 리소스는 특정 작업을 수행하도록 할당된 시스템(100)의 장치일 수 있다. 리소스 관리자(170)는 작업 부하 개시자가 작업 부하를 수행하기 위해 추천된 플랫폼 리소스들(예를 들어, 시스템(100)의 다양한 장치들) 중 하나 이상을 선택하거나 거부할 수 있도록 애플리케이션(162)과 같은 작업 부하 개시자에게 플랫폼 리소스 추천을 제공한다. 이는 전통적으로 플랫폼 리소스의 전체 기능 또는 심지어 플랫폼 리소스에 대한 심층적인 지식 없이도 OS(164)에 의해 플랫폼 리소스가 할당되기 때문에 작업 부하 개시자에게 유리하게 된다. 예를 들어, APU(102) 및 GPU 성능 능력 또는 제한(라이센스 또는 설계로 인함)은 OS(164)에 표시되지 않는다. 또한, 애플리케이션(162)과 OS(164) 각각에는 작업 클래스 도메인별로 이용 가능한 리소스를 평가하기 위한 상세한 런타임 플랫폼 부하 정보가 부족할 수 있다.

다양한 유형의 애플리케이션이, 각각 다양한 유형의 작업 부하를 갖는 작업 부하 개시자가 될 수 있다. 일부 예에서, 작업 부하 개시자의 요청은 작업 부하 유형, 작업 부하 특징, 처리 요건, 및/또는 작업 부하에 대한 성능 기대치를 설명한다. 예를 들어, 미디어 플레이어 애플리케이션에는 컴퓨팅 시스템에서 실행하려는 미디어 재생 작업 부하가 있을 수 있다. 이러한 예에서, 작업 부하의 설명에는 재생 작업 부하에 대한 소스 해상도, 디스플레이 해상도, 비트 전송률, 비디오 코덱, 오디오 코덱, 및 프레임 속도가 포함된다. 또 다른 예로, 화상 회의 애플리케이션에는 컴퓨팅 시스템을 실행하려는 트랜스코드 작업 부하가 있을 수 있다. 이러한 예에서, 작업 부하 설명에는 소스 비디오 코덱, 타겟 비디오 코덱, 및 프레임 속도가 포함될 수 있다. 화상 회의 애플리케이션은 스크린 상의 참가자의 배경을 제거/대체하거나 또는 시선을 교정하기 위한 인공 지능(AI) 알고리즘을 포함하는 인공 지능(AI) 작업 부하도 포함할 수 있다.

일부 예에서, 리소스 관리자가 구문 분석할 수 있는 설명 언어를 사용하여 작업 부하에 대한 설명을 제공할 수 있다. 예를 들어, 설명 언어는 비트 전송률에 대한 설명 태그, 디스플레이 해상도에 대한 설명 태그, 비디오 인코딩 프로토콜에 대한 설명 태그 등을 포함한다. 이러한 예에서, 작업 부하에 대한 설명은 작업 부하에 대한 구조화된 설명이다. 일부 예에서, 아래에서 더 자세히 설명되는 바와 같이, 요청에 포함된 설명 언어는 리소스 관리자(170)의 정책 엔진(174)에 의해 분석 가능하다.

플랫폼 리소스 추천에 대한 요청을 수신하는 것과, 복수의 플랫폼 리소스의 요청 및 성능 능력과 활용도 지표에 기반하여 하나 이상의 플랫폼 리소스 후보를 식별하는 것과, 식별된 하나 이상의 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하는 것에 대해 논의하는 추가적인 자세한 내용은 아래에 제공된다.

추가 설명을 위해, 도 2는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(200)의 추가 블록선도를 설명한다. 단지 예시적인 도 2의 예에서, 예시적인 시스템(200)은, CPU(106), GPU(104), 오디오 코덱(122)(예를 들어, 오디오 코프로세서), 비디오 코덱(120), 및 GPU 계산 엔진(110), 및 디스플레이 제어기(124)를 통합한 APU(102)를 포함한다. dGPU(134)는 비디오 코덱(150), GPU 계산 엔진(140), 및 디스플레이 제어기(154)를 포함할 수 있다. 도 1의 각 컴포넌트는 APU(102) 및 dGPU(134)에 포함될 수 있지만 도 2에 도시된 것들은 예시의 편의를 위해 사용된 것임을 유의해야 한다. 플랫폼 리소스 무결성 서비스(210)(예를 들어, 플랫폼 리소스 추천 서비스)는 또한 스마트 시프트 컴포넌트(242) 및 플랫폼 컴포넌트(240)와도 연관된다.

일 양태에서, 스마트 시프트 컴포넌트(242)는 엔진별 활용도에 대한 정보를 제공하고, 주문형 집적 회로(ASIC)에 대해 요청된 추가 정보를 제공한다. 스마트 시프트 컴포넌트(242)는 작업 부하당 전력 예산/요건에 관한 정보를 제공하고, 필요에 따라 플랫폼 리소스들 간의 전력 할당을 시프트하는 데 도움을 준다. 즉, 스마트 시프트 컴포넌트(242)는 플랫폼 리소스들로의 전력 분배의 재균형을 돕는다. 스마트 시프트 컴포넌트(242)는, 예를 들어 APU(102) 및 dGPU(134)와 같은 플랫폼 리소스의 능력과 관련된 전력, 성능, 발열, 및 정책을 플랫폼 리소스 무결성 서비스(210)에 제공한다.

도시된 바와 같이, APU(102) 및 dGPU(134)는 플랫폼 리소스 무결성 서비스(210)와 통신한다. 즉, 플랫폼 리소스 무결성 서비스(210)는 "스마트 할당자"(예를 들어, "SmartAlloc)"로 지칭될 수 있다. 플랫폼 리소스 무결성 서비스(210)는 APU(102)와 연관된 시스템 메모리(160)와도 연관된다. 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)의 그래픽 메모리(180)(예를 들어, 로컬 메모리)와도 연관된다.

다시, 도 1과 유사하게, APU(102)는 PCIe 상호 연결(190)과 같은 상호 연결을 통해 dGPU(134)와 통신한다. 일부 예에서, APU(102) 및 dGPU(134)는 동일한 기판(예를 들어, 인쇄 회로 기판)에 구현될 수 있다. 플랫폼 컴포넌트(240)는 플랫폼 리소스 무결성 서비스(210)와 통신하기 위한 APU(102)와 dGPU(134) 사이의 인터페이스일 수 있다.

플랫폼 리소스 무결성 서비스(210)는 엔진 선택 지침을 제공하기 위해 플랫폼 기능을 수집, 저장, 및 모니터링하는 사용자 모드 서브시스템이다. 즉, 플랫폼 리소스 무결성 서비스(210)는 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)(예를 들어, 도 1의 그래픽 메모리(180))의 능력과 관련된 모든 데이터에 접근하고 이를 저장한다. 플랫폼 리소스 무결성 서비스(210)는, 예컨대 컴퓨터 플랫폼에 설치된 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)의 능력 및 이와 함께 이들의 작업 모드 각각, APU(102)와 dGPU(134) 사이의 상호 연결 능력, 교류(AC) 및 직류(DC) 모드 동안의 전력 한계(power envelope), 및 연결될 수 있는 주변 기기(예를 들어, 카메라, 디스플레이 패널 등이 있지만 설명의 편의를 위해 도시되지 않음)의 능력과 같은, 모든 플랫폼 리소스에 접근하며 그에 대한 지식을 갖는 중앙 집중식 플랫폼 "브레인"으로 기능한다.

추가적으로, 플랫폼 리소스 무결성 서비스(210)는, 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)와 같은, 플랫폼 리소스의 심지어 검색 불가능한(예를 들어, OS에 의해 검색 불가능한) 능력 또는 알려진 제한 사항에 대한 완전한 지식과 인식을 갖는다. 플랫폼 리소스 무결성 서비스(210)는 플랫폼 컴포넌트(240)를 사용하여 예를 들어 도 1의 애플리케이션(162)과 같은 작업 부하 개시자로부터 플랫폼 리소스 추천에 대한 요청을 수신할 수 있다. 따라서, 플랫폼 리소스 무결성 서비스(210)는 작업 부하 시작 또는 런타임 시 사용 중인 플랫폼의 하드웨어 리소스에 대한 정보를 수집하고, 작업 부하 개시자 자체가 이용 가능한 리소스를 조정하고 사용할 수 있게 할 수 있다. 플랫폼 리소스 무결성 서비스(210)는 작업 부하 개시자의 질의가 있을 때에는 사용 사례 클래스별로 추천된 리소스 힌트(예를 들어, GPU 또는 APU 및 해당 엔진)를 반환할 수 있다.

플랫폼 리소스 무결성 서비스(210)는 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)와 같은 복수의 플랫폼 리소스의 성능 능력 및 활용도 지표를 분석하고 검사한다. 플랫폼 리소스 무결성 서비스(210)는 작업 부하 개시자에게, 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)와 같은 복수의 플랫폼 리소스 중 하나 이상을 선택하여 성능 능력 및 활용도 지표에 기반하여 작업 부하를 실행하도록, 플랫폼 리소스 추천을 제공한다. 플랫폼 리소스 추천은 또한 복수의 플랫폼 리소스의 비성능 능력 및 성능 제한에 기반할 수도 있다. 플랫폼 리소스 무결성 서비스(210)는 플랫폼 리소스 라이브러리에 있는 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 수집하고 저장하고 모니터링한다.

일 양태에서, 플랫폼 리소스 무결성 서비스(210)는, 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 그래픽 메모리(180)와 같은 복수의 플랫폼 리소스 각각에 대한 검색 불가능한 성능 능력, 성능 제한, 및 이력 성능 데이터를 작업 부하 개시자로부터의 플랫폼 리소스 추천에 대한 요청에 기반하여 결정하기 위한 동적 플랫폼 리소스 라이브러리(SmartAlloc 라이브러리)이다.

플랫폼 리소스 무결성 서비스(210)는 작업 부하의 시작 또는 런타임 동안, 예를 들어 APU(102), dGPU(134), 시스템 메모리(160), 및 로컬 메모리(180)와 같은 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 모니터링한다. 플랫폼 리소스 무결성 서비스(210)는 작업 부하의 런타임 동안, 업데이트된 플랫폼 리소스 후보를 복수의 플랫폼 리소스의 조정된 성능 능력 및 조정된 활용도 지표에 기반하여 동적으로 제공할 수 있다.

플랫폼 리소스 무결성 서비스(210)는 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 각각의 순위를 매긴다. 예를 들어, 순위 매기기는 추가 작업 부하 작업을 수신하기 위해서는 플랫폼 리소스가 전력 임계값 수준 아래로 떨어지지 않아야 하는 것과 같은 정책에 기반할 수 있다. 대안적으로, 순위 매기기는 작업 부하 및 사용자 기본설정과 관련된 플랫폼 능력에 기반할 수도 있다.

플랫폼 리소스 무결성 서비스(210)는 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 중 하나 이상 각각에 대해 작업 부하를 실행하기 위한 활용도 영향을 예측한다.

추가적인 설명을 위해, 도 3a는 본 발명의 일부 구현예에 따른 것으로, 클라이언트-서버 스마트 할당(alloc)을 위한 예시적인 시스템(300), 예를 들어 상위 레벨 시스템의 추가 블록선도를 설명한다. 도 3의 예에서, 단지 예시적으로, 예시적인 시스템(300)은 본원에서 "플랫폼 리소스 무결성 서비스"(210)(예를 들어, "플랫폼 리소스 무결성 서비스")로 지칭되는 클라이언트-서버 스마트 할당 서비스를 포함한다. 따라서, "플랫폼 리소스 무결성 서비스(210)"라는 언급은 클라이언트-서버 스마트 할당 또는 "스마트 할당" 서비스와 상호교환 가능하게 사용될 수 있다. 전술한 바와 같이, 도 2의 플랫폼 리소스 무결성 서비스(210)는 예를 들어 플랫폼 리소스 라이브러리(314A, 314B)와 같이 서버측에 제공될 수 있으며 사용자 모드에서도 제공될 수 있는 플랫폼 리소스 라이브러리(312)를 포함한다. 따라서, 플랫폼 리소스 무결성 서비스(210)는 주문 방식으로 로드되어 호출될 수 있는 서비스와 라이브러리로 집합적으로 제공될 수 있다.

본원에서 사용되는 "스마트 할당(smart allocation)" 또는 "스마트 할당(smart alloc)"이라는 용어는 플랫폼 리소스 무결성 서비스를 제공하는 하나 이상의 작업 또는 시스템을 지칭할 수 있다. 또한, "스마트 할당(smart allocation)" 또는 "스마트 할당(smart alloc)"이라는 용어는, 복수의 플랫폼 리소스의 요청과 성능 능력과 활용도 지표에 기반하여 하나 이상의 플랫폼 리소스 후보를 식별할 수 있고 식별된 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공할 수 있는 작업 또는 시스템을 지칭할 수 있다. 플랫폼 리소스는 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 또한 "스마트 할당" 작업 또는 시스템은 작업 부하 개시자(예를 들어, 애플리케이션)를 대신하여 리소스를 "할당"하지 않고, 다만 리소스 할당을 선택하는 작업 부하 개시자에게 추천 또는 '힌트'만 제공한다.

플랫폼 리소스 라이브러리(312)는 2개의 모드, 즉 1) 클라이언트 전용 모드(또는 클라이언트 모드/사용자 모드)(예를 들어, 애플리케이션 또는 드라이버)와, 2) 클라이언트-서버 모드(또는 서버 모드)로 동작한다. 본원에서 사용되는 클라이언트 전용 모드(또는 클라이언트 모드/사용자 모드)라는 언급은 "스마트 할당 클라이언트 모드"로도 지칭될 수 있다는 점에 유의해야 한다. 마찬가지로, 클라이언트-서버 모드(또는 서버 모드)라는 언급은 "스마트 할당 서버 모드"로도 지칭될 수 있다.

클라이언트-서버 모드에서, 클라이언트는, 도 3a, 도 3b, 및 도 4에서 설명된 바와 같이, 애플리케이션과 링크되는 플랫폼 리소스 라이브러리일 수 있으며, 서버는 플랫폼 리소스 추천을 위한 리소스 추정 작업을 수행한다.

클라이언트 전용의 경우, 클라이언트는 도 3c에서와 같이 애플리케이션과 링크되는 플랫폼 리소스 라이브러리일 수 있고, 플랫폼 리소스 추천을 위한 리소스 추정 작업을 수행한다. 일 양태에서, 클라이언트 전용 모드를 사용하는 한 세트의 애플리케이션은 클라이언트 플랫폼 리소스 라이브러리 통신을 통해 스마트 할당 가능 애플리케이션의 서버리스 메시를 구축하여 서버 중심 방식을 효과적으로 실행하도록 하는 클라이언트 플랫폼 리소스 라이브러리 코드를 가질 수 있다.

예를 들어 사용자 모드(320A 및 320B)와 같은 사용자 모드(예를 들어, 클라이언트 모드)에서, 사용자 모드(320A, 320B)(또한 "사용자 모드 드라이버"의 드라이버(344))는 플랫폼 리소스 라이브러리(314A, 314B)와 링크되거나 이 플랫폼 리소스 라이브러리를 로드할 수 있으며, 플랫폼 리소스 라이브러리(314A, 314B)에 의해 노출된 API(예를 들어, 플랫폼 리소스 인터페이스 또는 "내부 인터페이스")를 플랫폼 리소스 라이브러리(312)(서버 측)를 이용하여 호출한다.

서버 모드에서, 플랫폼 리소스 무결성 서비스(210)는 플랫폼 리소스 라이브러리(312)를 제공하고, 서버 모드를 호스팅할 수 있고, 연속적으로 실행되며, 서버 모드에서 초기화된 플랫폼 리소스 라이브러리(312)와 링크된다. 사용자(예를 들어, 작업 부하 개시자)의 요청(예를 들어, API 호출)이 있을 때, 그 요청은 동기적 작업에서 원격 프로시저 호출(RPC)을 사용하여 플랫폼 리소스 라이브러리(312)에서 서버 측으로 전달된다.

플랫폼 리소스 라이브러리(312)는 예를 들어 리소스 플랫폼 레코드(340)와 같은 레코드 세트에 의해 배포될 수 있고 그 레코드 세트가 첨부될 수 있다. 레코드(340)는 운영 체제에 의해 검색 불가능한 능력, 제한 사항, 성능 지표, 및 이력 데이터를 포함하는 플랫폼 리소스 능력들의 목록일 수 있다. 레코드(340)는 플랫폼 리소스 라이브러리(312)에 의해 읽기 전용으로 사용될 수 있다. 레코드(340)는 플랫폼 리소스 라이브러리(312)에 제공될 수 있으며, OEM(original equipment manufacturer) 및 플랫폼별 추가 정보가 재정의(override)와 함께 질의될 수 있다. 일 양태에서, 레코드(340)는 예를 들어 RO SA DB(RO SA(SmartAlloc) DB)와 같은 읽기 전용(RO) 데이터베이스(DB)로 간주될 수 있다. 레코드(340)는 플랫폼 리소스 무결성 서비스(210)에 의해 암호화 및 복호화될 수 있다.

레코드(340)는 드라이버 업데이트 설치와 함께 업데이트되며, 디버깅 및 테스트 목적을 위한 드롭인 교체로 사용된다. 작업 부하 개시자로부터 요청을 수신한 때, 레코드(340)는 인스턴스화되고, 병합되고, 그리고/또는 업데이트되며, 플랫폼 리소스와 관련된 최신 활동 데이터/지표를 수집, 저장, 및 기록하는 중에도 연속적으로 사용되고 있는 예를 들어 전체 정적 플랫폼 리소스 능력 목록과 같은 포괄적인 플랫폼 데이터 세트로 제공된다.

운영 체제 부팅 시 또는 특정 애플리케이션의 최초 실행 시, 플랫폼 리소스 라이브러리(312)는 플랫폼 리소스 검색 작업을 실행하고, 모든 이용 가능한 플랫폼 정보를 결정/검색한 다음, 레코드(340)에 대해 검색 데이터를 교차 확인하여, 시스템(300)의 완전한 정적 플랫폼 리소스 능력 목록을 구축한다. 정적 플랫폼 리소스 능력 목록은 플랫폼 리소스 라이브러리(312)에 저장될 수 있으며, 그 라이브러리에서는 플랫폼 리소스 라이브러리(312)에 대한 후속 질의에 의해 정적 플랫폼 리소스 능력 목록으로 액세스할 수 있다.

대조적으로, 동적 작업(예를 들어, 시스템(300)에서 현재 상태, 부하, 및 GPU 엔진별 사용을 결정하기 위한 작업)의 경우, 플랫폼 리소스 라이브러리(312)는 현재 플랫폼 리소스 지표를 수집하고, 모으고, 처리하고, 저장하고, 모니터링한다.

추가적인 일 양태에서, 예를 들어 사용자 모드(320A 또는 320B)와 같은 사용자 모드에서, 사용자 모드 무결성 프로세스는 플랫폼 리소스 라이브러리에 연결한 다음, 예를 들어 플랫폼 리소스 라이브러리(314A 또는 314B)와 같은 사용자 모드 플랫폼 리소스 라이브러리를 호스팅하는 데 사용된다. 플랫폼 리소스 라이브러리(312) 인스턴스는 플랫폼 리소스 무결성 서비스(210)에 의해 초기화 시점에 서버 모드에서 플랫폼 리소스 무결성 서비스(210)에 링크될 수 있다. 플랫폼 리소스 무결성 서비스(210)는 원격 절차 호출(RPC: remote procedure call) 요청을 수신한 때에 무결성 작업을 수행하고 (클라이언트와 링크된) 다른 플랫폼 리소스 라이브러리 인스턴스를 서비스한다.

예를 들어, 플랫폼 리소스 라이브러리(314A 또는 314B)와 같은 플랫폼 리소스 라이브러리는 클라이언트별 플랫폼 정보 질의를 제공하기 위해 다수의 클라이언트 프로세스와 링크될 수 있다. 이들 인스턴스는 예를 들어 사용자 모드(320A 또는 320B)와 같은 사용자 모드에서 (예를 들어, 사용자 모드 플랫폼 리소스 인터페이스(322A 및 322B)를 사용하여) 초기화된 예를 들어 플랫폼 리소스 라이브러리(314A 또는 314B)와 같은 플랫폼 리소스 라이브러리를 갖는다. 서버 모드에서 초기화되는 플랫폼 리소스 라이브러리만이 플랫폼 리소스 무결성 서비스(210)와 링크되는 플랫폼 리소스 라이브러리(312)이고 그 밖의 모든 플랫폼 리소스 라이브러리는 유저 모드에서 초기화된다는 점에 유의해야 한다.

서버 모드에서의 플랫폼 리소스 라이브러리(312)를 더 설명하기 위해, 도 3b는 서버 모드(예를 들어, 스마트 할당 서버 모드)에서 플랫폼 리소스 추천 서비스를 플랫폼 리소스 라이브러리로서 제공하기 위한 예시적인 시스템(315)의 추가 블록선도를 설명한다.

시작 시, 플랫폼 리소스 무결성 서비스(210)는 플랫폼 하드웨어 및 상태 검색 관리자(328)를 사용할 수 있는 서버 모드에서 초기화하기 위해 플랫폼 리소스 라이브러리(312)를 로드하고 호출한다. 플랫폼 리소스 라이브러리(312)는 서버 모드에서 시작하기 위한 초기 호출을 수신한 때에, 플랫폼 상태 변경 리스너(325)(예를 들어, OS 알림 리스너)를 통해 리소스 추천 요청을 위해 운영 체제(OS) 또는 드라이버에 의해 트리거되는 플랫폼 및 시스템 이벤트를 구독한다. 플랫폼 리소스 라이브러리(312)는 장치, 엔진, 속성(prop), 및 상태 통신 관리자(324)를 사용하여, 예를 들어 드라이버 검색(344)과 같은, 장치 검색(예를 들어, 모든 사용 가능한 하드웨어 장치 검색) 및 그 밖의 모든 대체 장치(316)(예를 들어, 제3자 장치)를 시작한다. 플랫폼 리소스 라이브러리(312)는 대체 장치 통신 관리자(326)를 사용하여, 예를 들어 플랫폼 리소스와 같은, 대체 장치(예를 들어, 제3자 장치) 및 속성(예를 들어, 장치 엔진, 장치 엔진 속성, 및 정적 능력 "캡")의 목록을 구축할 수 있다.

플랫폼 리소스 라이브러리(312)는 레코드 데이터베이스(346)(예를 들어, RO SA DB) 또는 소프트웨어 기본 입력 출력 시스템(SBIOS)을 판독하고, 가능한 경우 그 레코드에 재정의를 적용한다. 플랫폼 리소스 라이브러리(312)는 임의의 플랫폼 능력 변경이 식별되면 플랫폼 데이터베이스(348)에서 업데이트하거나, 또는 플랫폼 하드웨어 및 상태 검색 관리자(328)를 통해 식별되지 않으면 추가 플랫폼 능력을 생성한다. 플랫폼 리소스 라이브러리(312)는 또한 각 플랫폼 리소스에 대한 플랫폼 상태를 결정하고, 플랫폼 하드웨어 및 상태 검색 관리자(328)를 사용하여 플랫폼 상태 관리자(332)에 식별된 상태를 설정할 수 있다.

런타임 시, 플랫폼 정적 능력(330)이 생성되거나 업데이트될 수 있고, 장치 도착/제거 감지 시, 플랫폼 상태 변경 리스너(327)는 플랫폼 하드웨어 및 상태 검색 관리자(328)를 사용하여 여기에 설명된 시작 작업을 시작한다. 플랫폼 상태 변경 리스너(327)는 플랫폼 데이터베이스(348)(예를 들어, 읽기/쓰기 레코드 데이터베이스)를 업데이트하고/하거나 필요한 경우 플랫폼 상태 변경 리스너(327)에 상태를 설정할 수 있다. 플랫폼 상태 변경 리스너(327)는 임의의 플랫폼 리소스 상태 변경과 관련된 정보를 사용자 플랫폼 리소스 인터페이스(322)(예를 들어, 사용자 플랫폼 리소스 인터페이스 관리자)에 알리고 제공할 수 있다.

사용자 플랫폼 리소스 인터페이스(322)는 (플랫폼 리소스 라이브러리(314)를 통해) 모든 플랫폼 리소스 상태 변경에 대한 모든 알림을 사용자에게 제공하고, 플랫폼 리소스 추천(예를 들어, 힌트)을 사용 사례별 정책 관리자(334)로 리디렉션한다. 예를 들어 사용자 플랫폼 리소스 라이브러리(314)와 같은 각 플랫폼 리소스 라이브러리(예를 들어, 클라이언트별 각 플랫폼 리소스 라이브러리)에 대해 추적이 필요한 경우, 플랫폼 리소스 라이브러리(312)는 (서버 모드에서) 사용자 식별자(ID)를 사용하여 각 사용자의 등록 및 등록 취소를 보조 채널(AUX)을 통해서 수락할 수 있다. 사용자 플랫폼 리소스 인터페이스(322)는 플랫폼 상태 관리자(332)에 각각의 등록된 클라이언트와 함께 활성 사용자/클라이언트 상태 또는 "살아있는 상태"를 유지할 수 있다. 사용자 플랫폼 리소스 인터페이스(322)는 이전에 "활성 상태"로 등록된 사용자/클라이언트의 것들을 소거, 제거, 및/또는 스크러빙하도록 플랫폼 상태 관리자(332)에 표시할 수 있지만, 더 이상 활성 사용자/클라이언트 상태를 유지하지 않거나 사용자 플랫폼 리소스 인터페이스(322)로부터 활성 사용자 상태 확인을 하지 못한다. 추가적으로, 사용자 플랫폼 리소스 인터페이스(322)는 사용자에게 크로스 프로세스 통신 채널을 제공한다.

추가적인 양태에서, 정책 관리자(334)는 플랫폼 리소스 추천 요청(예를 들어, 리소스 할당 힌트 요청)을 수신하고 처리한다. 이렇게 함으로써, 정책 관리자(334)는 사용 사례 클래스 요청을 결정하고, 플랫폼 데이터베이스(348)의 요청 레코드로부터 예를 들어 요청의 일부로서의 특정 엔진 또는 형식 요구 사항이 있는지 여부와 같은 요청의 세부 사항을 결정한다. 정책 관리자(334)는 플랫폼 데이터베이스(348)로부터 정적 능력 레코드 및 플랫폼 리소스 상태를 검색해서, 요청별로 추천할 하나 이상의 플랫폼 리소스를 결정하기 위해 사용 사례별 힌트 요청을 적용한다. 일 양태에서, 플랫폼 데이터베이스(348)는 플랫폼 결함 또는 기타 이유가 있는 경우에는 정책 재정의를 (레코드 데이터베이스(346)로부터 병합된 레코드들의 일부로서) 가질 수 있다.

런타임 시, 동적 능력이 정적 능력의 확장인 플랫폼 리소스의 플랫폼 동적 능력에 대해, 동적 능력 관리자(352)가 시작될 수 있다. 작업 부하 개시자가 플랫폼 리소스 추천 요청을 시작한 때, 정책 관리자(334)는 플랫폼 데이터베이스(348)의 동적 레코드를 결정하고 확인하여, 정적 능력 레코드에 대해 위에서 설명한 프로세스와 유사하게 리소스 할당 결정을 내린다.

일 양태에서, 동적 능력 관리자(352)는 제3자 장치 통신 관리자(326)를 통해 장치의 엔진 부하 및 대체 장치 부하(적용 가능한 경우)를 획득하고, 그 정보를 플랫폼 데이터베이스(348)의 동적 능력 레코드에 저장한다. 제3자 장치 통신 관리자(326)는 동적 능력 관리자(352)로부터 요청을 수신한 때에 대체 장치(예를 들어, 드라이버(344)) 각각에 대한 전력 관리 상태 및 소비를 확인하고 결정한다.

동적 능력 관리자(352)는 예를 들어 플랫폼 상태 변경, 사용자 플랫폼 리소스 추천/힌트 요청(응답 시간이 손상되지 않는 경우), 또는 주기적인 확인 요청과 같은 하나 이상의 이벤트에 뒤이은 플랫폼 리소스에 대한 부하 확인을 트리거한다. 동적 능력 관리자(352)는 플랫폼 장치 엔진(들) 사용의 이력 프로파일을 구축 및 유지할 수 있고, 그 이력 프로파일을 플랫폼 데이터베이스(348)의 동적 능력 레코드에 저장할 수 있다.

추가적인 양태에서, 사용자/클라이언트 추적이 필요하고 각각의 사용자/클라이언트 플랫폼 리소스 추천/힌트 요청이 저장되고 기록되어야 하는 경우, 사용자 플랫폼 리소스 인터페이스(320)는 동적 능력 관리자(352)에 그러한 요구 사항을 통지할 수 있다. 클라이언트는 (플랫폼 리소스 라이브러리(314)를 통해) 플랫폼 리소스 라이브러리(314)에 의해 생성되어 사용자 플랫폼 리소스 인터페이스(320)에 의해 제공되는 클라이언트 ID로 식별된다. 또한, 사용자 플랫폼 리소스 인터페이스(320)는 클라이언트가 연결을 종료한 경우 이를 동적 능력 관리자(352)에 통지하고, 종료된 클라이언트 사용자 ID를 제공하여 임의의 예약된 리소스를 해방시킨다.

이벤트 구독의 경우, 플랫폼 리소스 라이브러리(312)에 상주할 수 있는 플랫폼 상태 변경 리스너(327)가 서버 모드에서 활성화된다. 플랫폼 상태 변경 리스너(327)는 다양한 이벤트를 모니터링하고 청취하며, 시스템 또는 드라이버 이벤트들의 목록을 제공/포함한다. 이벤트들의 목록은 시간이 지남에 따라 증가하고 늘어날 수 있다. 한 양태에서, 플랫폼 상태 변경 리스너(327)는, 예를 들어 AC/DC 스위치 이벤트, 플랫폼 리소스의 추가 또는 제거, 또는 전원(예를 들어, 배터리/성능 슬라이더)을 통한 사용자 요청에 기반한 전력 한계 변경, 또는 예를 들어 AC 및 DC 모드 변경과 같은 제어판 설정 변경과 같은, 플랫폼 리소스 라이브러리(312)에 항상 등록되어야 하는 다양한 필수 이벤트를 모니터링하고 청취한다. 일 양태에서, 동시에 발생하는 다수의 이벤트가 있을 수 있다. 플랫폼 리소스 라이브러리(312)는 각 이벤트를 대기열에 추가하고, 발생 순서대로 처리한다. 운영 체제는 장치(예를 들어, 비주요 디스플레이 GPU)를 예를 들어 D3 핫 또는 D3 콜드 상태와 같은 핫 또는 콜드 상태로 설정한다는 것을 유의해야 한다. 이러한 장치에 접근하면 장치가 깨어난다. 따라서, 플랫폼 리소스 라이브러리(312)는 임의의 비-D0 상태(예를 들어, D1, D2, 및 D3 전력 상태)에 있는 장치를 구독하고, 그 장치로의 액세스를 피한다. 오히려, 플랫폼 리소스 라이브러리(312)는 모든 플랫폼 리소스 능력을 저장 및 캐싱하고, 작업 부하 개시자에게 플랫폼 리소스 추천을 제공할 때 모든 플랫폼 리소스를 이용 가능한 것으로 간주한다.

플랫폼 리소스 라이브러리(312)를 더 설명하기 위해, 도 3c는 플랫폼 리소스 라이브러리를 사용하여 클라이언트 모드에서 스마트 할당 서비스를 제공하기 위한 예시적인 시스템(325)의 추가 블록선도를 설명한다. 즉, 도 3c는 플랫폼 리소스 라이브러리 자체가 서버 부분 없이(또는 스마트 할당 서버 모드 없이) 리소스 추정을 제공할 때의 클라이언트 전용 모드 변형을 도시한다. 본원에서 사용되는 바와 같이, 플랫폼 리소스 라이브러리를 이용하는 클라이언트 모드에서의 스마트 할당 서비스는 스마트 할당 서버 모드가 없는 클라이언트 모드(예를 들어, 사용자 모드)에서의 플랫폼 리소스 라이브러리로서의 플랫폼 리소스 추천 서비스로 지칭될 수 있다.

다시, 앞서 언급한 바와 같이, 도 3c는 클라이언트가 플랫폼 리소스 추천을 위한 리소스 추정을 위한 작업을 수행하는 애플리케이션과 링크되는 플랫폼 리소스 라이브러리일 수 있는 클라이언트 전용 모드에서의 작업을 도시한다. 또한, 클라이언트 전용 모드를 사용하는 한 세트의 작업 부하 개시자들(예를 들어, 애플리케이션들)에는 클라이언트 플랫폼 리소스 라이브러리 통신을 통해 스마트 할당 가능 애플리케이션의 서버리스 메시를 구축하여 클라이언트-서버 방식을 효과적으로 실행하도록 하는 클라이언트 플랫폼 리소스 라이브러리 코드가 있을 수 있다.

시스템(325)은 본원에 설명된 것과 유사한 컴포넌트를 사용하면서 사용자 모드(예를 들어, 스마트 할당 클라이언트 모드)에서 플랫폼 리소스 무결성 서비스(210) 및 플랫폼 리소스 라이브러리(314)의 필수 컴포넌트의 예시적인 구현을 제공한다. 이러한 방식으로, 예시적인 시스템(325)은 완전한 클라이언트-서버 아키텍처 또는 다른 유형의 컴퓨팅 시스템으로의 플랫폼 리소스 무결성 서비스(210)의 향후 확장 및 이식을 수용하도록 조정될 수 있다.

한 구현예에서, 클라이언트 애플리케이션(예를 들어, 사용자 모드 애플리케이션) 또는 사용자 모드 드라이버는 플랫폼 리소스 추천에 대한 요청을 발행하는 사용자 모드에서 플랫폼 리소스 라이브러리(314)를 로드하거나 그와 링크하거나 그를 초기화한다. 도 3c에 도시된 바와 같이 플랫폼 리소스 라이브러리(314)는 도 3b에서 설명한 바와 같이 서버 모드가 아닌 클라이언트 모드에서 초기화된다는 것을 유의해야 한다.

플랫폼 리소스 라이브러리(314) 초기화 및 이식은 다음 활동을 초기화하고 구현하는 것을 포함할 수 있다. 일 양태에서, 플랫폼 리소스 라이브러리(314) 초기화 및 이식은 다양한 알림을 제공하고 구현하기 위해 사용자 플랫폼 리소스 인터페이스(320)를 통해 인터페이스 정의를 제공하는 것을 포함할 수 있다. 플랫폼 상태 변경 리스너(327)는 예를 들어 AC/DC 전력 이벤트와 같은 하나 이상의 플랫폼 시스템 이벤트를 구독한다. 모든 플랫폼 능력은 인터페이스 지원 도메인으로만 축소될 수 있다. 또한, 플랫폼 리소스의 정적 능력은 변경되지 않은 것으로 간주될 수 있으며, 플랫폼 데이터베이스(348)를 사용하여 한 번만 검색될 수 있다. 플랫폼 리소스의 동적 능력은 플랫폼 리소스 추천 요청 시 동적 능력 관리자(352)를 통해 조회할 수 있다. 또한, 플랫폼 리소스 라이브러리(314) 초기화 및 이식은 본원에 설명된 바와 같이 D3 상태 장치의 불필요한 웨이크업을 인식하게 되고 방지하게 되는 것을 포함할 수 있다. 동적 능력 관리자(352)에 저장된 동적 능력의 모든 이력 데이터는 다양한 플랫폼 리소스의 플랫폼 능력을 결정하기 위해 필요한 부하 이력을 결정하는 데 사용될 수 있다.

플랫폼 리소스 라이브러리(314)는 클라이언트 애플리케이션(예를 들어, 작업 부하 개시자)이 추천 플랫폼 리소스 또는 힌트에 대해 문의할 수 있는 진입점을 클라이언트 애플리케이션에 제공한다.

일 양태에서, 클라이언트는 하나 이상의 유형의 알림에 대한 알림을 수신하기 위해 플랫폼 리소스 라이브러리(314)를 구독한다. 구독 시, 플랫폼 리소스 라이브러리(314)는 예를 들어 AC/DC 스위치 또는 장치 도착/제거와 같은 플랫폼 상태 관리자(332)를 통해 다양한 플랫폼 리소스 상태 변경에 대한 임의의 알림을 클라이언트에 제공한다. 일부 이벤트의 경우, 이전에 발행된 플랫폼 리소스 추천/힌트가 무효화될 수 있다. 이 경우, 플랫폼 리소스 라이브러리(314)는 업데이트된 플랫폼 리소스 추천 또는 할당 힌트를 동적으로 제공할 수 있다. 그러나 플랫폼 리소스를 재할당하는 결정 또는 이전에 할당된 플랫폼 리소스의 사용을 유지하는 결정은 클라이언트의 재량에 달려 있다. 즉, 플랫폼 리소스 라이브러리(314)는 플랫폼 리소스 추천이나 할당 힌트만을 제공할 뿐, 이전에 할당된 플랫폼 리소스를 재할당할지 계속 사용할지는 결정하지 않는다.

일 양태에서, 사용 사례 클래스별로 플랫폼 리소스 추천이 제공될 수 있다. 클래스별 플랫폼 리소스들의 목록이 제공되어 사용자 플랫폼 리소스 인터페이스(320)와 연계하여 사용될 수 있다. 사용자 플랫폼 리소스 인터페이스(320)는 플랫폼 리소스 라이브러리(314)를 통해, 계층적 사용 사례 클래스 각각과 연관된 세부 사항 및 리소스와 함께 계층적 사용 사례 클래스를 제공한다. 이용 가능한 모든 사용 사례 도메인 클래스와, 클래스별 플랫폼 리소스 목록이 사용자 플랫폼 리소스 인터페이스(320)와 함께 제공될 수 있다.

추가적인 양태에서, 플랫폼 리소스 라이브러리(314)는 사용자/클라이언트에게 플랫폼 리소스 추천을 사용자 플랫폼 리소스 인터페이스(320)를 통해 제공한다. 플랫폼 리소스 추천에는 플랫폼 리소스 클래스, 세부 사항, 성능 능력, 및 활용도 지표가 포함된다.

플랫폼 리소스 라이브러리(314)가 수신한 리소스 조회는 플랫폼 리소스(예를 들어, 비디오 또는 오디오)의 사용 사례 클래스(예를 들어, 도메인)와, 예를 들어 비디오 클래스의 인코딩 표준의 유형과 같은 플랫폼 리소스 추천 요청에 대한 특정 세부 사항을 지정한다. 사용 사례 클래스 및 사용 사례의 특정 세부 사항은 사용할 최상 또는 "최적" 플랫폼 리소스에 대한 플랫폼 리소스 추천을 제공하기 위한 플랫폼 리소스 라이브러리(314)로의 입력으로 사용될 수 있다. 플랫폼 리소스 추천은 예를 들어 추천 CPU 또는 GPU 셰이더 제공과 같이 구체적일 수 있으며, 심지어 전용 하드웨어를 제공할 수도 있다. 따라서, 플랫폼 리소스 라이브러리(314)는 요청의 목적 및 세부 사항에 적합할 수 있는 특정 장치 및 리소스 설명을 포함하는 플랫폼 리소스 추천을 사용자(예를 들어, 작업 부하 개시자)에게 제공한다.

추가적인 양태에서, 플랫폼 리소스 라이브러리(314)는, 선택적으로, 예를 들어 절전(예를 들어, 적은 전력)과 같은 효율성과 비교되는 품질(예를 들어, 많은 전력)을 위해 클래스(도메인)당 예를 들어 성능 기본설정과 같은 성능 프로파일을 제공할 수 있다. 이 옵션은 클라이언트가 특징 구현의 다수의 변형이 있는 경우에 실행을 위한 특정 추천 솔루션을 선택하기 위해 그 옵션을 플랫폼 리소스 추천에서 수신할 수 있게 한다. 일 양태에서, 성능 프로파일은 특정 플랫폼 리소스의 성능 능력 및 제한 사항을 포함한다. 성능 프로파일 데이터는 수집되고, 모니터링되어, 플랫폼 데이터베이스에 저장될 수 있다.

더 설명하기 위해, 도 4는 본 개시의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 제공하기 위해 사용자 모드에서 플랫폼 리소스 라이브러리를 이용하기 위한 예시적인 시스템(400)의 추가적인 블록선도를 설명한다. 더 구체적으로, 도 4는 클라이언트-서버 스마트 할당 시스템에 대한 클라이언트 또는 "클라이언트 모드"의 논리 선도를 도시하며, 이는 도 3b(서버 모드가 도시됨)와 보완적이고 도 3a에서 논의된다. 도 4의 예에서, 단지 예시적으로, 예시적인 시스템(400)은 서버 측에 제공될 수 있는, 플랫폼 리소스 라이브러리(312)와 통신하는 사용자 모드 애플리케이션/드라이버(410)를 포함한다. 사용자 모드 애플리케이션/드라이버(410)는 내부 또는 외부에 플랫폼 리소스 라이브러리(314)를 포함한다. 따라서, 도 2의 플랫폼 리소스 무결성 서비스(210)는, 요청 시 또는 필요에 따라 로드되고 호출될, 예를 들어 서버 모드의 플랫폼 리소스 라이브러리(312) 및 사용자 모드의 플랫폼 리소스 라이브러리(314)와 같은, 플랫폼 리소스 라이브러리와 플랫폼 리소스 무결성 서비스로서 집합적으로 제공될 수 있다.

한 구현예에서, 플랫폼 리소스 추천 서비스 제공을 위한 초기화 동안, 예를 들어 사용자 모드 애플리케이션/드라이버(410)와 같은 클라이언트 애플리케이션은 사용자 모드에서 플랫폼 리소스 라이브러리(314)를 로드하거나 그와 링크되거나 그를 초기화한다. 일 양태에서, 플랫폼 리소스 라이브러리(314)는 클라이언트 모드에서 초기화될 수 있는 반면, 서버 플랫폼 리소스 라이브러리(312)는 서버 모드에서 초기화된다. 플랫폼 리소스 라이브러리(314)는 일단 초기화되면, 사용자 모드에서, 서버 모드의 플랫폼 리소스 라이브러리(312)와의 통신을 확립한다. 그러나 플랫폼 리소스 라이브러리(312)와 플랫폼 리소스 라이브러리(314)의 연결이 확립될 수 없는 경우에는 사용자 모드 애플리케이션/드라이버(410)로 오류가 반환되어야 한다.

초기화 시, 플랫폼 리소스 라이브러리(312)는 서버 플랫폼 리소스 라이브러리(312)와의 크로스 프로세스 통신 채널을 확립하려고 시도한다. 플랫폼 리소스 인터페이스(320)는 크로스 프로세스 통신 채널을 제공한다. 플랫폼 리소스 라이브러리(314)는 일단 초기화되면, 사용자 모드 애플리케이션/드라이버(410)를 대신하여 플랫폼 리소스 라이브러리(314)와 통신하여, a) 플랫폼 리소스 추천(예를 들어, 사용 사례별 플랫폼 리소스 힌트 추천)에 대한 요청/응답을 제공하거나 수신하고, b) 임의의 플랫폼 상태 변경에 대한 알림을 받고, c) 선택적으로, 플랫폼 리소스 사용과 관련된 정보, 지표, 및 능력을 제공한다.

예를 들어, 사용자 모드 애플리케이션/드라이버(410)는 플랫폼 리소스 인터페이스(320)를 사용하여 플랫폼 리소스 라이브러리(314)를 호출하여, 예를 들어 도메인 사용 사례별 리소스 할당 추천에 대한 요청 또는 문의와 같은, 플랫폼 리소스 추천을 요청한다. 플랫폼 리소스 라이브러리(312)는 플랫폼 리소스 추천을 플랫폼 리소스 라이브러리(314)에 제공한다. 그러나, 플랫폼 리소스 추천 서비스 알림이 플랫폼 상태 변경으로 인해 플랫폼 리소스를 재할당하도록 제안하는 경우, 플랫폼 리소스를 재할당하는 것은 사용자 모드 애플리케이션/드라이버(410)의 책임이다. 사용자 모드 애플리케이션/드라이버(410)에 알림을 제공하기 위해 플랫폼 리소스 라이브러리(314)에 의해 스레드 풀(422)이 사용될 수 있다. 또한, 콜백이 스레드 풀(422)을 사용하여 차단 해제 형식으로 플랫폼 리소스 라이브러리(314)에서 구현되어, 콜백 자체 내에서 플랫폼 리소스 인터페이스(320)의 호출이 차단되지 않도록 하여 사용자 모드 애플리케이션/드라이버(410)가 완전히 재초기화를 완료하고 플랫폼 리소스 라이브러리(314)의 다른 인터페이스 기능을 호출할 수 있도록 할 수 있다.

다시, 여기서 언급한 바와 같이, 플랫폼 리소스 인터페이스(320)와 서버 플랫폼 리소스 라이브러리(312) 사이에, 예를 들어 요청/응답, 알림, 보조(AUX), 및 상태 변경 인터페이스 연결과 같은 다양한 연결 및 인터페이스가 확립될 수 있다.

일 양태에서, 플랫폼 리소스 인터페이스(320)는 사용자 모드 애플리케이션/드라이버(410)가 요청을 발행하고 플랫폼 리소스 추천에 대한 응답(예를 들어, 요청/응답)을 수신할 수 있게 한다. 일 양태에서, 플랫폼 리소스 추천에는 플랫폼 리소스 능력, 제한 사항, 활용도 지표, 특정 요구 사항에 대한 플랫폼 리소스 유형이 포함된다. 또한, 플랫폼 리소스 인터페이스(320)는 사용자 모드 애플리케이션/드라이버(410)가 예를 들어 임의의 플랫폼 상태 변경과 같은 다양한 알림을 구독할 수 있게 한다. 플랫폼 상태 변경은 또한 리소스 할당 또는 재할당 이벤트에 대한 업데이트된 플랫폼 리소스 추천을 포함 또는 구비할 수 있다.

예를 들어 클라이언트별 추적이 필요한 경우와 같은 때에 서버 플랫폼 리소스 라이브러리(312)에의 등록을 암시적으로 유지하고 "활성 상태로 유지"(또는 "살아있게 유지")하기 위해 AUX 정보 채널이 플랫폼 리소스 라이브러리(314)에 의해 생성될 수 있다.

사용자 식별(ID)은 플랫폼 리소스 라이브러리(314)에 의해 제공 및 생성(ID GEN)될 수 있으며, 이는 사용자 모드 애플리케이션/드라이버(410)를 추적하는 데 사용될 수 있다. 플랫폼 리소스 라이브러리(314)는 보조 채널을 언로드하지만 서버 플랫폼 리소스 라이브러리(312)에 의해 등록 해제될 수 있다. 또한, AUX 정보 채널은 (사용자 모드 애플리케이션/드라이버(410)의 개입 없이) 메시지를 활성 상태로/살아있는 상태로 유지하는/두는 데 사용될 수 있으며, 서버 모드 셧다운의 경우에는 서버 플랫폼 리소스 라이브러리(312)에 다시 연결하려고 시도한다. AUX 정보 채널은 연결 손실에 대한 알림을 제공하는 데 사용될 수 있으며, 연결 복구는 플랫폼 리소스 인터페이스(320)로 전송되어야 한다. AUX 정보 채널은 제공된 사용자 ID로 로드/언로드 시 플랫폼 리소스 라이브러리(314)를 등록 및 등록 해제하는 데 사용될 수 있다. 사용자 ID는 사용자 모드 애플리케이션/드라이버(410)의 상태(예를 들어, 클라이언트 상태)를 추적하고 사용자 모드 애플리케이션/드라이버(410)와의 연결이 종료되는 경우에는 리소스들을 정리하기 위해 서버 플랫폼 리소스 라이브러리(312)에 의해 사용될 수 있다.

추가적으로, 서버 플랫폼 리소스 라이브러리(312)는 플랫폼 레벨 리소스(예를 들어, 정적 능력)의 모든 능력 및 제한 사항을 수집하고, 모으고, 모니터링하고, 검색하고, 능력(예를 들어, 동적 능력)당 플랫폼 리소스의 런타임 사용을 지표를 통해 모니터링하고 유지한다. 서버 플랫폼 리소스 라이브러리(312)는, 예를 들어 비디오, 오디오, 3차원(3D), 및/또는 컴퓨팅 클래스와 같은, 도메인 클래스당 원하는 또는 "선호하는" 플랫폼 리소스(예를 들어, 도메인 클래스당 장치/엔진)의 플랫폼 리소스 추천을 제공한다. 클래스별 정책도 정의하여 사용할 수 있다. 정책은 규칙이 될 수 있으며, 시간이 지남에 따라 변경되거나 조정될 수 있다. 새로운 도메인 클래스, 사용자 작업, 및 작업 부하에 대해 정책 규칙을 확장할 수 있다.

더 설명하기 위해, 도 5a는 본 개시내용의 일부 구현예에 따른 것으로, 오디오 잡음 저감(ANR)을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(500)의 추가 블록선도를 설명한다. 예시적인 시스템(500)은 CPU(106), GPU(104), 오디오 코덱(122), 비디오 코덱(120), GPU 계산 엔진(110), 및 디스플레이 제어기(124)를 통합한 APU(102)를 포함한다. 예시적인 시스템(500)은 비디오 코덱(150), GPU 계산 엔진(140), 및 디스플레이 제어기(154)를 포함하는 dGPU(134)를 포함한다. APU(102)는 GPU/CPU 일관성 메모리(coherent memory)(544) 및 디스플레이(542)를 갖는 시스템 메모리(160)와 통신할 수 있다. dGPU(134)는 로컬 메모리(180) 및 디스플레이(542B)와 통신할 수 있다. 도 1 또는 도 2의 각 컴포넌트는 APU(102) 및 dGPU(134)에 포함될 수 있지만 도 5a에 도시된 것들은 단지 예시의 편의를 위해 사용된 것임을 유의해야 한다. APU(102)는 오디오 입력(546A) 데이터를 수신하고 오디오 데이터를 오디오 출력(546B)으로 출력한다.

예시적인 시스템(500)은 APU(102) 및 dGPU(134)와 통신하는 플랫폼 리소스 라이브러리(312)를 포함한다. 플랫폼 리소스 라이브러리(312)는 예를 들어 APU(102) 및 dGPU(134)와 같은 각 플랫폼 리소스의 정적 및 동적 능력을 수집하고, 모으고, 저장하는 역할을 담당할 수 있다.

작업 시, 예를 들어 가상 오디오 드라이버(510)와 같은 작업 부하 개시자는 예를 들어 오디오 잡음 저감(ANR)을 위한 할당 추천에 대한 요청 정보를 요청하는 것과 같은 플랫폼 리소스 추천 힌트를 요청할 수 있다. 플랫폼 리소스 라이브러리(312)는, 예를 들어 APU(102), dGPU(134), 및 이들의 내부/관련 컴포넌트들(예를 들어, 계산 엔진(110), 디스플레이 제어기(124) 등)과 같은, 모든 플랫폼 리소스의 정적 능력(예를 들어, 리소스 가용성) 및 동적 능력(리소스 점유)을 분석하고 결정한다.

플랫폼 리소스 라이브러리(312)는, 예를 들어 효율성을 최대화하고 전력/성능 비율을 최적화하기 위해 품질 요청별로 어떤 리소스를 사용할지 추천하는 것과 같은, 드라이버(510)로부터 발행된 요청에 대한 특정 세부 사항에 기반하여, 플랫폼 리소스 추천을 제공한다. 작업 부하 개시자(예를 들어, 드라이버(510))는 플랫폼 리소스 라이브러리(312)로부터 수신한 플랫폼 리소스 추천을 이용하여 플랫폼 리소스 추천을 수락하거나 거부할 수 있다. 예를 들어, 작업 부하 개시자(예를 들어, 드라이버(510))가 플랫폼 리소스 추천을 수락한 경우, 작업 부하 개시자(예를 들어, 드라이버(510))는 전력/성능 비율의 최적화 및 효율성을 최대화하기 위해 추천 플랫폼 리소스를 할당한다.

도 5b는 본 개시내용의 일부 구현예에 따른 것으로, 비디오 사전 프로세싱을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(500)의 추가 블록선도를 설명한다.

작업 중에, 예를 들어 카메라(562)에 연결될 수 있는 비디오 캡처 파이프라인 장치 미디어 기반 변환(DMFT: device media foundation transform) 컴포넌트(514)와 같은 작업 부하 개시자는, 예를 들어 비디오 전처리를 위한 할당 추천에 대한 요청 정보에서 문의하는 것과 같은, 플랫폼 리소스 추천 힌트를 요청한다. 플랫폼 리소스 라이브러리(312)는, 예를 들어 APU(102), dGPU(134), 및 이들의 내부/관련 컴포넌트들(예를 들어, 계산 엔진(110), 디스플레이 제어기(124) 등)과 같은, 모든 플랫폼 리소스의 정적 능력(예를 들어, 리소스 가용성) 및 동적 능력(리소스 점유)을 분석하고 결정한다.

예를 들어 비디오 캡처 파이프라인 장치 DMFT 컴포넌트(514)와 같은 작업 부하 개시자는 예를 들어 노이즈 제거, 밝기 수준, 콘트라스트, 및 기타 이미지 향상과 같은 비디오 품질 향상을 위해 컴퓨터 비전 및 기계 학습(CVML: computer vision and machine learning) 소프트웨어 개발 키트(SDK: software development kit)(566)과 링크된다. CVML SDK(566)는 플랫폼 리소스 라이브러리(312)를 로드한다. 플랫폼 리소스 라이브러리(312)는, 예를 들어 APU(102), dGPU(134), 및 이들의 내부/관련 컴포넌트들(예를 들어, 계산 엔진(110), 디스플레이 제어기(124) 등)과 같은, 모든 플랫폼 리소스의 정적 능력(예를 들어, 리소스 가용성) 및 동적 능력(리소스 점유)을 분석하고 결정한다.

플랫폼 리소스 라이브러리(312)는, 예를 들어 효율성을 최대화하고 전력/성능 비율을 최적화하기 위해 품질 요청별로 어떤 리소스를 사용할지 추천하는 것과 같은, 작업 부하 개시자(예를 들어, 비디오 캡처 파이프라인 DMFT 컴포넌트(514))로부터 발행된 요청에 대한 특정 세부 사항에 기반하여, 플랫폼 리소스 추천을 제공한다. 작업 부하 개시자(예를 들어, 비디오 캡처 파이프라인 DMFT 컴포넌트(514))는 플랫폼 리소스 라이브러리(312)로부터 수신한 플랫폼 리소스 추천을 이용하여 플랫폼 리소스 추천을 수락하거나 거부할 수 있다. 예를 들어, 작업 부하 개시자(예를 들어, 비디오 캡처 파이프라인 DMFT 컴포넌트(514))가 플랫폼 리소스 추천을 수락하면, 작업 부하 개시자(예를 들어, 비디오 캡처 파이프라인 DMFT 컴포넌트(514))는 추천 플랫폼 리소스를 할당하여 전력/성능 비율의 최적화 및 효율성을 최대화한다.

도 5c는 본 개시내용의 일부 구현예에 따른 것으로, 비디오 녹화/스트리밍을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(500)의 추가 블록선도를 설명한다.

작업 시, 예를 들어 미디어/비디오 및 이미지를 캡처, 스트리밍, 및 공유하기 위한 게임/게임 플레이 애플리케이션(550) 및 개방형 방송 소프트웨어(OBS: open broadcaster software) 애플리케이션(552)과 같은 작업 부하 개시자는 예를 들어 비디오 전처리를 위한 할당 추천에 대한 요청 정보 조회와 같은 플랫폼 리소스 추천 힌트를 요청한다.

게임/게임 플레이 애플리케이션(550) 및 OBS 애플리케이션(552)은 예를 들어 요청을 인코딩하는 것과 같은 인코딩을 위해 고급 미디어 프레임워크(AMF: advanced media framework)(570)를 열 수 있다. AMF(570)는 플랫폼 리소스 라이브러리(312)를 열 수 있다. 플랫폼 리소스 라이브러리(312)는, 예를 들어 APU(102), dGPU(134), 및 이들의 내부/관련 컴포넌트들(예를 들어, 계산 엔진(110), 디스플레이 제어기(124), 및 비디오 코덱(120, 150) 등)과 같은, 모든 플랫폼 리소스의 정적 능력(예를 들어, 리소스 가용성) 및 동적 능력(리소스 점유)을 분석하고 결정한다.

플랫폼 리소스 라이브러리(312)는, 예를 들어 효율성을 최대화하고 전력/성능 비율을 최적화하기 위해 품질 요청별로 어떤 리소스를 사용할지 추천하는 것과 같은, 작업 부하 개시자(예를 들어, 게임/게임 플레이 애플리케이션(550) 및 OBS 애플리케이션(552))로부터 발행된 요청에 대한 특정 세부 사항에 기반하여, 플랫폼 리소스 추천을 제공한다. 작업 부하 개시자(예를 들어, 게임/게임 플레이 애플리케이션(550) 및 OBS 애플리케이션(552))는 플랫폼 리소스 라이브러리(312)로부터 수신된 플랫폼 리소스 추천을 이용하여 플랫폼 리소스 추천을 수락하거나 거부한다. 예를 들어, 작업 부하 개시자(예를 들어, 게임/게임 플레이 애플리케이션(550) 및 OBS 애플리케이션(552))가 플랫폼 리소스 추천을 수락하는 경우, 작업 부하 개시자(예를 들어, 게임/게임 플레이 애플리케이션(550) 및 OBS 애플리케이션(552))는 전력/성능 비율의 최적화 및 효율성을 최대화하기 위해 추천 플랫폼 리소스를 할당한다.

도 5d는 본 개시내용의 일부 구현예에 따른 것으로, 사후 프로세싱 및 스케일을 위한 플랫폼 리소스 후보를 제공하는 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(500)의 추가 블록선도를 설명한다.

작업 시, 예를 들어 미디어/비디오 및 이미지를 캡처, 스트리밍, 및 공유하기 위한 게임/게임 플레이 애플리케이션(550)과 같은 작업 부하 개시자는 예를 들어 비디오 전처리를 위한 할당 추천에 대한 요청 정보 조회와 같은 플랫폼 리소스 추천 힌트를 요청한다.

예를 들어 게임/게임 플레이 애플리케이션(550)과 같은 작업 부하 개시자는 플랫폼 리소스 라이브러리(312)를 열 수 있다. 플랫폼 리소스 라이브러리(312)는, 예를 들어 APU(102), dGPU(134), 및 이들의 내부/관련 컴포넌트들(예를 들어, 계산 엔진(110), 디스플레이 제어기(124), 및 비디오 코덱(120, 150) 등)과 같은, 모든 플랫폼 리소스의 정적 능력(예를 들어, 리소스 가용성) 및 동적 능력(리소스 점유)을 분석하고 결정한다.

플랫폼 리소스 라이브러리(312),는 예를 들어 업스케일링 및 후처리에 사용할 리소스를 추천하는 것과 같은, 작업 부하 개시자로부터 발행된 요청에 대한 특정 세부 사항에 기반하여 플랫폼 리소스 추천을 제공한다. 작업 부하 개시자(514)는 플랫폼 리소스 라이브러리(312)로부터 수신한 플랫폼 리소스 추천을 이용하여 플랫폼 리소스 추천을 수락하거나 거부한다.

도 5d에 도시된 바와 같이 게임 애플리케이션은 렌더링을 위해 dGPU(134) 또는 APU(102)를 사용할 수 있다는 것을 유의해야 한다. 따라서, 도 5d는 렌더링된 프레임을 추가적인 업스케일/후처리에 대한 애플리케이션 인식 없이 dGPU(134) 또는 APU(102)에서 후처리하는 것을 나타낸다. 그러나, 도 5d는 게임 애플리케이션이 또한 플랫폼 리소스에 대해 질의하고 후처리 작업을 요청할 때에도 적용될 수 있다.

이제 도 6을 참조하면, 본 개시내용의 일부 구현예에 따른 것으로, 업스케일링 작업의 복합 처리를 위한 플랫폼 리소스 추천 서비스(예를 들어, 플랫폼 리소스 무결성 서비스)를 제공하기 위한 예시적인 시스템(600)의 블록선도가 도시되어 있다. 또한, 도 6은 복합 처리에 대한 일반화된 작업이고, 이는 업스케일링 공정에 적용할 수 있다. 즉, 도 6은 본 개시내용의 일부 구현에 따른 것으로, 플랫폼 리소스 추천 서비스를 이용하여 업스케일링 작업을 복합 처리하는 데 적용될 수 있다.

작업 시, 플랫폼 리소스 무결성 서비스(210)는 업스케일링 서비스(예를 들어, "스마트 업스케일링" 서비스)도 제공할 수 있다. 즉, 업스케일링 서비스는 최적의 리소스 접근을 선택하여 업스케일링을 수행한다. 더 구체적으로, 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 APU(102)와 dGPU(134)의 존재 또는 가용성을 정확하게 식별하고, APU(102)와 dGPU(134) 사이에 또는 이들 전체에 걸쳐 래스터화 및 업스케일링 작업 부하를 분산시킨다. 추가적인 양태에서, 플랫폼 리소스 무결성 서비스(210)는 이미지의 배열을 렌더링하고, 업스케일링하고, 스캔하기 위한, APU(102), dGPU(134), 또는 이들의 조합을 할당한다.

추가적인 양태에서, 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 데이터를 업스케일링하기 위해 하나 이상의 GPU 및 하나 이상의 APU를 동적으로 식별한다. 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 적어도 업스케일링 작업의 방식에 기반하여 업스케일링 작업의 작업 부하를 APU(102), dGPU(134), 또는 이들의 조합에 동적으로 할당한다. 일 양태에서, 업스케일링 작업의 방식은 최근접 이웃 보간, 쌍선형(기본 보간), 및 쌍삼차 알고리즘(복소 보간)을 포함하지만 이에 국한되지 않는다. 각 방식은 상이한 업스케일링 작업을 구성하며, 유사한 이미지를 다르게 처리한다. 업스케일링 작업의 작업 부하는 APU(102), dGPU(134), 또는 이들의 조합에 의해 작업 부하의 동적 할당에 기반하여 처리될 수 있다. 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 사용자 기본설정, APU(102), dGPU(134), 또는 이들의 조합의 플랫폼 능력에 기반하여 업스케일링 작업의 작업 부하를 동적으로 할당한다.

추가적인 양태에서, 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 사용자 기본설정, APU(102), dGPU(134), 또는 이들의 조합의 플랫폼 능력에 의해 업스케일링 작업의 방식을 동적으로 선택한다.

예를 들어, 업스케일링 서비스가 레이 트레이싱으로 완전한 풀 프레임 렌더링을 수행하기 위해 dGPU(134)의 처리 사이클을 보존하거나 저장하려고 시도한다고 가정해 보자. 이를 위해, dGPU(134)는 더 낮은 공간 단위에서 렌더링한다. 플랫폼 리소스 무결성 서비스(210)는 업스케일링 서비스를 사용하여, APU(102)에 할당하고, APU(102)는 예를 들어 가장자리 강화와 같은 필터링을 사용하여 저해상도 렌더링을 다시 고해상도로 복원한다. 따라서, 플랫폼 리소스 무결성 서비스(210)가 제공하는 업스케일링 서비스는 사용자 기본설정 및 플랫폼 능력에 기반하여 적절한 업스케일링 알고리즘을 선택함으로써 업스케일링에 대한 유연성을 제공한다.

일 양태에서, 사용자 기본설정은 업스케일링 방식(예를 들어, 업스케일링 작업의 모드 또는 유형), 값, 임계값, 능력, 활용도 지표를 정의하는 것을 포함하지만 이에 국한되지 않는다. 사용자 기본설정은 다양한 유형의 헤드룸 편향, 전력 편향, 품질 편향, 속도 편향을 포함한다. 예를 들어, 사용자 기본설정은 1) 헤드룸 편향의 경우, APU(102)를 정의된 활용도 임계값 미만(예를 들어, 60% 미만)으로 제한하는 최고 품질의 업스케일러 방식을 사용하는 것, 2) 전력 편향의 경우, 기준 업스케일러 방식을 사용하는 것, 3) 품질 편향의 경우, APU(102)에 의해 지원되는 최고 품질의 업스케일러 방식을 정의된 활용도 임계값(예를 들어, APU(102)에 의한 최소 80% 활용도 용량)까지 사용하는 것, 또는 4) 속도 편향을 위해 기준 업스케일러 방식을 사용하는 것을 포함할 수 있다.

업스케일러 방식 품질의 경우, 업스케일러 방식은 순위가 매겨진 품질 수준 또는 선호하는 품질 수준에 기반할 수 있다. 예를 들어, 제공되는 품질에 기반하여 업스케일러 방식의 순위를 매기고 선택하거나 배열할 수 있다. 업스케일러 방식은, 예를 들어, 1) 출력 해상도에 대한 시간 기반 초해상도, 2) 출력 해상도에 가까운 시간 기반 초해상도(즉, 디스플레이 제어기에서 각 방향을 1.3배 미만으로 업스케일링), 3) 출력 해상도에 대한 공간 전용 인식 기반 업스케일링, 4) 출력 해상도에 가까운 공간 전용 인식 기반 업스케일링, 5) 입력 해상도에 대한 개선된 RCAS 및 출력 해상도에 가까운 오버슈트/언더슈트 필터를 사용한 알고리즘을 포함한다. 입력 해상도에 대한 RCAS 및 출력 해상도에 가까운 오버슈트/언더슈트 필터를 사용한 알고리즘.

따라서, 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 dGPU(134), APU(102), 또는 dGPU(134)와 APU(102) 모두에서 렌더링 작업을 선택한다. 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 dGPU(134), APU(102), 또는 dGPU(134)와 APU(102) 모두에서 업스케일링 작업을 선택한다. 플랫폼 리소스 무결성 서비스(210)에 의해 제공되는 업스케일링 서비스는 dGPU(134), APU(102), 또는 dGPU(134)와 APU(102) 모두에서 디스플레이 작업을 선택한다. 예를 들어, 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)에서의 렌더링, APU(102)에서의 업스케일링, 및 APU(102)의 디스플레이 제어기(124)를 사용하여 디스플레이하는 것을 선택한다. 대안적으로, 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)에서의 렌더링, APU(102)에서의 업스케일링, 및 dGPU(134)의 디스플레이 제어기(154)를 사용하여 디스플레이하는 것을 선택한다. 다른 양태에서, 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)에서의 렌더링, dGPU(134)에서의 업스케일링, 및 dGPU(134)의 디스플레이 제어기(154)를 사용하여 디스플레이하는 것을 선택한다. 추가 양태에서, 플랫폼 리소스 무결성 서비스(210)는 APU(102)에서의 렌더링, APU(102)에서의 업스케일링, APU(102)의 디스플레이 제어기(124)를 사용하여 디스플레이하는 것을 선택한다.

더 자세히 설명하기 위해, 하기의 예시적 작업들을 고려한다. 예비적으로, 각 예에서, 플랫폼 리소스 무결성 서비스(210)는 플랫폼 구성 요소(240)를 사용하여 정적 및 동적 플랫폼 리소스 확인(예를 들어, 능력 분석)을 수행한다. 스마트 시프트(242)는, 예를 들어 APU(102) 및 dGPU(134)와 같은 플랫폼 리소스의 능력과 관련된 전력, 성능, 발열, 및 정책을 플랫폼 리소스 무결성 서비스(210)에 제공한다.

제1 예에서, 플랫폼 리소스 무결성 서비스(210)가 렌더링 작업을 수행하기 위해 dGPU(134)를 선택하고 게임 애플리케이션(예를 들어, 이미지 디스플레이)을 디스플레이하기 위해 APU(102)를 선택한다고 가정한다. 일 양태에서, 플랫폼 리소스 무결성 서비스(210)는 사용자 기본설정이 프레임 속도 및 레이 트레이싱을 최대화하기를 원하거나 의도하는 경우 이러한 선택을 한다. 그러나 공간 해상도가 낮은 경우에는 레이 트레이싱이 프레임 속도에 부정적인 영향을 미칠 수 있다. 따라서, 프레임을 사용한 레이 트레이싱은 공간 해상도를 희생하면서 더 높은 프레임 속도를 달성하는 절충적 결과를 가져온다. 따라서, 이 예에서, 사용자는 프레임 속도를 최대화하기 위해(예를 들어, 가장 높은 프레임 속도를 달성하기 위해) 선택하는 기본설정을 나타내지만 이러한 선택은 공간 해상도의 품질을 저하시키는 결과를 가져온다.

이 시나리오에서, 플랫폼 리소스 무결성 서비스(210)는 공간 해상도를 복원하기 위해 APU(102)를 선택한다. 이러한 방식으로, 플랫폼 리소스 무결성 서비스(210)는 사용자 기본설정에 기반하여 어떤 플랫폼 리소스를 사용할 것인지를 결정한다. 예를 들어, 플랫폼 리소스 무결성 서비스(210)는 사용자가 이미지 세부 사항을 손상시키는 더 높은 프레임 속도에 대한 기본설정을 나타내는 것을 학습하거나 결정할 수 있거나, 또는 사용자가 예를 들어 고해상도 비디오(예를 들어, "4K" 비디오)와 같은 최대의 상세에 대한 기본설정을 나타내며 사용자가 차선의 프레임 속도에 만족하거나 레이 트레이싱에 대한 기본설정을 갖지 않음을 학습하거나 결정할 수 있다. 일 양태에서, 작업 부하 요청은 사용자 기본설정을 제공하는 반면, 기계 학습 작업은 이력 데이터에 기반하여 사용자 행동을 학습하도록 플랫폼 리소스 무결성 서비스(210)에 의해 수행될 수 있다.

따라서, 이 예에서, 디스플레이(542B)의 현재 디스플레이 설정보다 낮은 해상도로 dGPU(134)에서 게임이 실행(예를 들어, 플레이)된다. 이 시나리오에서는 렌더링된 이미지가 업스케일링 및 후처리를 위해 처리된다. 일 양태에서, 후처리는 이미지의 선명화, 색상 등급 조정, 또는 dGPU(134)가 렌더링을 마친 후에 필요한 임의의 다른 처리 작업일 수 있다. dGPU(134) 상의 GPU 계산 엔진(140)은 예를 들어 시간적 재구성 슈퍼 샘플링(TRSS: temporal reconstruction super-sampling)과 같은 선택된 업스케일링 작업을 수행할 수 있다.

다시 말하면, 작업 시, 플레이된 게임은 dGPU(134)에서 렌더링되고, 그런 다음 다른 업스케일링 작업 부하가 예를 들어 디스플레이 제어기(124)를 사용하여 디스플레이를 위해 APU(102)로 전달/전송된다. 플랫폼 리소스 무결성 서비스(210)의 지시에 따라 APU(102)는 고급 업스케일링 작업, 기계 학습 추론 기반 업스케일링, 또는 셰이더 업스케일링(APU(102) 능력 및 사용자 기본설정에 기반하여)을 APU(102)에 의해 수행되는 후처리와 함께 제공한다. 일 양태에서, 후처리를 위한 APU(102)는 이미지가 더 낮은 해상도에서 렌더링되었기 때문에 이미지 선명화를 수행할 수 있다. 그런 다음 이미지는 예를 들어 APU의 디스플레이 제어기(124)를 사용하여 디스플레이 파이프(예를 들어 "DCN" 스케일 다음의 디스플레이 코어)에서 선명해지고 업스케일링된다.

제2 예에서, dGPU(134)가 고전력이고 낮은 대기 시간 출력을 제공한다고 가정한다. 이 시나리오에서, 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)를 선택하여 전체 프레임 속도 게임 플레이를 실행하고 (선택적으로) dGPU(134)에 출력하거나 하이브리드 그래픽 상황에서 APU(102)에 출력한다.

제3 예에서, 사용자 기본설정은 예를 들어 고급 기계 학습 추론 기반 업스케일링과 같은 기본 업스케일러를 사용하는 대신 고급 업스케일러를 사용하는 것이라고 가정한다. dGPU(134)가 고급 기계 학습 추론 기반 업스케일링을 실행하는 능력이 부족한 경우, 플랫폼 리소스 무결성 서비스(210)는 이제는 고급 기계 학습 추론 기반 업스케일링의 전문화된 방식으로 업스케일링할 APU(102) - 여기서, APU(102)는 추론 프로세서 유닛(예를 들어, 도시되지 않은 기계 학습 컴포넌트)을 포함함 - 를 선택하고, 셰이더의 전체 보완을 사용하여 업스케일링을 수행하거나 추론 처리 유닛을 기반으로 업스케일링을 수행하여 더 우수하거나 증가된 업스케일링 결과를 얻을 수 있다. 따라서, 이 제3 예에서, 게임은 dGPU(134)에서 플레이될 수 있고, APU(102)는 기계 학습 추론 업스케일러를 수행하고, 그런 다음 이미지의 추가 선명화와 함께 APU(102)에서 후처리도 발생할 수 있다. 이런 방식으로, APU(102)는 업스케일링을 위한 기계 학습을 사용하고, 그런 다음 추가 후처리를 위한 셰이더(예를 들어, APU(102) 상의 GPU 계산 엔진(110))를 사용한다.

제4 예에서, 사용자 기본설정은 예를 들어 게임을 최저 전력으로 플레이하는 것과 같이 애플리케이션을 실행하는 것이라고 가정한다. 플랫폼 리소스 무결성 서비스(210)는 dGPU(134)를 완전히 무시하면서 APU(102)에서 게임을 플레이하고 APU(102)에서 출력하도록 선택할 수 있다. 따라서, 이 예는 플랫폼 리소스 추천을 위해 본원에 설명된 작업이 스마트 업스케일러와 함께 작동할 수 있는 방법을 예시한다. 예를 들어, 플랫폼 리소스 무결성 서비스(210)는 배터리 부족에 기반하여 플랫폼 리소스를 전환하라는 추천을 제공하고, 게임을 계속 플레이하기 위해 모든 작업을 dGPU(134)에서 APU(102)로 이동하고 dGPU(134)를 무시하라고 힌트를 주거나 제안한다.

요약하면, 플랫폼 리소스 무결성 서비스(210)는 각 플랫폼의 플랫폼 능력을 식별한다. 그런 다음, 플랫폼 리소스 무결성 서비스(210)는 스마트 업스케일링을 이용하여, 작업 조건에 기반하여 업스케일링의 방식(예를 들어, 업스케일링을 어떻게 수행할지)을 결정할 수 있다. 즉, 플랫폼 리소스 무결성 서비스(210)는 APU(102) 및 dGPU(134)의 사용자 기본설정 및 플랫폼 능력에 기반하여 어떤 플랫폼 리소스가 업스케일링을 수행할지를 이해하고 결정한다. 예를 들어, dGPU(134)가 특정 업스케일 비율로 조정되면, 플랫폼 리소스 무결성 서비스(210)는 사용자가 예를 들어 종횡비를 변경하고자 하는 기본설정을 표시하는 경우, 또는 다른 축척 비율을 사용하고 싶다는 기본설정을 표시하는 경우, 또는 예를 들어 링잉이나 앨리어싱된 선과 같은 업스케일링의 일부 결과를 상쇄하여 셰이더를 사용하여 후처리를 하고 싶어하는 기본설정을 표시하는 경우, 어떤 다른 플랫폼 리소스(있는 경우)가 선택되어 사용될 수 있는지를 결정할 수 있다. 이러한 방식으로, 플랫폼 리소스 무결성 서비스(210)는 적어도 업스케일링 작업의 방식, 플랫폼 능력, 및 사용자 기본설정에 기반하여 업스케일링 작업의 업스케일링 작업 부하를 APU(102), dGPU(134), 또는 이들 둘 다에 동적으로 할당할 수 있다. 그러면 APU(102), dGPU(134), 또는 이들 둘 다는 작업 부하를 동적으로 할당하는 것에 기반하여 업스케일링 작업의 작업 부하를 처리할 수 있다.

더 설명하기 위해, 도 7은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 예시적인 방법을 예시하는 흐름도를 설명한다. 도 7의 예시적인 방법은 작업 부하 개시자로부터 플랫폼 리소스 추천에 대한 요청을 수신하는 단계(710)를 포함한다. 일부 예에서, 요청은 작업 부하를 실행할 수 있는 처리 리소스 중에서 어느 처리 리소스에 작업 부하를 배치해야 하는지를 나타내는 정보에 대한 것일 수 있다. 예를 들어, 작업 부하가 비디오 처리 또는 그래픽 처리 작업을 포함하는 경우, 작업 부하를 실행하는 컴퓨팅 시스템(예를 들어, 도 1의 시스템(100))은 작업 부하를 실행할 수 있는 다수의 GPU를 포함한다. 특정 예에서, 컴퓨팅 시스템은 통합 GPU(예를 들어, 도 1의 통합 GPU(104)) 및 개별 GPU(예를 들어, 도 1의 dGPU(134))를 포함한다. 이러한 예에서, 작업 부하 개시자로부터의 요청은 작업 부하가 통합 GPU나 개별 GPU, 또는 이들의 조합에 배치되어야 하는 추천이나 "힌트"를 플랫폼 리소스 무결성 서비스(210)에 질의하는 것이다. 일부 경우에서, 작업 부하는 통합 GPU에서 실행될 수 있는 작업 항목과, 개별 GPU에서 동시에 실행될 수 있는 기타 작업 항목을 포함한다.

다양한 유형의 애플리케이션이, 각각 다양한 유형의 작업 부하를 갖는 작업 부하 개시자가 될 수 있다. 일부 예에서, 작업 부하 개시자의 요청은 작업 부하 유형, 작업 부하 특징, 처리 요건, 및/또는 작업 부하에 대한 성능 기대치를 설명한다. 예를 들어, 미디어 플레이어 애플리케이션에는 컴퓨팅 시스템에서 실행하려는 미디어 재생 작업 부하가 있을 수 있다. 이러한 예에서, 작업 부하의 설명에는 재생 작업 부하에 대한 소스 해상도, 디스플레이 해상도, 비트 전송률, 비디오 코덱, 오디오 코덱, 및 프레임 속도가 포함된다. 또 다른 예로, 화상 회의 애플리케이션에는 컴퓨팅 시스템을 실행하려는 트랜스코드 작업 부하가 있을 수 있다. 이러한 예에서, 작업 부하 설명에는 소스 비디오 코덱, 타겟 비디오 코덱, 및 프레임 속도가 포함된다. 화상 회의 애플리케이션은 스크린 상의 참가자의 배경을 제거/대체하거나 또는 시선을 교정하기 위한 인공 지능(AI) 알고리즘을 포함하는 인공 지능(AI) 작업 부하도 포함할 수 있다.

도 7의 예시적인 방법은 또한 복수의 플랫폼 리소스의 요청과 성능 능력과 활용도 지표에 기반하여 하나 이상의 플랫폼 리소스 후보를 식별하는 단계(720)를 포함한다. 플랫폼 리소스는 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 일부 예에서, 하나 이상의 플랫폼 리소스 후보를 식별하는 단계(720)는, 통합 GPU 계산 엔진(예를 들어, 도 1의 통합 GPU 계산 엔진(110)) 및 개별 GPU 계산 엔진(예를 들어, 도 1의 개별 GPU 계산 엔진(140))의 능력 및 활용도 지표를 포함하여 APU 및 dGPU의 런타임 활용 지표와 함께 정적 및 동적 능력을 수집함으로써, 실행된다.

APU 및 dGPU의 능력은 당업자가 인식할 수 있는 다양한 방식으로 표현될 수 있다. 예를 들어, 플랫폼 능력에는 처리 속도, 전력 상태, 엔진 활용도, 메모리 컨트롤러/PCIe 활용도 및 능력, 전력 제한 사항 또는 제약, 업스케일링 능력 및 제한 사항, 렌더링 능력 및 제한 사항, 디스플레이 능력 및 제한 사항이 포함된다. 플랫폼 능력에는 비디오 향상 능력과, 영상/원격 전화 회의 또는 스트리밍을 위한 인공 지능(AI) 기능이 포함될 수 있다. 플랫폼 능력에는 예를 들어 업스케일링, 렌더링, 디스플레이와 같은 작업 부하 또는 애플리케이션의 다양한 유형의 방식을 실행하는 능력이 포함된다. 플랫폼 능력에는 예를 들어 최저 전력 소비로 게임 애플리케이션을 실행하는 것과 같은 배터리 부족 모드에서 작업 부하를 처리하는 능력이 포함된다.

일부 예에서, 하나 이상의 플랫폼 리소스 후보를 식별하는 단계(720)는 하나의 프로세서 리소스가 다른 프로세서 리소스보다 작업을 더 잘 수행하는 플랫폼 리소스 능력에 대한 성능 인자에 기반하여 실행된다. 한 예에서, 플랫폼 리소스 무결성 서비스(210)는 게임 작업 부하가 개별 GPU의 초과 구독을 초래할 것으로 예측되지 않는 한 게임 작업 부하를 개별 GPU에 배치해야 한다고 결정한다. 다른 양태에서, 플랫폼 리소스 무결성 서비스(210)는 비디오 재생이 오디오 코덱(122)을 사용하여 수행되어야 한다고 결정한다. 이는 GPU들 중 하나에 오디오 코덱(122) 가속기가 포함되고 나머지 다른 것에는 포함되어 있지 않은 경우일 수 있다.

APU 및 dGPU의 활용도는 당업자가 인식할 수 있는 다양한 방식으로 표현될 수 있다. 예를 들어, APU 및 dGPU의 활용도 지표에는 바쁜 시간에 대한 유휴 시간의 비율, 활성 프로세스의 수, 활성 스레드의 수, 전력 소비, 또는 이들의 조합으로서의 프로세서 활용도가 포함된다. 통합 GPU와 개별 GPU에는 이러한 지표를 제공하기 위한 다양한 카운터들이 포함되어 있다.

도 7의 예시적인 방법은 또한 식별된 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하는 단계(730)를 포함한다. 일부 예에서, 식별된 플랫폼 리소스 후보를 작업 부하 개시자에게 동적으로 제공하는 단계(730)는 식별된 플랫폼 리소스 후보를 포함하는 통지를 작업 부하 개시자에게 보내는 플랫폼 리소스 무결성 서비스(210)에 의해 수행된다.

추가적인 예에서, 플랫폼 리소스 추천은 복수의 플랫폼 리소스 중 적어도 2개가 작업 부하를 실행하는 데 이용 가능할 때 작업 부하를 실행하기 위해 복수의 플랫폼 리소스 중 적어도 하나를 선택하라는 추천을 포함한다. 예를 들어, 추천 또는 리소스 힌트는 어떤 플랫폼 리소스(예를 들어, GPU, APU 등)에 작업 부하를 적용할지에 대한 힌트 또는 추천을 포함하며, 다수의 옵션을 사용할 수 있는 경우에 어떤 플랫폼 리소스를 사용할지에 대한 추천/리소스 힌트를 제공할 수도 있다.

더 설명하기 위해, 도 8은 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다. 도 8의 방법은 플랫폼 리소스 라이브러리에서 각 플랫폼 리소스에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한(참조의 편의를 위해 총칭하여 '파라미터' 또는 '지표'라고 함)을 수집하는 단계(810)도 포함한다는 것을 제외하면, 도 8의 방법은 도 7의 방법과 유사하다. 이러한 파라미터를 수집하는 단계(810)는 작업 부하 시작 시 또는 시스템 부팅 시 초기 '검색' 작업으로 실행된다. 파라미터를 수집하는 단계는 플랫폼의 하드웨어 리소스에 대한 정보를 수집하는 단계를 포함할 수 있다.

운영 체제 부팅 시 또는 애플리케이션 최초 실행 시, 플랫폼 리소스 라이브러리(312)는 플랫폼 리소스 검색 작업을 실행하여 이용 가능한 모든 플랫폼 정보를 결정한다. 그런 다음 플랫폼 리소스 라이브러리(312)는 시스템(300)의 완전한 정적 플랫폼 리소스 능력 목록을 구축하기 위해 리소스 플랫폼 레코드(위에서 340으로 설명됨)에 대해 검색 데이터를 교차 확인한다. 정적 플랫폼 리소스 능력 목록은 플랫폼 리소스 라이브러리(312)에 의해 액세스될 수 있는 방식으로 저장될 수 있다. 대조적으로, 동적 작업(예를 들어, 현재 시스템(300) 상태, 부하, 및 GPU 엔진별 사용을 결정하기 위한 작업)의 경우, 플랫폼 리소스 라이브러리(312)는 현재 플랫폼 리소스 지표 또는 파라미터를 수집하고, 모으고, 처리하고, 저장하고, 모니터링한다. 플랫폼 리소스 활용도 지표는 또한 사용 가능한 동적 부하 범위에서 각 플랫폼 리소스(예를 들어, 각 엔진/코어) 부하에 대해서 수집될 수도 있다. 이러한 동적 부하 범위는 플랫폼 리소스 능력이나 제한 사항에 따라 달라질 수 있다. 이러한 능력이나 제한 사항은 작동 모드 유형, 메모리 대역폭에 따른 제한 사항, 또는 시스템 상호 연결 부하로 인한 것일 수 있다.

도 8의 방법은 또한 작업 부하의 런타임 동안 복수의 플랫폼 리소스 각각에 대한 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한을 모니터링하는 단계(820)를 포함한다. 즉, 초기 검색 프로세스 후와 리소스 활용도 지표에 대한 기준선 설정 후에, 시스템은 리소스의 실시간 활용도와 능력으로 지표를 모니터링하고 업데이트할 수 있다. 모니터링의 일부로서, 플랫폼 리소스 무결성 서비스(210)는 시스템 또는 드라이버 이벤트들의 목록에 지정된 다양한 이벤트를 모니터링하고 청취하는 플랫폼 상태 변경 리스너(327)를 활용할 수 있다. 이벤트들의 목록은 시간이 지남에 따라 증가하고 늘어날 수 있다. 일 양태에서, 플랫폼 상태 변경 리스너(327)는 플랫폼 리소스 라이브러리(312)에 항상 등록되어야 하는 다양한 필수 이벤트를 모니터링하고 청취한다. 이러한 필수 이벤트에는 예를 들어 교류/직류(AC/DC) 전환 이벤트, 플랫폼 리소스의 추가 또는 제거, 전원(예를 들어, 배터리/성능 슬라이더)을 통한 사용자 요청에 기반한 전력 한계 변경, 또는 제어판 설정 변경이 포함된다. 제어판 설정 변경에는 예를 들어 AC 및 DC 모드 변경이 포함될 수 있다. 이러한 모니터링된 이벤트는 플랫폼 리소스 무결성 서비스(210)에 실시간 데이터를 제공하고, 플랫폼 리소스 후보의 식별(720)을 더 잘 알릴 수 있다.

또한, 도 8의 방법에서, 플랫폼 리소스 후보를 식별하는 단계(720)에는, 작업 부하 개시자로부터의 플랫폼 리소스 추천에 대한 요청에 기반하여 복수의 플랫폼 리소스 각각에 대해 검색할 수 없는 성능 능력, 성능 제한, 및 이력 성능 데이터를 결정하기 위해 플랫폼 리소스 라이브러리에서 찾는 단계(830)가 포함된다. 플랫폼 리소스 무결성 서비스(210)는 예를 들어 레코드(340)와 같은 레코드들의 세트를 포함하는 플랫폼 리소스 라이브러리(312)를 배포한다. 레코드(340)는 플랫폼 리소스 능력(운영 체제가 검색할 수 없는 능력 포함), 제한 사항, 성능 지표, 및 이력 데이터의 전체 목록을 포함하는 포괄적인 리소스 플랫폼 데이터세트를 갖춘 리소스 플랫폼 레코드일 수 있다. 레코드(340)는 플랫폼 리소스 라이브러리(312)에 의해 읽기 전용으로 사용될 수 있다. 레코드(340)는 OEM 및 플랫폼 보충 정보로부터 플랫폼 리소스 라이브러리(312)에 제공될 수 있다.

플랫폼 리소스 라이브러리에서 찾는 단계(830) 후에, 도 8의 방법은 복수의 플랫폼 리소스의 비성능 능력 및 성능 제한에 기반하여 플랫폼 리소스 후보를 식별하는 단계(840)로 계속 이어진다. 즉, 성능 능력 외에도 리소스 후보 식별은 또한 성능 제한뿐만 아니라 비성능 능력에 의존할 수도 있다.

더 설명하기 위해, 도 9는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 후보를 작업 부하 개시자에게 제공하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다. 도 9의 방법은 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 각각의 순위를 매기는 단계(910)를 포함한다는 것을 제외하고는 도 9의 방법은 도 7의 방법과 유사하다. 일부 예에서, 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한에 기반하여 복수의 플랫폼 리소스 각각의 순위를 매기는 단계(910)는 1) APU(102) 또는 dGPU가 허용하는 최대 플랫폼 용량 내에서 가능한 최대 프레임 속도 및/또는 최고 품질, 2) 메모리 대역폭, 3) 컴퓨팅 대역폭, 4) 다양한 유형의 사용 사례에 대해 실시간으로 프레임 속도를 유지하는 능력 또는 용량, 5) 예를 들어 최저 전력 옵션 또는 최고 성능 옵션을 기반으로 작업 부하를 수행하는 능력, APU(102) 또는 dGPU 사이의 메모리 전송을 최소화하는 용량과 같은, 에너지를 보존하는 용량 및 능력, 및 6) 메모리 공간을 최소화하는 능력이 전해지도록 플랫폼 리소스 무결성 서비스(210)에 의해 APU(102) 또는 dGPU의 능력에 기반하여 성능 능력, 활용도 지표, 검색 불가능한 성능 능력, 및 성능 제한의 순위를 매김으로써 실행된다. 사용자 기본설정은 능력에 순위를 매기는 데에도 사용될 수 있다는 점에 유의해야 한다.

시스템 운영 중에 리소스 활용도와 능력이 변경된다. 이를 위해, 도 10은 본 개시내용의 구현예에 따른 것으로, 런타임 동안 플랫폼 리소스 후보를 업데이트하는 예시적인 방법을 예시하는 흐름도를 설명한다. 도 10의 방법은 작업 부하의 런타임 동안, 업데이트된 플랫폼 리소스 후보를 복수의 플랫폼 리소스의 조정된 성능 능력 및 조정된 활용도 지표에 기반하여 동적으로 제공하는 단계(1010)도 포함한다는 것을 제외하고는 도 10의 방법은 도 7과 유사하다. 일부 예에서, 업데이트된 플랫폼 리소스 후보를 동적으로 제공하는 단계(1010)는 플랫폼 리소스를 재할당하기 위해 작업 부하 개시자에게 업데이트된 추천을 제공함으로써 실행된다. 예를 들어, 이전에 제공된 리소스 후보 세트에 제공된 플랫폼 리소스에 변경이 감지된 때, 감지된 변경에 기반하여 플랫폼 리소스 후보가 재식별되고, 업데이트된 리소스 후보 추천이 작업 부하 개시자에 제공될 수 있다. 이러한 변경에는 예를 들어 성능 변경, 활성 프로세스의 수, 활성 스레드의 수, 전력 소비의 손실 또는 이득, 또는 이들의 조합이 포함될 수 있다.

더 설명하기 위해, 도 11는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 이용하여 렌더링된 프레임의 업스케일링 작업을 복합 처리하는 예시적인 방법을 예시하는 흐름도를 설명한다. 본원에 기술된 바와 같이 스케일링 작업 또는 "업스케일링"은 예를 들어 프레임이 최종 사용자에게 제시되는 것보다 더 높은 해상도로 렌더링되는 경우와 같은 다운스케일링을 포함할 수도 있다는 점을 유의해야 한다. 따라서, 일반적으로, 스케일링 작업은 또한, 스케일링 없이, 스케일 작업과 함께, 또는 스케일링 없이 독립적으로, 크로스 디바이스 방식으로 이미지를 처리하는 것(예를 들어, 이미지 선명화)을 포함할 수도 있다.

도 11의 예시적인 방법은 (렌더링된 프레임의) 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스를 식별하는 단계(1110)를 포함하며, 여기서 리소스는 (적어도) 하나 이상의 GPU 및 하나 이상의 APU를 포함한다. 일부 예에서, 데이터를 업스케일하기 위한 dGPU(134) 및 APU(102)의 가용성을 동적으로 식별함으로써 업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스를 식별하는 단계(1110).

도 11의 예시적인 방법은 또한 적어도 업스케일링 작업의 방식에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계(1120)를 포함한다. 일부 예에서, 플랫폼 리소스들 중 하나 이상에 작업 부하를 동적으로 할당하는 단계(1120)는 래스터화 및 업스케일링 작업 부하를 APU와 dGPU 사이에서 분산시키는 플랫폼 리소스 무결성 서비스(210)에 의해 실행된다. 즉, 플랫폼 리소스 무결성 서비스(210)는 통합 GPU 계산 엔진(예를 들어, 도 1의 통합 GPU 계산 엔진(110)) 및 개별 GPU 계산 엔진(예를 들어, 도 1의 개별 GPU 계산 엔진(140))의 능력 및 활용도 지표에 기반하여 래스터화 및 업스케일링 작업 부하를 APU와 dGPU 사이에서 분산시킬 수 있다.

도 11의 예시적인 방법은 또한 작업 부하를 동적으로 할당하는 것에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 의해 업스케일링 작업의 작업 부하를 처리하는 단계(1130)를 포함한다. 일부 예에서, 작업 부하를 동적으로 할당하는 것에 기반하여 복수의 플랫폼 리소스 중 하나 이상에 의해 업스케일링 작업의 작업 부하를 처리하는 단계(1130)는 업스케일링 작업이 APU(102), dGPU(134), 또는 이들 둘 다에 할당된다는 것을 특정 플랫폼 리소스에 표시함으로써 실행된다. APU(102), dGPU(134), 또는 이들 둘 다는 표시에 기반하여 프로세스를 실행할 수 있다.

더 설명하기 위해, 도 12는 본 개시내용의 일부 구현예에 따른 것으로, 플랫폼 리소스 추천 서비스를 이용하여 렌더링된 프레임의 업스케일링 작업을 복합 처리하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다. 도 12의 방법은 업스케일링 작업을 수행하는 데 이용할 수 있는 플랫폼 리소스를 식별하는 단계(1110)의 대안적인 구현예를 설명하고 있다는 것을 제외하고는, 도 12의 방법은 도 11의 방법과 유사하다. 한 구현예에서, 상기 방법은 사용자 기본설정에 기반하여 업스케일링 작업의 방식을 선택하는 단계(1210)를 포함한다. 일부 예에서, 사용자 기본설정에 기반하여 업스케일링 작업의 방식을 선택하는 단계(1210)는 업스케일링에 대한 사용자 기본설정을 식별하거나 학습(기계 학습 동작을 통해)하고 업스케일링 작업의 방식을 선택함으로써 실행된다. 예를 들어, 업스케일링 작업의 방식은 사용자 기본설정이나 학습된 사용자 프로파일에 기반하여 최근접 이웃 보간, 쌍선형(기본 보간), 및 쌍삼차 알고리즘(복소 보간)이 될 수 있다.

다른 구현예에서, 업스케일링 작업을 수행하는 데 이용 가능한 플랫폼 리소스를 식별하는 단계(1110)는 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 방식을 선택하는 단계(1220)를 포함한다. 일부 예에서, 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반하여 업스케일링 작업의 방식을 선택하는 단계(1210)는 업스케일링하기 위한 복수의 플랫폼 리소스 중 하나 이상의 성능 능력을 식별하거나 학습(기계 학습 작업을 통해)하고 업스케일링 작업의 방식을 선택함으로써 실행된다.

플랫폼 리소스의 식별(1110)이 다양한 방식으로 수행될 수 있는 것처럼 작업 부하의 할당도 마찬가지이다. 이를 위해, 도 13은 본 개시내용의 일부 구현예에 따른 것으로, 작업 부하 할당이 다양한 방식으로 수행되는, 업스케일링 작업을 복합 처리하는 또 다른 예시적인 방법을 예시하는 흐름도를 설명한다. 더 구체적으로, 도 13의 예시적인 방법은 사용자 기본설정에 기반하여 작업 부하는 동적으로 할당하는 단계(1310) 및 복수의 플랫폼 리소스의 성능 능력에 기반하여 작업 부하를 동적으로 할당하는 단계(1320)를 포함한다.

일부 예에서, (렌더링된 프레임의) 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계(1310)는 APU(102), dGPU(134), 또는 이들 둘 다에서의 렌더링 작업, 업스케일링 작업, 및 디스플레이 작업을 사용자 기본설정에 따라 선택함으로써 실행된다. 예를 들어, 최저 전력에서 게임 애플리케이션의 실행을 지정하는 사용자 기본설정의 경우, 플랫폼 리소스 무결성 서비스(210)는 APU(102)에서 모든 작업을 실행하라는 추천을 제공하고, 저전력 모드에 있는 동안 게임을 계속 플레이하기 위해 dGPU(143)를 무시한다. 다른 예에서, 사용자 기본설정이 레이 트레이싱으로 프레임 속도를 최대화하는 것이라면, 플랫폼 리소스 무결성 서비스(210)는 낮은 해상도를 복원하여 다시 고해상도로 렌더링하는 작업 흐름 작업을 APU(102)에 할당함과 동시에 이미지를 더 낮은 공간 단위에서 렌더링하기 위해 dGPU(134)를 활용할 수 있다. 이러한 복원에는 사용자 기본설정 및 플랫폼 능력에 기반하여 적절한 업스케일링 알고리즘을 선택하여 업스케일링에 유연성을 제공하기 위한 가장자리 향상과 같은 필터링이 포함될 수 있다.

도 17의 예시적인 방법은 플랫폼 리소스의 성능 능력에 기반하여 작업 부하를 동적으로 할당하는 단계(1320)도 포함한다. 일부 예에서, 플랫폼 리소스의 성능 능력에 기반하여 작업 부하를 할당하는 단계(1320)는 APU(102), dGPU(134), 또는 이들 둘 다에서의 렌더링 작업, 업스케일링 작업, 및 디스플레이 작업을 APU(102) 및 dGPU(134)의 플랫폼 능력에 따라 선택함으로써 실행된다. 예를 들어, APU(102), dGPU(134), 또는 이들 둘 다는 리소스 또는 리소스들에 할당된 작업 부하가 리소스의 초과 구독을 초래하지 않는다는 것을 하나 이상의 정책에 기반하여 결정함으로써 래스터화 또는 업스케일링을 수행하도록 선택될 수 있다. 한 예로, 어떤 정책은 APU(102), dGPU(134), 또는 이들 둘 다가 초과 구독되지 않는 한 렌더링 및 디스플레이가 추가된 작업 부하로 APU에 할당될 수 있는 동안 프레임 속도를 최대화하는 기능으로 인해, 가능하다면, dGPU를 업스케일링 작업 부하를 배치할 곳으로 권장할 수 있다고 명시할 수 있다. 예를 들어, 이러한 정책은 업스케일링 작업 부하 또는 업스케일링 작업 부하의 컴포넌트를 배치해야 하는 위치에 대한 기본설정, 작업 부하 측면(예를 들어, 속도, 전력 소비, 이미지 품질 등)에서의 열거된 우선순위, 작업 부하에 대한 기본 요구 사항(예를 들어, 프레임 속도, 대기 시간, 출력 해상도), 작업 부하에 대한 중요한 리소스(예를 들어, 작업 부하에 의해 과도하게 사용되는 리소스), 보안 및 보호 정책 등을 지정한다.

정책은 APU(102), dGPU(134), 또는 이들 둘 다에 업스케일링 작업의 작업 부하를 다음과 같은 정책에 기반하여 할당하도록 요구할 수 있다: 1) APU(102) 또는 dGPU가 허용하는 최대 플랫폼 용량 내에서 가능한 최대 프레임 속도 및/또는 최고 품질을 제공하도록 하는 정책, 2) 메모리 대역폭을 기반으로 할당하도록 하는 정책, 3) 컴퓨팅 대역폭에 기반하여 우선순위를 지정하도록 하는 정책, 4) 실시간의 다양한 유형의 사용 사례에 대해 프레임 속도를 유지할 수 있는 능력이나 용량에 기반하여 할당하도록 하는 정책, 5) 예를 들어 최저 전력 옵션 또는 최고 성능 옵션에 기반하여 작업 부하를 실행하는 능력, APU(102) 또는 dGPU 사이의 메모리 전송을 최소화하는 용량과 같은, 에너지 보존을 위한 용량 및 능력에 기반하여 할당하도록 하는 정책, 및 6) 메모리 공간을 최소화하는 능력에 기반하여 할당하도록 하는 정책.

추가로, 작업 부하의 렌더링 작업, 업스케일링 작업, 디스플레이 작업을 복수의 플랫폼 리소스 중 하나 이상의 플랫폼 리소스들 사이에 할당하는 것은 복수의 플랫폼 리소스 중 하나 이상의 전력 상태(예를 들어, AC에서 DC 전력으로의 변경 또는 DC에서 AC 전력으로의 변경)와, 복수의 플랫폼 리소스 중 하나 이상의 성능 능력에 기반할 수 있다.

전술한 내용을 고려하여, 당업자는 본 개시내용에 따른 구현예들이 다수의 이점들을 제공한다는 것을 이해할 것이다. 구현예들은 애플리케이션이 과도하게 활용되는 리소스에 작업 부하를 배치하지 않도록 시스템의 런타임 동작에 대한 가시성을 갖춘 다중 GPU 시스템에서 작업 부하를 시작하도록 한 애플리케이션을 제공한다. 또한, 기능부/작업 부하 유형에 대한 정책은 리소스 관리자의 정책 엔진이 해당 기능부/작업 부하 유형에 대한 최적의 작업 부하 할당 권장 사항을 만들 수 있게 하는 정의를 제공한다. 따라서, 시스템은 작업 부하가 예상대로 수행되는 것을 보장하거나, 작업 부하를 시작하기 전에 성능을 보장할 수 없다는 사실을 애플리케이션에 알릴 수 있다. 이러한 방식으로 사용자 경험이 향상된다.

구현예들은 메모리-로컬 컴퓨팅을 아토믹 작업들에 대해 효율적으로 사용할 수 있게 하며, 이는 다양한 중요한 작업 부하들(예를 들어, 그래프 분석, 희소 행렬 대수, 기계 학습 등)에 대한 성능을 개선할 수 있다. 이러한 애플리케이션들은 캐시 지역성(cache locality)이 이용 가능한 경우 이를 이용할 수 있고, 병합(coalescing) 기회들을 동적으로 식별하여 더 효율적인 다중-모듈 메모리-로컬 처리 작업들을 가능하게 할 수 있다.

구현예들은 시스템, 장치, 방법, 및/또는 논리 회로부일 수 있다. 본 개시내용의 컴퓨터 판독 가능 프로그램 명령어는 어셈블러 명령어, 명령어 집합 아키텍처(ISA) 명령어, 기계 명령어, 기계 종속적 명령어, 마이크로코드, 펌웨어 명령어, 상태 설정 데이터, 또는 Smalltalk, C++ 등과 같은 객체 지향 프로그래밍 언어 및 "C" 프로그래밍 언어 또는 유사한 프로그래밍 언어와 같은 기존의 절차적 프로그래밍 언어를 포함하는 하나 이상의 프로그래밍 언어의 조합으로 작성된 소스 코드 또는 개체 코드 중 어느 하나일 수 있다. 일부 구현예들에서, 예를 들어 프로그램 가능 논리 회로부, 필드 프로그램 가능 게이트 어레이(FPGA), 또는 프로그램 가능 논리 어레이(PLA)를 포함하는 전자 회로부는 컴퓨터 판독 가능 프로그램 명령어의 상태 정보를 이용함으로써 컴퓨터 판독 가능 프로그램 명령어를 실행한다.

본 개시내용의 양태들은 본원에서는 본 개시내용의 일부 구현예들에 따른 방법, 장치(시스템), 및 논리 회로부의 흐름도 및/또는 블록선도를 참조하여 설명되어 있다. 흐름도 및/또는 블록선도의 각 블록과, 흐름도 및/또는 블록선도의 블록들의 조합은 논리 회로부에 의해 구현될 수 있는 것으로 이해될 것이다.

논리 회로부는, 컴퓨터 또는 기타 프로그램 가능 장치 또는 기타 디바이스에서 실행되는 명령어들이 흐름도 및/또는 블록선도의 블록 또는 블록들에 지정된 기능/동작들을 구현하도록, 일련의 연산 단계들이 하나의 프로세서 또는 기타 프로그램 가능 장치 또는 기타 디바이스에서 수행되게 해서 하나의 컴퓨터 구현 프로세스가 생성되도록 그 하나의 프로세서 또는 기타 프로그램 가능 데이터 프로세싱 장치 또는 기타 디바이스에서 구현될 수 있다.

도면에서의 흐름도 및 블록선도는 본 개시내용의 다양한 구현예들에 따른 시스템, 방법, 및 논리 회로부의 가능한 구현예들의 아키텍처, 기능, 및 연산을 예시한다. 이와 관련하여, 흐름도 또는 블록선도에서의 각 블록은 모듈, 세그먼트, 또는 특정된 논리 기능(들)을 구현하기 위한 하나 이상의 실행 가능한 명령어를 포함하는 명령어들의 일부를 나타낼 수 있다. 일부 대안적인 구현예들에서, 블록에 언급된 기능성들은 도면들에 언급된 순서를 벗어나서 발생할 수 있다. 예를 들어, 연속적으로 도시된 2개의 블록은, 사실상, 실질적으로 동시에 실행될 수 있거나, 때로는 관련된 기능성 여하에 따라 역순으로 실행될 수 있다. 또한, 블록선도 및/또는 흐름도에서의 각 블록과, 블록선도 및/또는 흐름도에서의 블록들의 조합은, 지정된 기능 또는 동작을 수행하거나 특수 목적 하드웨어와 컴퓨터 명령어의 조합을 수행하는 특수 목적 하드웨어 기반 시스템에 의해 구현될 수 있다는 것도 유의한다.

본 개시내용은 이의 구현예들을 참조하여 구체적으로 나타내고 설명되었지만, 형태 및 세부사항들에 있어서의 다양한 변경이 하기의 청구범위의 사상 및 범위로부터 벗어나지 않고 이루어질 수 있음이 이해될 것이다. 따라서, 본원에 설명된 구현예들은 제한의 목적이 아니라 설명적인 의미로만 고려되어야 한다. 본 개시내용은 상세한 설명에 의해서가 아니라 첨부된 청구범위에 의해 정의되고, 그 범위 내에서의 모든 차이는 본 개시내용에 포함되는 것으로 해석되어야 할 것이다.

Claims (20)

1. 플랫폼 리소스들을 이용하여 복합 처리하는 방법으로서,
   업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하는 단계 - 상기 복수의 플랫폼 리소스들에는 하나 이상의 그래픽 처리 장치(GPU) 및 하나 이상의 가속 처리 장치(APU)가 포함됨 -;
   상기 업스케일링 작업의 방식에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 플랫폼 리소스들 중 하나 이상에 동적으로 할당하는 단계; 및
   상기 작업 부하가 할당된 상기 플랫폼 리소스들에 의해 상기 업스케일링 작업의 상기 작업 부하를 처리하는 단계를 포함하는, 복합 처리하는 방법.
2. 제1항에 있어서, 상기 업스케일링 작업의 상기 방식을 사용자 기본설정에 기반하여 선택하는 단계를 더 포함하는, 복합 처리하는 방법.
3. 제1항에 있어서, 상기 업스케일링 작업의 상기 방식을 상기 플랫폼 리소스들의 성능 능력에 기반하여 선택하는 단계를 더 포함하는, 복합 처리하는 방법.
4. 제1항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 플랫폼 리소스들의 성능 능력에 기반하여 상기 작업 부하를 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 방법.
5. 제1항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 사용자 기본설정에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 하나 이상의 플랫폼 리소스에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 방법.
6. 제1항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 상기 업스케일링 작업의 상기 작업 부하를 상기 제1 플랫폼 리소스와 상기 제2 플랫폼 리소스 사이에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 방법.
7. 제1항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 상기 복수의 플랫폼 리소스들 중 하나 이상의 전력 상태, 및 상기 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 상기 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 상기 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 방법.
8. 플랫폼 리소스들을 이용하여 복합 처리하는 장치로서, 상기 장치는 컴퓨터 프로세서, 상기 컴퓨터 프로세서에 동작 가능하게 결합된 컴퓨터 메모리를 포함하고, 상기 컴퓨터 메모리는 그 안에 컴퓨터 프로그램 명령어들이 내장되고, 상기 컴퓨터 프로그램 명령어들은 상기 컴퓨터 프로세서에 의해 실행될 때 상기 장치로 하여금,
   업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하는 단계 - 상기 복수의 플랫폼 리소스들에는 하나 이상의 그래픽 처리 장치(GPU) 및 하나 이상의 가속 처리 장치(APU)가 포함됨 -;
   적어도 상기 업스케일링 작업의 방식에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 플랫폼 리소스들 중 하나 이상에 동적으로 할당하는 단계; 및
   상기 작업 부하가 할당된 상기 플랫폼 리소스들에 의해 상기 업스케일링 작업의 상기 작업 부하를 처리하는 단계를 수행하게 하는, 복합 처리하는 장치.
9. 제8항에 있어서, 실행될 때 당해 장치로 하여금 사용자 기본설정에 기반하여 상기 업스케일링 작업의 상기 방식을 선택하는 단계를 수행하게 하는 컴퓨터 프로그램 명령어들을 더 포함하는, 복합 처리하는 장치.
10. 제8항에 있어서, 실행될 때 당해 장치로 하여금 상기 플랫폼 리소스들의 성능 능력에 기반하여 상기 업스케일링 작업의 상기 방식을 선택하는 단계를 수행하게 하는 컴퓨터 프로그램 명령어들을 더 포함하는, 복합 처리하는 장치.
11. 제8항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 플랫폼 리소스들의 성능 능력에 기반하여 상기 작업 부하를 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 장치.
12. 제8항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 사용자 기본설정에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 하나 이상의 플랫폼 리소스에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 장치.
13. 제8항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 상기 업스케일링 작업의 상기 작업 부하를 상기 제1 플랫폼 리소스와 상기 제2 플랫폼 리소스 사이에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 장치.
14. 제8항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 상기 복수의 플랫폼 리소스들 중 하나 이상의 전력 상태, 및 상기 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 상기 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 상기 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하는 단계를 더 포함하는, 복합 처리하는 장치.
15. 플랫폼 리소스들을 이용한 복합 처리를 위한 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 프로그램 제품은 컴퓨터 판독 가능 매체에 배치되고, 상기 컴퓨터 프로그램 제품은 컴퓨터 프로그램 명령어들을 포함하고, 상기 컴퓨터 프로그램 명령어들은 실행될 때 컴퓨터로 하여금,
    업스케일링 작업을 수행하는 데 이용 가능한 복수의 플랫폼 리소스들을 식별하는 단계 - 상기 복수의 플랫폼 리소스들에는 하나 이상의 그래픽 처리 장치(GPU) 및 하나 이상의 가속 처리 장치(APU)가 포함됨 -;
    상기 업스케일링 작업의 방식에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 플랫폼 리소스들 중 하나 이상에 동적으로 할당하는 단계; 및
    상기 작업 부하가 할당된 상기 플랫폼 리소스들에 의해 상기 업스케일링 작업의 상기 작업 부하를 처리하는 단계를 수행하게 하는, 컴퓨터 프로그램 제품.
16. 제15항에 있어서, 실행될 때 컴퓨터로 하여금,
    상기 업스케일링 작업의 상기 방식을 사용자 기본설정에 기반하여 선택하는 단계; 및
    상기 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 상기 업스케일링 작업의 상기 방식을 선택하는 단계를 수행하게 하는 컴퓨터 프로그램 명령어들을 더 포함하는, 컴퓨터 프로그램 제품.
17. 제15항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 플랫폼 리소스들의 성능 능력에 기반하여 상기 작업 부하를 동적으로 할당하는 단계를 더 포함하는, 컴퓨터 프로그램 제품.
18. 제15항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 사용자 기본설정에 기반하여 상기 업스케일링 작업의 작업 부하를 상기 하나 이상의 플랫폼 리소스에 동적으로 할당하는 단계를 더 포함하는, 컴퓨터 프로그램 제품.
19. 제15항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 및 제1 플랫폼 리소스와 제2 플랫폼 리소스의 성능 능력에 기반하여 상기 업스케일링 작업의 상기 작업 부하를 상기 제1 플랫폼 리소스와 상기 제2 플랫폼 리소스 사이에 동적으로 할당하는 단계를 더 포함하는, 컴퓨터 프로그램 제품.
20. 제15항에 있어서, 상기 업스케일링 작업의 작업 부하를 동적으로 할당하는 단계는 상기 업스케일링 작업의 상기 방식, 사용자 기본설정, 상기 복수의 플랫폼 리소스들 중 하나 이상의 전력 상태, 및 상기 복수의 플랫폼 리소스들 중 하나 이상의 성능 능력에 기반하여 상기 작업 부하의 렌더링 작업과 업스케일링 작업과 디스플레이 작업을 상기 복수의 플랫폼 리소스들 중 하나 이상의 플랫폼 리소스들 사이에 동적으로 할당하는 단계를 더 포함하는, 컴퓨터 프로그램 제품.

Images