特表2024-538875 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ ▲騰▼▲訊▼科技（深▲セン▼）有限公司の特許一覧

特表2024-538875グラフィックスプロセッサのリソース管理方法、装置及び機器、並びにプログラム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2A
2B
2C
3
4A
4B
5
6
7
8A
8B
9A
9B
10
11
12
13

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-24

(54)【発明の名称】グラフィックスプロセッサのリソース管理方法、装置及び機器、並びにプログラム

(51)【国際特許分類】

G06F 9/50 20060101AFI20241017BHJP

【ＦＩ】

G06F9/50 150D

G06F9/50 150C

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024524725

(86)(22)【出願日】2022-11-17

(85)【翻訳文提出日】2024-04-24

(86)【国際出願番号】 CN2022132457

(87)【国際公開番号】W WO2023151340

(87)【国際公開日】2023-08-17

(31)【優先権主張番号】202210135158.4

(32)【優先日】2022-02-14

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

【氏名又は名称原語表記】ＴＥＮＣＥＮＴＴＥＣＨＮＯＬＯＧＹ（ＳＨＥＮＺＨＥＮ）ＣＯＭＰＡＮＹＬＩＭＩＴＥＤ

【住所又は居所原語表記】３５／Ｆ，ＴｅｎｃｅｎｔＢｕｉｌｄｉｎｇ，ＫｅｊｉｚｈｏｎｇｙｉＲｏａｄ，ＭｉｄｗｅｓｔＤｉｓｔｒｉｃｔｏｆＨｉ－ｔｅｃｈＰａｒｋ，ＮａｎｓｈａｎＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８０５７，ＣＨＩＮＡ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾直樹

(72)【発明者】

【氏名】▲楊▼ 坤

(72)【発明者】

【氏名】王 ▲賜▼▲ラン▼

(72)【発明者】

【氏名】唐 ▲璽▼

(72)【発明者】

【氏名】▲楊▼ ▲広▼▲東▼

(57)【要約】

本願の実施形態は、グラフィックスプロセッサのリソース管理方法、装置及び機器、コンピュータ読み取り可能な記憶媒体、並びにコンピュータプログラム製品を提供する。本願の実施形態に係る方法は、クラウド技術及びクラウドゲーミングの分野に関し、同一のグラフィックスプロセッサ上で同時に実行される複数のアプリケーションプロセスに対して、過去のリソース割り当てにおけるこれらのアプリケーションプロセスに使用可能な残りのリソースを考慮し、グラフィックスプロセッサのリソースにおけるこれらのアプリケーションプロセスの現在使用可能なリソース量に基づいて、リソース割り当て方式をリアルタイムに決定することにより、グラフィックスプロセッサのリソースに対する効率的な割り当てを実現する。本願の実施形態に係る方法によれば、各アプリケーションプロセスのリソース需要に応じて、グラフィックスプロセッサのリソースを合理的に割り当てることができ、複数のアプリケーションプロセス間の競合の影響を回避し、グラフィックスプロセッサのリソースの使用率を向上させる。

【特許請求の範囲】

【請求項1】

グラフィックスプロセッサのリソース管理機器が実行するグラフィックスプロセッサのリソース管理方法であって、
アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定するステップと、
処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるステップと、
１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するステップであって、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられる、ステップと、
前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するステップであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、ステップと、を含み、
前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理方法。

【請求項2】

前記複数のアプリケーションプロセスの各アプリケーションプロセスは、所定のリソース需要重みを有し、
前記グラフィックスプロセッサのリソース管理方法は、
前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を取得し、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するステップをさらに含み、
前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するステップは、
前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量、及び前記アプリケーションプロセスのリソース需要重みに基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するステップを含み、
前記リソース割り当て命令は、前記アプリケーションプロセスの第１誤差を第２誤差よりも大きくするために用いられ、前記第１誤差は、前記アプリケーションプロセスのリソース需要重みと、前記過去の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差であり、前記第２誤差は、前記アプリケーションプロセスのリソース需要重みと、前記現在の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差である、請求項１に記載のグラフィックスプロセッサのリソース管理方法。

【請求項3】

グラフィックスプロセッサの過去の所定リソースと現在の所定リソースにそれぞれ含まれるリソース量は、いずれも所定リソース量であり、
前記複数のアプリケーションプロセスの各アプリケーションプロセスのリソース需要重みは、前記所定リソース量における前記アプリケーションプロセスに必要なリソース量の割合を示すものであり、
前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるステップは、
前記複数のグラフィックスプロセッサの各グラフィックスプロセッサの使用可能リソース比を決定するステップであって、前記使用可能リソース比は、前記グラフィックスプロセッサにおけるアプリケーションプロセスの処理に使用可能なリソースの割合である、ステップと、
前記複数のアプリケーションプロセスの各アプリケーションプロセスのリソース需要重み、及び前記複数のグラフィックスプロセッサの各グラフィックスプロセッサの使用可能リソース比に基づいて、各アプリケーションプロセスに割り当てられるグラフィックスプロセッサを決定するステップと、を含み、
１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスのリソース需要重みの合計は、前記グラフィックスプロセッサの使用可能リソース比以下である、請求項２に記載のグラフィックスプロセッサのリソース管理方法。

【請求項4】

前記リソース割り当て命令は、対応するアプリケーションプロセスが対応するグラフィックスプロセッサに処理タスクを送信して前記グラフィックスプロセッサに処理させるか否かを指示するものであり、前記グラフィックスプロセッサによる前記処理タスクの処理は、前記アプリケーションプロセスによる前記グラフィックスプロセッサのリソースの使用に対応し、
前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するステップは、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップであって、前記第１増分は、前記アプリケーションプロセスに対応するグラフィックスプロセッサによる前記アプリケーションプロセスからの処理タスクの前回の処理に対応する、ステップを含む、請求項２に記載のグラフィックスプロセッサのリソース管理方法。

【請求項5】

前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップは、
前記グラフィックスプロセッサによる前記処理タスクの処理方式に基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップであって、前記処理方式は、同期レンダリング又は非同期レンダリングのうちの少なくとも１つを含む、ステップを含む、請求項４に記載のグラフィックスプロセッサのリソース管理方法。

【請求項6】

前記グラフィックスプロセッサによる前記処理タスクの処理方式に基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップは、
前記グラフィックスプロセッサによる前記処理タスクの処理方式が非同期レンダリングである場合、前記前回の処理の開始と終了をマークすることにより、前記第１増分を決定するステップを含む、請求項５に記載のグラフィックスプロセッサのリソース管理方法。

【請求項7】

前記グラフィックスプロセッサによる前記処理タスクの処理方式に基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップは、
前記グラフィックスプロセッサによる前記処理タスクの処理方式が同期レンダリングである場合、クエリ命令を使用することにより、前記グラフィックスプロセッサから前記第１増分を取得するステップを含む、請求項５に記載のグラフィックスプロセッサのリソース管理方法。

【請求項8】

前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するステップは、
前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する現在の所定リソースにおける使用可能な残りのリソース量がゼロ以下である場合、前記アプリケーションプロセスへのリソース割り当て命令が前記アプリケーションプロセスに対して処理を行わないことを指示すると決定するステップと、
前記少なくとも１つのアプリケーションプロセスのうち、使用可能な残りのリソース量がゼロより大きい他のアプリケーションプロセスに対して、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップと、を含む、請求項４に記載のグラフィックスプロセッサのリソース管理方法。

【請求項9】

前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度は、前記アプリケーションプロセスの処理待ち時間の長さ、及びその最新の第１増分を決定する時間的順序に関連付けられ、
前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップは、
前記他のアプリケーションプロセスの各アプリケーションプロセスに対して、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在する場合、前記アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、前記アプリケーションプロセスへのリソース割り当て命令を決定するステップと、
処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在しない場合、前記他のアプリケーションプロセスの各アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップと、を含む、請求項８に記載のグラフィックスプロセッサのリソース管理方法。

【請求項10】

グラフィックスプロセッサのリソース管理機器が実行するグラフィックスプロセッサのリソース管理方法であって、
スケジューリングプロセスを起動するステップであって、前記スケジューリングプロセスは、割り当てスレッド及び複数の処理スレッドを含む、ステップと、
前記割り当てスレッドにより、アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定し、前記複数のグラフィックスプロセッサの各グラフィックスプロセッサに１つの処理スレッドを割り当てるステップと、
複数のアプリケーションプロセスを起動するステップであって、前記複数のアプリケーションプロセスの各アプリケーションプロセスは、前記スケジューリングプロセスによって予め構築されたスケジューリングライブラリを含む、ステップと、
前記複数のアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスのスケジューリングライブラリ及び前記割り当てスレッドにより、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサ及び対応する処理スレッドを割り当てるステップと、
１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する処理スレッドにより、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定して、前記アプリケーションプロセスへのリソース割り当て命令を決定するステップであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、ステップと、を含み、
前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられ、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理方法。

【請求項11】

アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定するように構成されるプロセッサ決定モジュールと、
処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるように構成されるプロセッサ割り当てモジュールと、
１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するように構成される残りリソース決定モジュールであって、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられる、残りリソース決定モジュールと、
前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するように構成されるリソース割り当てモジュールであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、リソース割り当てモジュールと、を備え、
前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理装置。

【請求項12】

前記複数のアプリケーションプロセスの各アプリケーションプロセスは、所定のリソース需要重みを有し、
前記グラフィックスプロセッサのリソース管理装置は、
前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を取得し、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するように構成される使用済みリソース決定モジュールをさらに備え、
前記残りリソース決定モジュールは、さらに、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量、及び前記アプリケーションプロセスのリソース需要重みに基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するように構成され、
前記リソース割り当て命令は、前記アプリケーションプロセスの第１誤差を第２誤差よりも大きくするために用いられ、前記第１誤差は、前記アプリケーションプロセスのリソース需要重みと、前記過去の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差であり、前記第２誤差は、前記アプリケーションプロセスのリソース需要重みと、前記現在の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差である、請求項１１に記載のグラフィックスプロセッサのリソース管理装置。

【請求項13】

前記リソース割り当て命令は、対応するアプリケーションプロセスが対応するグラフィックスプロセッサに処理タスクを送信して前記グラフィックスプロセッサに処理させるか否かを指示するものであり、前記グラフィックスプロセッサによる前記処理タスクの処理は、前記アプリケーションプロセスによる前記グラフィックスプロセッサのリソースの使用に対応し、
前記使用済みリソース決定モジュールは、さらに、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するように構成され、前記第１増分は、前記アプリケーションプロセスに対応するグラフィックスプロセッサによる前記アプリケーションプロセスからの処理タスクの前回の処理に対応する、請求項１２に記載のグラフィックスプロセッサのリソース管理装置。

【請求項14】

前記リソース割り当てモジュールは、さらに、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する現在の所定リソースにおける使用可能な残りのリソース量がゼロ以下である場合、前記アプリケーションプロセスへのリソース割り当て命令が前記アプリケーションプロセスに対して処理を行わないことを指示すると決定し、前記少なくとも１つのアプリケーションプロセスのうち、使用可能な残りのリソース量がゼロより大きい他のアプリケーションプロセスに対して、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するように構成される、請求項１３に記載のグラフィックスプロセッサのリソース管理装置。

【請求項15】

前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度は、前記アプリケーションプロセスの処理待ち時間の長さ、及びその最新の第１増分を決定する時間的順序に関連付けられ、
前記リソース割り当てモジュールは、さらに、前記他のアプリケーションプロセスの各アプリケーションプロセスに対して、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在する場合、前記アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、前記アプリケーションプロセスへのリソース割り当て命令を決定し、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在しない場合、前記他のアプリケーションプロセスの各アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するように構成される、請求項１４に記載のグラフィックスプロセッサのリソース管理装置。

【請求項16】

１つ又は複数のプロセッサと、
１つ又は複数のメモリと、を含むグラフィックスプロセッサのリソース管理機器であって、
前記メモリには、コンピュータ実行可能なプログラムが記憶され、前記コンピュータ実行可能なプログラムが前記プロセッサによって実行されると、請求項１～１０のいずれか一項に記載のグラフィックスプロセッサのリソース管理方法が実行される、グラフィックスプロセッサのリソース管理機器。

【請求項17】

コンピュータ実行可能な命令が記憶されるコンピュータ読み取り可能な記憶媒体であって、
プロセッサによって前記命令が実行されると、請求項１～１０のいずれか一項に記載のグラフィックスプロセッサのリソース管理方法が実現される、コンピュータ読み取り可能な記憶媒体。

【請求項18】

コンピュータ命令を含むコンピュータプログラム製品であって、
該コンピュータ命令がプロセッサによって実行されると、請求項１～１０のいずれか一項に記載のグラフィックスプロセッサのリソース管理方法のステップが実現される、ことを特徴とするコンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０２２年２月１４日に中国国家知識産権局に提出された、出願番号が２０２２１０１３５１５８４で、発明の名称が「グラフィックスプロセッサのリソース管理方法、装置及び機器、並びに記憶媒体」である中国特許出願の優先権を主張するものであり、その全ての内容は、参照により本願に組み込まれるものとする。

【0002】

本願は、クラウド技術の分野に関し、より具体的には、グラフィックスプロセッサのリソース管理方法、装置及び機器、コンピュータ読み取り可能な記憶媒体、並びにコンピュータプログラム製品に関する。

【背景技術】

【0003】

クラウド技術の継続的な発展に伴い、クラウドゲーミングは、ゲーム業界においてますます人気が高まっている。クラウドゲーミングは、ゲームの画面をクラウドサーバ側のグラフィックスプロセッサ（ＧｒａｐｈｉｃＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、ＧＰＵ）でレンダリングし、ネットワークを介してレンダリング結果をユーザのクライアントに伝送する。しかしながら、クラウドサーバ側のＧＰＵリソースが限られており、クラウドゲーミングを提供するクラウドサーバでは、該クラウドサーバにロードされた複数のゲームプロセスがクラウドサーバのハードウェアコンピューティングリソースを共有する可能性があるため、ハードウェアコンピューティングリソースに対する競合が発生する。１つのＧＰＵ上で複数のゲームプロセスが同時に実行されると、これらのゲームプロセスがＧＰＵリソースを競合するため、レンダリング効果に影響を与え、各ゲームプロセスに個別のＧＰＵを提供すると、各ゲームプロセスのレンダリング品質を保証することができるが、必然的にＧＰＵリソースの深刻な浪費を招く。

【0004】

したがって、限られたＧＰＵリソースで、より高品質なマルチゲームプロセスのレンダリングを実現する効率的なＧＰＵリソース管理方法が求められている。

【発明の概要】

【発明が解決しようとする課題】

【0005】

上記課題を解決するために、本願は、各タスクプロセスのリソース需要及び既に発生したリソース消費に基づいて、これらのタスクプロセスに対する処理順序をリアルタイムに決定することにより、グラフィックスプロセッサのリソースに対する効率的な割り当てを実現する。

【課題を解決するための手段】

【0006】

本願の実施形態は、グラフィックスプロセッサのリソース管理方法、装置及び機器、コンピュータ読み取り可能な記憶媒体、並びにコンピュータプログラム製品を提供する。

【0007】

本願の実施形態は、アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定するステップと、処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるステップと、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するステップであって、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられている、ステップと、前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するステップであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、ステップと、を含み、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理方法を提供する。

【0008】

本願の実施形態は、スケジューリングプロセスを起動するステップであって、前記スケジューリングプロセスは、割り当てスレッド及び複数の処理スレッドを含む、ステップと、前記割り当てスレッドにより、アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定し、前記複数のグラフィックスプロセッサの各グラフィックスプロセッサに１つの処理スレッドを割り当てるステップと、複数のアプリケーションプロセスを起動するステップであって、前記複数のアプリケーションプロセスの各アプリケーションプロセスは、前記スケジューリングプロセスによって予め構築されたスケジューリングライブラリを含む、ステップと、前記複数のアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスのスケジューリングライブラリ及び前記割り当てスレッドにより、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つグラフィックスプロセッサ及び対応する処理スレッドを割り当てるステップと、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する処理スレッドにより、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定して、前記アプリケーションプロセスへのリソース割り当て命令を決定するステップであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、ステップと、を含み、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられており、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理方法をさらに提供する。

【0009】

本願の実施形態は、アプリケーションプロセスを処理可能な複数のグラフィックスプロセッサを決定するように構成されるプロセッサ決定モジュールと、処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるように構成されるプロセッサ割り当てモジュールと、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するように構成される残りリソース決定モジュールであって、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられている、残りリソース決定モジュールと、前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するように構成されるリソース割り当てモジュールであって、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである、リソース割り当てモジュールと、を備え、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる、グラフィックスプロセッサのリソース管理装置を提供する。

【0010】

本願の実施形態は、１つ又は複数のプロセッサと、１つ又は複数のメモリとを含むグラフィックスプロセッサのリソース管理機器であって、前記１つ又は複数のメモリには、コンピュータ実行可能なプログラムが記憶され、前記コンピュータ実行可能なプログラムが前記プロセッサによって実行されると、上記のようなグラフィックスプロセッサのリソース管理方法が実行される、グラフィックスプロセッサのリソース管理機器を提供する。

【0011】

本願の実施形態は、コンピュータ実行可能な命令が記憶されるコンピュータ読み取り可能な記憶媒体であって、プロセッサによって前記命令が実行されると、上記のようなグラフィックスプロセッサのリソース管理方法が実現される、コンピュータ読み取り可能な記憶媒体を提供する。

【0012】

本願の実施形態は、コンピュータ命令を含むコンピュータプログラム製品又はコンピュータプログラムであって、該コンピュータ命令がコンピュータ読み取り可能な記憶媒体に記憶される、コンピュータプログラム製品又はコンピュータプログラムをさらに提供する。コンピュータ機器のプロセッサは、コンピュータ読み取り可能な記憶媒体から該コンピュータ命令を読み取り、プロセッサは、該コンピュータ命令を実行して、該コンピュータ機器に本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を実行させる。

【発明の効果】

【0013】

本願の実施形態に係る方法は、従来のグラフィックスプロセッサのリソース管理方法に比べて、グラフィックスプロセッサ上で実行されるアプリケーションプロセスの過去のリソース消費量をリソース割り当ての参照として、各アプリケーションプロセスの実際に使用可能なリソース量に基づいて、リソース割り当てをリアルタイムに調整することにより、複数のアプリケーションプロセス間のリソース競合を回避する。

【0014】

本願の実施形態に係る方法は、同一のグラフィックスプロセッサ上で同時に実行される複数のアプリケーションプロセスに対して、過去のリソース割り当てにおけるこれらのアプリケーションプロセスに使用可能な残りのリソースを考慮し、グラフィックスプロセッサのリソースにおけるこれらのアプリケーションプロセスの現在使用可能なリソース量に基づいて、リソース割り当て方式をリアルタイムに決定することにより、グラフィックスプロセッサのリソースに対する効率的な割り当てを実現する。本願の実施形態に係る方法によれば、各アプリケーションプロセスのリソース需要に応じて、グラフィックスプロセッサのリソースを合理的に割り当てることができ、複数のアプリケーションプロセス間の競合の影響を回避し、グラフィックスプロセッサのリソースの使用率を向上させる。

【図面の簡単な説明】

【0015】

本願の実施形態における技術的手段をより明確に説明するために、以下、実施形態の説明に使用される必要がある図面を簡単に説明する。明らかなように、以下の説明における図面は、本願のいくつかの例示的な実施形態に過ぎず、当業者であれば、創造的な労働をせずに、これらの図面に基づいて他の図面を得ることができる。

【図1】本願の実施形態に係る複数のアプリケーションプロセスがＧＰＵリソースを使用するシーンを示す例示的な概略図である。

【図2A】本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示すフローチャートである。

【図2B】本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示す概略フローチャートである。

【図2C】本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示すシーケンス概略図である。

【図3】本願の実施形態に係る複数のアプリケーションプロセスにグラフィックスプロセッサを割り当てることを示す概略図である。

【図4A】本願の実施形態に係る２種類のリソース使用状況を示す概略図である。

【図4B】本願の実施形態に係る複数のアプリケーションプロセスのリソース割り当て割合を示す概略図である。

【図5】本願の実施形態に係る収集キュー及び処理キューを示す概略図である。

【図6】本願の実施形態に係る現在の所定リソースにおけるアプリケーションプロセスの使用済みリソース量の第１増分を決定することを示す例示的な概略図である。

【図7】本願の実施形態に係る第１増分の取得と処理を示す概略図である。

【図8A】本願の実施形態に係る第１増分を決定する際のＣＰＵとＧＰＵのダブルバッファリング方法を示す概略図である。

【図8B】本願の実施形態に係る第１増分を決定する際のＣＰＵとＧＰＵの適応バッファリング方法を示す概略図である。

【図9A】本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示す概略図である。

【図9B】本願の実施形態に係るグラフィックスプロセッサのリソース管理方法のスケジューリングロジックを示す概略図である。

【図10】本願の実施形態に係るグラフィックスプロセッサのリソース管理装置を示す概略図である。

【図11】本願の実施形態に係るグラフィックスプロセッサのリソース管理機器を示す概略図である。

【図12】本願の実施形態に係る例示的なコンピューティング機器のアーキテクチャを示す概略図である。

【図13】本願の実施形態に係る記憶媒体を示す概略図である。

【発明を実施するための形態】

【0016】

本願の目的、技術的手段及び利点をより明確にするために、以下、図面を参照しながら本願に係る例示的な実施形態を詳細に説明する。明らかに、説明された実施形態は、本願の一部の実施形態に過ぎず、全てではなく、本願は、ここで説明された例示的な実施形態に限定されない。

【0017】

本明細書及び図面において、実質的に同一又は類似のステップ及び要素については、同一又は類似の符号を付することにより重複する説明を省略する。また、本願の説明において、「第１」、「第２」などの用語は、説明を区別するためだけに用いられ、相対的な重要性又は順序を指示又は暗示するものとして理解されるべきではない。また、用語「複数」は、少なくとも２つであると理解されてもよい。

【0018】

別段の定義がない限り、本明細書で用いられる全ての技術用語及び科学用語は、本願が属する技術分野の当業者によって一般的に理解されるのと同じ意味を有する。本明細書で使用される用語は、本発明の実施形態を説明するためのものにすぎず、本発明を限定することを意図するものではない。

【0019】

本願に係るグラフィックスプロセッサのリソース管理方法は、クラウド技術（Ｃｌｏｕｄｔｅｃｈｎｏｌｏｇｙ）に基づくことができる。

【0020】

本願に係るグラフィックスプロセッサのリソース管理方法は、クラウドゲーミング（Ｃｌｏｕｄｇａｍｉｎｇ）に基づくことができる。

【0021】

図１は、本願の実施形態に係る複数のアプリケーションプロセスがＧＰＵリソースを使用するシーンを示す例示的な概略図である。

【0022】

現在、多くの携帯電話アプリケーション又はコンピュータソフトウェアは、ネットワークを介してその機能を実現する必要があり、ゲームアプリケーションについてはなおさらである。ネットワークは、インターネット及び／又は電気通信網に基づくモノのインターネット（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ）であってもよく、有線ネットワークであっても無線ネットワークであってもよく、例えば、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、広域ネットワーク（ＷＡＮ）、セルラーデータ通信ネットワークなどの情報交換機能を実現できる電子ネットワークであってもよい。図１に示すように、ユーザ端末における携帯電話アプリケーション又はコンピュータソフトウェアは、ユーザによって入力される制御命令をサーバに送信して、対応するアプリケーションプロセスを起動することができる。サーバは、様々なハードウェアコンピューティングリソース、例えば、中央演算装置ユニット、通信インタフェース、メモリなどを有してもよい。図１に示すＧＰＵリソースを例として、サーバに複数のＧＰＵ（例えば、ＧＰＵ－１、ＧＰＵ－２など）があり、これらのＧＰＵのそれぞれは、異なる複数のアプリケーションプロセスに対して関連計算を行うことができる。

【0023】

任意選択で、該サーバは、独立した物理サーバであってもよく、複数の物理サーバで構成されたサーバクラスタ又は分散システムであってもよく、さらに、クラウドサービス、クラウドデータベース、クラウドコンピューティング、クラウド関数、クラウドストレージ、ネットワークサービス、クラウド通信、ミドルウェアサービス、ドメインネームサービス、セキュリティサービス、ＣＤＮ、並びに、ビッグデータ及び人工知能プラットフォームなどの基礎クラウドコンピューティングサービスを提供するクラウドサーバであってもよい。ユーザ端末は、スマートフォン、タブレットコンピュータ、ノートパソコン、デスクトップコンピュータ、スマートスピーカー、スマートウォッチなどであってもよいが、これらに限定されない。ユーザ端末及びサーバは、有線又は無線通信方式により直接的又は間接的に接続することができ、本願において限定されない。例えば、本願の実施形態において、ネットワークに接続されるゲームアプリケーションは、一般的に、クラウドサーバ上のＧＰＵによって、ユーザ端末に表示されるゲーム画面を合成したり、ハードウェアエンコードを行ったりし、このようなゲームアプリケーションは、クラウドゲーミングとも呼ばれる（「ゲームオンデマンド」とも呼ばれる）。ユーザ端末は、制御ストリームを介して、ユーザからのゲーム操作データをクラウドサーバに伝送することができ、クラウドサーバは、データストリームを介して、１フレーム又は複数フレームのオーディオフレーム及びビデオフレームをユーザ端末に伝送する。

【0024】

クラウドゲーミングにおいて、ゲームは、リモートクラウドサーバにおいて記憶、同期及びプレゼントされ、ストリーム技術によりプレイヤーに伝送され、従来のタイプとは全く異なるオンラインゲームサービスである。具体的には、クラウドサーバは、ゲームを実行し、そのグラフィカル出力をプレゼントしてビデオにエンコードし、そして、ビデオをネットワーククライアントにストリーミングし、クライアントは、プレイヤーがゲームとインタラクションするように、ビデオストリームをデコードして表示するとともに、プレイヤーによって入力される制御命令をクラウドサーバに送信する。このように、クラウドゲーミングは、ゲームの計算負荷をクライアントからクラウドに移行させることにより、プレイヤー機器に対する制約を解除するとともに、プレイヤーが時間をかけてゲームクライアントをダウンロードしてインストールすることなく、直ちにゲームを開始することができる。これらの利点により、クラウドゲーミングは、学術界及び産業界に大きな注目を集めている。

【0025】

以上より、クラウドサーバは、プレイヤーの入力に対する解釈、ゲームコードの実行及びグラフィックレンダリングを担当し、ネットワークを介してクライアントにゲームシーンを伝送し、クライアントは、デコードしてプレイヤーにゲームシーンを表示し、ゲームプレイヤーのゲームに対する操作をリアルタイムにキャプチャして送信し、クラウドサーバの入力とする。クラウドサーバがＧＰＵによりグラフィックレンダリングを実行する過程において、ＧＰＵハードウェアコンピューティングリソースが限られており、クラウドゲーミングを提供するクラウドサーバでは、該クラウドサーバにおける複数の仮想エンティティがクラウドサーバのハードウェアコンピューティングリソースを共有する可能性があるため、ハードウェアコンピューティングリソースに対する競合が発生する。一般的には、ＧＰＵハードウェアのレンダリングは、その上で実行する全てのゲームプロセスからのレンダリング要求を先着順でレンダリング処理し、単一のゲームプロセスのレンダリング負荷の増加は、他のゲームプロセスの正常なレンダリングに影響を与える。例えば、いずれかのゲームプロセスのレンダリングがタイムアウトする場合、他のゲームプロセスのレンダリング時間が強制的に短縮されるため、そのレンダリング品質が高くなくなり、また、このようなレンダリング品質の劣化がレンダリングプロセスの進行に伴って徐々に蓄積され、ユーザのゲーム体験に深刻な影響を与える可能性がある。

【0026】

現在のＧＰＵリソース管理方法は、ＧＰＵリソースに対する管理において、リソース割り当てを完全に分離するか、又はリソースプリエンプションを無視するが、ＧＰＵメモリとＰＣＩ－Ｅ（ｐｅｒｉｐｈｅｒａｌｃｏｍｐｏｎｅｎｔｉｎｔｅｒｃｏｎｎｅｃｔｅｘｐｒｅｓｓ）バス規格のバスの帯域幅に対して分離を行わないため、ある瞬間においてＧＰＵの占有率が非常に高いが、ＰＣＩ－Ｅバスがナル状態にあり、最終的なリソース全体の使用率が高くない可能性がある。例えば、仮想化ＧＰＵの技術によるＧＰＵリソースの分割は、ＧＰＵリソースの２分の１又は４分の１の分割粒度しか実現できず、より細かい粒度のリソース分割を行うことができず、このようなリソース管理方法は、特定のアプリケーションプロセスに対する事前設定に依存し、アプリケーションプロセスのエントリ／エグジットに応じてＧＰＵコンピューティングリソースをリアルタイムで柔軟に割り当てることができない。

【0027】

本願は、上記に鑑みて、グラフィックスプロセッサのリソース管理方法を提供し、各タスクプロセスのリソース需要及び既に発生したリソース消費に基づいて、これらのタスクプロセスに対する処理順序をリアルタイムに決定することにより、グラフィックスプロセッサのリソースに対する効率的な割り当てを実現する。

【0028】

本願の実施形態に係る方法は、従来のグラフィックスプロセッサのリソース管理方法に比べて、グラフィックスプロセッサ上で実行するアプリケーションプロセスの過去のリソース消費量をリソース割り当ての参照として、各アプリケーションプロセスの実際に使用可能なリソース量に基づいて、リソース割り当てをリアルタイムに調整することにより、複数のアプリケーションプロセス間のリソース競合を回避する。

【0029】

本願の実施形態に係る方法は、同一のグラフィックスプロセッサ上で同時に実行する複数のアプリケーションプロセスに対して、過去のリソース割り当てにおけるこれらのアプリケーションプロセスに使用可能な残りのリソースを考慮し、グラフィックスプロセッサのリソースにおけるこれらのアプリケーションプロセスの現在使用可能なリソース量に基づいて、リソース割り当て方式をリアルタイムに決定することにより、グラフィックスプロセッサのリソースに対する効率的な割り当てを実現する。本願の実施形態に係る方法によれば、各アプリケーションプロセスのリソース需要に応じて、グラフィックスプロセッサのリソースを合理的に割り当てることができ、複数のアプリケーションプロセス間の競合の影響を回避し、グラフィックスプロセッサのリソースの使用率を向上させる。

【0030】

図２Ａは、本願の実施形態に係るグラフィックスプロセッサのリソース管理方法２００を示すフローチャートである。図２Ｂは、本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示す概略フローチャートである。図２Ｃは、本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を示すシーケンス概略図である。

【0031】

図２Ａに示すように、ステップ２０１では、アプリケーションプロセスを処理するための複数のグラフィックスプロセッサを決定してもよい。

【0032】

任意選択で、ＧＰＵに対するリソース管理は、図２Ｃに示すようなアプリケーションプロセスとスケジューリングサービスとの２つの部分で協同して行うことができ、アプリケーションプロセス部分は、ＧＰＵリソース管理プロセスにおいてアプリケーションプロセス（例えば、ゲームインスタンス）が実行する操作に対応し、スケジューリングサービス部分は、対応するアプリケーションプロセスに対するＧＰＵリソース管理スケジューリング操作に対応する。任意選択で、該アプリケーションプロセスは、ゲームプロセス、ビデオプロセス及び会議プロセスなどの様々なアプリケーションプロセスであってもよく、本願において、限定ではなくＯｐｅｎＧＬ（ＯｐｅｎＧｒａｐｈｉｃｓＬｉｂｒａｒｙ、オープングラフィックスライブラリ）などのグラフィックスエンジンによって開発されたゲームプロセスを例として説明し、ＧＰＵリソーススケジューリングを必要とする任意のプロセスは、いずれも本願のＧＰＵリソース管理方法が適用可能である。

【0033】

図２Ｃに示すように、アプリケーションプロセスが起動される前に、スケジューリングサービスにおける割り当てスレッドは、まず、アプリケーションプロセスの処理に現在使用可能な複数のＧＰＵを決定し、スケジューリングサービスにおいて、これらのＧＰＵのために、対応する処理スレッドをそれぞれ作成することができるため、その後の各ＧＰＵに対するリソース割り当て管理は、その対応する処理スレッド上で行うことができる。例えば、ゲームインスタンスなどのアプリケーションプロセスのグラフィックレンダリングタスクについて、決定されたＧＰＵは、一定のレンダリング計算を実行する能力を有するべきである。なお、以下、多くの場合、クラウドゲーミングシーンでゲームインスタンスのグラフィックレンダリングについて説明するが、本願に係るＧＰＵリソース管理方法は、同様に他のアプリケーションプロセスの処理に適用され、例えば、ビデオプロセス及び会議プロセスの処理に適用され、ビデオ画面の画像レンダリングを処理してもよく、会議画面の画像レンダリングを処理してもよい。

【0034】

ステップ２０２では、処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当ててもよい。

【0035】

図２Ｃに示すように、各ユーザ端末がアプリケーションを起動した後、サーバ側は、対応するアプリケーションプロセスをそれぞれ登録することができ、各アプリケーションプロセスにそのグラフィックレンダリング処理用のＧＰＵを割り当て、割り当てられたＧＰＵのインデックス及びそれに対応する処理スレッドなどの情報である登録情報をアプリケーションプロセスに返すことを含むが、これらに限定されない。

【0036】

任意選択で、アプリケーションプロセスのＧＰＵリソース需要が決定された各ＧＰＵの使用可能なリソースを超える場合、アプリケーションプロセスのＧＰＵリソースに対する要求を異なるＧＰＵに転送して実行することにより、複数のＧＰＵを１つのＧＰＵに仮想化して、この場合のアプリケーションプロセス処理を実現することができる。

【0037】

任意選択で、ＧＰＵの計算性能の制限を満たすことを保証する場合、複数のアプリケーションプロセスを同一のＧＰＵに割り当てることができ、即ち、同一のＧＰＵ上で複数のアプリケーションプロセスの処理タスクを同時に実行する。

【0038】

図３は、本願の実施形態に係る複数のアプリケーションプロセスにグラフィックスプロセッサを割り当てることを示す概略図である。図３に示すように、３つのアプリケーションプロセスＡ、Ｂ、Ｃ、及び３つの使用可能なＧＰＵ１、２、３が存在する場合、ステップ２０２におけるＧＰＵの割り当て操作を実行することにより、ＧＰＵ１には、処理のためにアプリケーションプロセスＡ及びＣが割り当てられ、ＧＰＵ２には、処理のためにアプリケーションプロセスＢが割り当てられ、ＧＰＵ３には、いずれのアプリケーションプロセスの処理も割り当てられない。したがって、ＧＰＵ１上で共同して実行されるアプリケーションプロセスＡ及びＣについて、これらのアプリケーションプロセスは、ＧＰＵ１のコンピューティングリソースを共有することができるため、これらのアプリケーションプロセスのリソース使用にも競合関係がある可能性があり、本願に係るＧＰＵリソース管理方法は、これらのアプリケーションプロセス間の競合影響を回避することができる。

【0039】

本願の実施形態によれば、前記複数のアプリケーションプロセスの各アプリケーションプロセスは、所定のリソース需要重みを有してもよい。任意選択で、各アプリケーションプロセスのリソース需要重みは、その計算に必要なＧＰＵリソース量に基づいて決定されてもよく、該リソース需要重みは、予め決められ、登録時にスケジューリングサービスに通知されてもよい。例えば、複数のゲームインスタンスについて、その画面レンダリングの複雑さ及び計算量に基づいて、その対応するリソース需要重みを予め決めることができ、該重みは、単位ＧＰＵリソースにおけるゲームインスタンスの画面レンダリングに必要な割合であってもよく、例えば、ゲームインスタンスの画面レンダリングが１ｓのＧＰＵハードウェアコンピューティング時間において２００ｍｓを必要とする場合、該ゲームインスタンスのリソース需要重みは、０．２（２００ｍｓ／１ｓ）であってもよい。

【0040】

本願の実施形態によれば、ステップ２０２において、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てることは、前記複数のグラフィックスプロセッサの各グラフィックスプロセッサの使用可能リソース比を決定するステップであって、前記使用可能リソース比は、前記グラフィックスプロセッサにおけるアプリケーションプロセスの処理に使用可能なリソースの割合である、ステップと、前記複数のアプリケーションプロセスの各アプリケーションプロセスのリソース需要重み、及び前記複数のグラフィックスプロセッサの各グラフィックスプロセッサの使用可能リソース比に基づいて、各アプリケーションプロセスに割り当てられるグラフィックスプロセッサを決定するステップと、を含んでもよい。

【0041】

以上より、該複数のＧＰＵのそれぞれは、アプリケーションプロセスの処理に現在使用可能なＧＰＵであるが、これらのＧＰＵにおける使用可能なコンピューティングリソース量は、必ずしも等しくなくてもよいし、全てのコンピューティングリソース量と等しくなくてもよいため、特定のリソース需要を有するアプリケーションプロセスにＧＰＵを割り当てる前に、使用可能なＧＰＵの使用可能なリソース量を決定する必要がある。上記リソース需要重みに関する説明と同様に、ＧＰＵの使用可能なリソース量は、その使用可能リソース比で表すことができ、該使用可能リソース比は、ＧＰＵにおけるアプリケーションプロセスの処理に使用可能なリソース量がその単位リソースに占める比率を表すことができ、例えば、１ｓのＧＰＵハードウェアコンピューティング時間において、アプリケーションプロセスの処理に使用可能な時間が０．８ｓである場合、該ＧＰＵの使用可能リソース比は、０．８であってもよい。

【0042】

したがって、各アプリケーションプロセスのリソース需要重み及び各ＧＰＵの使用可能リソース比の双方に基づいて、アプリケーションプロセスへのＧＰＵ割り当てを決定することができる。本願の実施形態によれば、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスのリソース需要重みの合計は、前記グラフィックスプロセッサの使用可能リソース比以下である。処理のために１つのＧＰＵに割り当てられるアプリケーションプロセスのリソース需要重みの合計は、該ＧＰＵの使用可能リソース比以下であり、即ち、該ＧＰＵにおけるアプリケーションプロセスの処理に実際に使用されるリソース量は、予想されるリソース量以下である。

【0043】

ステップ２０３では、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定してもよく、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられてもよい。本願の実施形態によれば、グラフィックスプロセッサの過去の所定リソースと現在の所定リソースにそれぞれ含まれるリソース量は、いずれも所定リソース量であってもよい。

【0044】

任意選択で、過去の所定リソースと現在の所定リソースにそれぞれ含まれるリソース量（即ち、所定リソース量）は、上記単位ＧＰＵリソースであってもよく、該過去の所定リソースは、現在の所定リソースの前のアプリケーションプロセスの所定リソースである。単位ＧＰＵリソースの使用量により、該ＧＰＵの使用率（ＧＰＵの実際の動作時間と実行時間との比）を決定することができるため、本願におけるＧＰＵリソースの割り当ては、単位ＧＰＵリソースの割り当てに基づいて行うことができる。例えば、該単位ＧＰＵリソースは、上述した１ｓ又は１フレーム時間などの単位長さの計算時間であってもよく、本願は、これを限定しない。本願の実施形態によれば、前記複数のアプリケーションプロセスの各アプリケーションプロセスのリソース需要重みは、前記所定リソース量における前記アプリケーションプロセスに必要なリソース量の割合を示してもよい。以上より、アプリケーションプロセスのリソース需要重みは、単位ＧＰＵリソースにおける該アプリケーションプロセスの処理に必要なリソースの割合であってもよい。

【0045】

本願の実施形態において、現在のリソース割り当ては、アプリケーションプロセスに対するリソース割り当ての過去の状態に基づいて決定されてもよい。該過去の状態は、過去のリソース割り当てにおける該アプリケーションプロセスの残りのリソース量、即ち、使用可能であるが未使用のリソース量を含んでもよい。該使用可能な残りのリソース量の存在は、他のアプリケーションプロセスの処理のタイムアウトにより該アプリケーションプロセスのリソースが占有されることに起因する場合があり、このようなリソース占有により、該アプリケーションプロセスのレンダリング効果が低くなる可能性があるため、このようなリソース占有の蓄積を回避するために、後続のリソース割り当てにおいて対応する調整を行うことができ、例えば、現在のリソース割り当てにおけるアプリケーションプロセスに使用可能なリソース量と、過去のリソース割り当てにおけるその使用可能な残りのリソース量とを関連付ける。

【0046】

本願の実施形態によれば、ステップ２０３において、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定することは、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量、及び前記アプリケーションプロセスのリソース需要重みに基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するステップを含んでもよい。

【0047】

任意選択で、アプリケーションプロセスのリソース需要重み及び過去の所定リソースにおけるその使用可能な残りのリソース量に基づいて、現在の所定リソースにおける該アプリケーションプロセスに使用可能なリソース総量を決定することができるため、その上で、現在の所定リソースにおける該アプリケーションプロセスの使用済みリソース量に基づいて、現在の所定リソースにおけるその使用可能な残りのリソース量を決定することができ、即ち、現在の所定リソースにおける使用可能なリソース総量から現在の所定リソースにおける使用済みリソース量を減算して、現在の所定リソースにおける使用可能な残りのリソース量を得ることができる。

【0048】

過去の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量に基づいて、現在の所定リソースにおけるその使用可能な残りのリソース量を決定することにより、過去のリソース割り当てにおける誤差に基づいて、現在のリソース割り当てを調整して、該リソース割り当ての誤差を低減し、さらに解消することができる。例えば、過去の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量がゼロより小さい場合、現在の所定リソースにおける該アプリケーションプロセスに使用可能な残りのリソース量から過去の所定リソースにおける該アプリケーションプロセスに使用可能な残りのリソース量の絶対値を減算することにより、該リソース割り当ての誤差を効果的に低減することができる。

【0049】

したがって、本願の実施形態によれば、グラフィックスプロセッサのリソース管理方法２００は、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を取得し、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するステップをさらに含んでもよい。

【0050】

任意選択で、現在の所定リソースにおけるアプリケーションプロセスの使用済みリソース量は、アプリケーションプロセスが前回のリソース割り当てで使用したリソース量と、現在の所定リソースに対するより早いリソース割り当てで使用したリソース量とを含んでもよく、該アプリケーションプロセスが前回のリソース割り当てで使用したリソース量は、その最新の処理に使用したコンピューティングリソースに対応する。

【0051】

したがって、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するステップは、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するステップであって、前記第１増分は、前記アプリケーションプロセスに対応するグラフィックスプロセッサによる前記アプリケーションプロセスからの処理タスクの前回の処理に対応する、ステップを含んでもよい。

【0052】

任意選択で、ゲームインスタンスのレンダリングタスクに対して、該第１増分は、ＧＰＵが該ゲームインスタンスのレンダリング処理を前回実行した時間に対応してもよく、図２Ｃに示すように、該レンダリング時間がアプリケーションプロセスによって取得されてもよく、そこに設定されたスケジューリングライブラリによってスケジューリングサービスに通知し、それにより、スケジューリングサービスは、該レンダリング時間に基づいてレンダリング時間を処理し、現在の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量などを決定することを含む。

【0053】

以上より、図２Ｃに示すように、現在の所定リソースにおける同一のＧＰＵ上の各アプリケーションプロセスに使用可能な残りのリソース量を決定することにより、スケジューリングサービスは、現在のリソース割り当て方式を決定するとともに、レンダリングするか否かをアプリケーションプロセスに通知することができ、アプリケーションプロセスは、この間に、スケジューリングサービスからのレンダリング通知を待つ。したがって、各アプリケーションプロセスに使用可能な残りのリソース量、特に各アプリケーションプロセスの第１増分を取得することは、本願のＧＰＵリソース管理にとって非常に重要であり、割り当ての誤差を効果的に低減することができる。第１増分の取得方式について、以下の図６及び図７に関する関連説明を参照することができ、ここでは詳述しない。

【0054】

ステップ２０４では、前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定してもよく、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである。

【0055】

本願の実施形態によれば、ステップ２０４は、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量がゼロ以下である場合、前記アプリケーションプロセスへのリソース割り当て命令が前記アプリケーションプロセスに対して処理を行わないことを示すと決定するステップと、前記少なくとも１つのアプリケーションプロセスのうち、使用可能な残りのリソース量がゼロより大きい他のアプリケーションプロセスに対して、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップと、を含んでもよい。

【0056】

任意選択で、以上より、現在の所定リソースにおける使用可能な残りのリソース量がゼロ以下であるアプリケーションプロセスの場合、他のアプリケーションプロセスの処理に影響を与えないように、現在の所定リソースから、それにリソースを割り当てなくてもよい。現在の所定リソースにおける使用可能な残りのリソース量がゼロより大きいアプリケーションプロセスの場合、これらのアプリケーションプロセスにＧＰＵコンピューティングリソースを割り当て続けることが考えられる。任意選択で、これらのアプリケーションプロセスに対するリソース割り当ては、これらのアプリケーションプロセスの優先度に基づいて行ってもよく、上述した先着順で処理する競合モードのみに基づいて行うわけではない。

【0057】

本願の実施形態によれば、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度は、前記アプリケーションプロセスの処理待ち時間の長さ、及びその最新の第１増分を決定する時間的順序に関連付けられてもよい。例えば、画面のフリーズなどが発生しそうな処理対象のアプリケーションプロセスの場合、優先的に処理するように、その優先度を高く設定してもよく、このような非常事態が発生しない処理タイミングの場合、これらのアプリケーションプロセスの第１増分を取得した時間的順序に基づいて優先度を決定してもよく、例えば、先に第１増分を取得した、現在の所定リソースにおける使用可能な残りのリソース量がゼロより大きい、アプリケーションプロセスを優先的に処理することができる。

【0058】

本願の実施形態によれば、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップは、前記他のアプリケーションプロセスの各アプリケーションプロセスに対して、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在する場合、前記アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、前記アプリケーションプロセスへのリソース割り当て命令を決定するステップと、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在しない場合、前記他のアプリケーションプロセスの各アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するステップと、を含んでもよい。

【0059】

以上より、アプリケーションプロセスの優先度の設定については、次の３つの要因（これらの要因を含むが、これらに限られない）が考えられる。(1)使用可能な残りのリソース量であり、現在の所定リソースにおける使用可能な残りのリソース量がゼロ以下であるアプリケーションプロセスに対して低優先度を設定してもよい（実行しないことを指示する）。(2)緊急性であり、現在の早急に処理する必要があるアプリケーションプロセスに対して高優先度を設定してもよく、例えば、画面のフリーズ又は他の非常事態が発生する。(3)第１増分の取得順序であり、第１増分を先に取得したアプリケーションプロセスに対して高優先度を設定してもよく、ＧＰＵリソースの割り当てをより連続的にすることにより、ＧＰＵリソースの使用率を向上させる。アプリケーションプロセスの処理の優先度を設定する際に、本願の方法は、他の様々な要因を考慮してもよく、上記で挙げた要因は、ここでは、あくまで例示であり、これらに限定されるものではないことを理解されたい。

【0060】

本願の実施形態によれば、前記リソース割り当て命令は、対応するアプリケーションプロセスが対応するグラフィックスプロセッサに処理タスクを送信して前記グラフィックスプロセッサに処理させるか否かを指示するものであり、前記グラフィックスプロセッサによる前記処理タスクの処理は、前記アプリケーションプロセスによる前記グラフィックスプロセッサのリソースの使用に対応する。

【0061】

以上より、上記各種の操作ステップの実行は、従来のように、全てのアプリケーションプロセスのレンダリング命令をスケジューリングプロセスのレンダリングに必要な命令フローシステムにリダイレクトすることを必要とせず、イベントトリガー方式で行われるため、開発効率を向上させ、コストを低減することができる。

【0062】

図２Ｂに示すように、本願のＧＰＵリソース管理は、各アプリケーションプロセスによるＧＰＵハードウェアリソースのリソース使用状況を評価することにより、これらのアプリケーションプロセスによる処理タスクの送信を制御する。図２Ｂには、グラフィックレンダリングタスクを例とし、ＧＰＵリソース管理は、リソース割り当て命令により各アプリケーションプロセスによるレンダリング命令の配信を制御することができる。

【0063】

任意選択で、各アプリケーションプロセスは、受信されるリソース割り当て命令に基づいて、対応するＧＰＵに処理タスク（例えば、図２Ｂ中のＧＰＵレンダリング命令キューへのレンダリング命令の配信）を送信するか否かを決定することができ、ＧＰＵは、一定数のＧＰＵハードウェアリソースを消費して該処理タスクを実行し、該一定数のコンピューティングリソースは、次回のリソース割り当てで参照となる該アプリケーションプロセスの第１増分に対応することができる。

【0064】

本願の実施形態によれば、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにすることができる。任意選択で、リソース割り当て命令により、各アプリケーションプロセスに対するリソース割り当ての誤差は、減少する傾向がある。該所定の目標値は、予め設定された使用可能な残りのリソース量が到達すべき値であり、必要に応じて設定することができ、例えば、使用可能な残りのリソース量をゼロに近づけて、リソースを節約するために、ゼロに設定してもよい。

【0065】

図４Ａは、本願の実施形態に係る２種類のリソース使用状況を示す概略図である。例えば、アプリケーションプロセスに使用可能な残りのリソース量がゼロより大きい場合（例えば、図４Ａに示す正常な場合）、該アプリケーションプロセスへのリソース割り当て命令により、該アプリケーションプロセスは、処理タスクを送信し、さらに、一定量のコンピューティングリソースを使用し、ゼロより大きい使用可能な残りのリソース量を減少させることができ、アプリケーションプロセスに使用可能な残りのリソース量がゼロより小さい場合（例えば、図４Ａに示すタイムアウトの場合）、該アプリケーションプロセスは、現在の所定リソースにおけるいずれのリソースも使用できなくなるため、現在の所定リソースから該アプリケーションプロセスにいずれのリソースも割り当てなくなり、その使用可能な残りのリソース量が減少し続けることがなくなる。

【0066】

本願の実施形態によれば、前記リソース割り当て命令は、前記過去の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合よりも、前記現在の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合を、前記アプリケーションプロセスのリソース需要重みに近づける。即ち、該リソース割り当て命令は、前記アプリケーションプロセスの第１誤差を第２誤差よりも大きくするものであり、前記第１誤差は、前記アプリケーションプロセスのリソース需要重みと、前記過去の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差であり、前記第２誤差は、前記アプリケーションプロセスのリソース需要重みと、前記現在の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差である。

【0067】

図４Ｂは、本願の実施形態に係る複数のアプリケーションプロセスのリソース割り当て割合を示す概略図である。図４Ｂに示すように、３つのアプリケーションプロセスＡ、Ｂ及びＣのリソース需要重みは、それぞれ０．５、０．２及び０．３である。過去の所定リソースにおいて、アプリケーションプロセスＡは、その所定のリソース需要を超えるリソース量（５８％）を使用するため、他の２つのアプリケーションプロセスＢとＣのリソースが不足する（それぞれ１７％と２５％であり、いずれもその所定のリソース重みに対応するリソース割合より少ない）。

【0068】

したがって、本願に係るＧＰＵリソース管理方法によれば、過去の所定リソースにおけるアプリケーションプロセスＡに使用可能な残りのリソース量がゼロより小さいため（例えば、図４Ｂの例では、－０．０８である）、その過剰に使用されたリソース量（即ち、０．０８）に応じて、現在の所定リソースからのリソースの割り当てを減少させる。したがって、現在の所定リソースのリソース割り当て結果において、リソース割り当ての調整により、アプリケーションプロセスＡに４２％の使用可能なリソース量を割り当て、リソースが占有される他のアプリケーションプロセスＢ及びＣに対して、それぞれ占有されるリソース量に応じてリソース補償を行う（即ち、アプリケーションプロセスＢに使用可能なリソース量が２０％＋（２０％－１７％）＝２３％であり、アプリケーションプロセスＣに使用可能なリソース量が３０％＋（３０％－２５％）＝３５％である）。

【0069】

上記のように、現在の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにすることにより、現在の所定リソースにおけるアプリケーションプロセスによって使用されるリソース量を所望のリソース量、即ち、そのリソース需要重みに対応するリソース需要量により近づけることができる。したがって、アプリケーションプロセスへのオンデマンドリソース割り当てを実現し、ＧＰＵリソースの効率的な使用を実現することができる。

【0070】

上記ＧＰＵハードウェアリソースのタイミング割り当てにおいては、タイミング割り当てをトリガーするために、処理スレッドに正確なタイマーをバインディングする必要があることを考慮すると、方法の複雑さを低減するために、レンダリング時間を収集するための１つの収集キュー、及びレンダリング時間を処理するための１つの処理キューを作成することにより、図２Ｃにおけるレンダリング時間通知及びレンダリング時間処理の操作を完了することができる。

【0071】

図５は、本願の実施形態に係る収集キュー及び処理キューを示す概略図である。図５に示すように、収集キューは、入力イベントにより複数の新しいレンダリング時間データを順次挿入し、処理キューは、この間にレンダリング時間処理を実行し、その処理が完了した後に収集キューと交替して、収集キューを新しい処理キューにし、処理キューを新しい収集キューにし、キューの交替によって時間に対するタイミング割り当てを実現する。

【0072】

レンダリング時間の収集中に、アプリケーションプロセスの異なるレンダリング方式によって、第１増分を取得する方式もそれに応じて変化する可能性がある。本願の実施形態によれば、前記第１増分を決定する方式は、前記グラフィックスプロセッサによる前記処理タスクの処理方式に基づいて決定されてもよく、前記処理方式は、同期レンダリング又は非同期レンダリングのうちの少なくとも１つを含んでもよい。

【0073】

本願の実施形態によれば、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定することは、前記前回の処理の開始と終了をマークすることにより、前記第１増分を推定すること、又は、クエリ命令を使用することにより、前記グラフィックスプロセッサから前記第１増分を取得すること、のうちの１つによって行われてもよい。

【0074】

任意選択で、非同期レンダリング方式について、第１増分は、信号でＧＰＵハードウェアキューをインターセプトすることによって決定されてもよい。この場合、本願の実施形態によれば、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定することは、前記前回の処理の開始と終了をマークすることにより、前記第１増分を推定することによって行われてもよい。

【0075】

図６は、本願の実施形態に係る現在の所定リソースにおけるアプリケーションプロセスの使用済みリソース量の第１増分を決定することを示す例示的な概略図である。

【0076】

任意選択で、描画関数の実行時間を計算して、レンダリングの実際の所要時間を決定し、該レンダリングの実際の所要時間を現在の所定リソースにおける使用済みリソース量の第１増分としてもよい。図６に示すように、描画関数の実行時間は、準備時間と実際のレンダリング時間を含んでもよく、準備時間において、描画関数のＰＣＩ－Ｅチャネルによる伝送とレンダリングの準備が実行され、レンダリング命令の実行が含まれ、実際のレンダリング時間は、実際に描画命令実行部分である。したがって、描画命令の前後に命令信号Ｆを挿入して、該信号Ｆがトリガーされる時にアプリケーションプロセス（又はスケジューリングサービス）に計時開始又は計時終了を通知することができる。

【0077】

任意選択で、同期レンダリング方式について、アプリケーションスレッドローカルで第１増分をクエリにより決定することができる。この場合、本願の実施形態によれば、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定することは、クエリ命令を使用することにより、前記グラフィックスプロセッサから前記第１増分を取得することによって行われてもよい。

【0078】

図７は、本願の実施形態に係る第１増分の取得と処理を示す概略図である。

【0079】

同期レンダリングの場合、クエリによりＧＰＵにクエリ操作を送信することができ、該クエリ操作は、ＧＰＵにより２つの指定されたクエリ点間の時間を決定することができる。図７に示すように、「クエリ開始」及び「クエリ終了」は、それぞれＧＰＵに挿入された２つの指定されたクエリ点であり、その間のレンダリング命令の描画関数の実行にかかるＧＰＵ時間、即ち、レンダリング時間をクエリし、挿入された最初の「クエリ終了」点は、それに対応する「クエリ開始」点の挿入位置を知ることができないため、当該クエリを破棄する。図７に灰色の枠で示す部分は、取得されたレンダリング時間に基づいて、ＧＰＵリソース管理処理を実行することを示し、即ち、取得されたレンダリング時間をスケジューリングサービスに通知してから、スケジューリングサービスによるレンダリング通知を待ち、スケジューリングサービスによりレンダリング時間処理を実行し、イベント通知によりアプリケーションプロセスにレンダリング通知（即ち、リソース割り当て命令）を送信する。

【0080】

上記のようなレンダリング時間のクエリ操作において、クエリ時間を待つ操作が中央演算装置（ＣＰＵ）側で同期操作であるため、レンダリング時間を取得する待ち過程は、アプリケーションの性能に大きな影響を与える可能性がある。したがって、本願に係るＧＰＵリソース管理方法は、ＣＰＵがレンダリング命令を実行する時間で、ＧＰＵがクエリ結果を準備する時間を相殺することができる。

【0081】

図８Ａは、本願の実施形態に係る第１増分を決定する際のＣＰＵとＧＰＵのダブルバッファリング方法を示す概略図である。

【0082】

ＧＰＵにおける非交差クエリメカニズム、即ち、クエリの開始点と終了点が非交差クエリに含まれなければならないこと、つまり、複数の開始点を連続的に挿入することができないことを保証するために、本実施形態において、ＧＰＵが１回遅延して計算する方式でＣＰＵとＧＰＵとの間のインタラクション操作を実行する。図８Ａに示すように、ＣＰＵとＧＰＵのインデックスは、それぞれの処理順序を示し、ＣＰＵ２の処理は、ＧＰＵ１のクエリ時間に対応し、ＣＰＵ３の処理は、ＧＰＵ２のクエリ時間に対応する。このようなダブルバッファリング方式により、ＣＰＵがＧＰＵのクエリ時間だけ待つ期間のＣＰＵの処理性能を効果的に向上させる。しかし、ＣＰＵの処理がＧＰＵより速い可能性があり、ダブルバッファリングの方式により、依然としてＣＰＵの待ちを完全に避けることができない可能性があるため、上記ダブルバッファリング方法に基づいて、本願に係るＧＰＵ管理方法は、適応バッファリングメカニズムに基づいて、上記問題を解決することもできる。

【0083】

図８Ｂは、本願の実施形態に係る第１増分を決定する際のＣＰＵとＧＰＵの適応バッファリング方法を示す概略図である。

【0084】

適応バッファリングメカニズムにおいて、依然としてダブルバッファリングメカニズムを用いることができるが、前回の描画が完了することをクエリすることができない場合、前回の描画が必ず完了すると決定するまで、今回のクエリを終了しなくてもよく、この間に複数回の描画呼び出しを行ってもよい。

【0085】

適応バッファリング方法は、ダブルバッファリング方法に対して、クエリにおける描画呼び出しの回数を拡張し、クエリの１回の描画呼び出しをランダムな複数回の呼び出しに拡張するため、複数のアプリケーションプロセスを同時に処理する場合、システム精度が低下する可能性がある。これは、異なるアプリケーションプロセス間にクロスレンダリングが存在する可能性があり、ＧＰＵが現在のクエリ点の時間を読み取るにすぎず、異なるアプリケーションプロセスを区別することができないため、クエリが不正確になるからである。

【0086】

したがって、レンダリング命令キューのコミッションをよりよく制御するために、ＧＰＵのクエリ終了時に強制的にレンダリング命令バッファエリアに対して非同期リフレッシュを行ってもよく、これにより、大量の高速描画を生成し、このような描画は、適応バッファリング方法を使用する必要がなく、ＧＰＵのレンダリング時間結果を速く取得することができるが、これも通信伝送負荷を招く。通信効率を保証しつつ、複数のアプリケーションプロセス間の相互影響を低減するように、システム性能と精度のバランスを取るために、ダブルバッファリング方法の基本アルゴリズムと適応アルゴリズムとを組み合わせるモンテカルロアルゴリズムを用いることができ、確率論的統計学的方法により（最適解に対して）より良い解を得る。描画呼び出し回数又はシステム実行時間により、適応アルゴリズムからダブルバッファリング基礎アルゴリズムへの劣化を制限することができ、これらのパラメータの低い値は、通信性能の低下を招く可能性があり、高い値は、複数のアプリケーションプロセス間の影響を増加させる可能性があるため、モンテカルロアルゴリズムを用いることにより、システムの合理性をより一層保証することができる。

【0087】

図９Ａは、本願の実施形態に係るグラフィックスプロセッサのリソース管理方法３００を示す概略図である。図９Ａに示すように、グラフィックスプロセッサのリソース管理方法３００は、スケジューリングプロセス及びアプリケーションプロセスによりそれぞれ実行される２つの操作を含んでもよい。グラフィックスプロセッサのリソース管理方法３００は、主に以下のステップ(1)～(6)を含んでもよく、各ステップの番号は、図９Ａ中の符号に対応する。

【0088】

ステップ(1)では、スケジューリングプロセスを起動し、前記スケジューリングプロセスは、割り当てスレッド及び複数の処理スレッドを含んでもよい。

【0089】

図９Ａに示すように、スケジューリングプロセスは、１つの割り当てスレッド及び複数の処理スレッドを含んでもよく、割り当てスレッドは、ＧＰＵとアプリケーションプロセスの割り当て及びメッセージの配信に用いられてもよく、処理スレッドは、ＧＰＵのレンダリング時間処理に用いられてもよい。

【0090】

ステップ(2)では、前記割り当てスレッドにより、アプリケーションプロセスを処理可能な複数のグラフィックスプロセッサを決定する。

【0091】

以上より、アプリケーションプロセスの処理に現在使用可能な複数のＧＰＵを決定して、その後、各ＧＰＵに対するリソース割り当て管理を行うことができる。

【0092】

ステップ(3)では、前記複数のグラフィックスプロセッサの各グラフィックスプロセッサに１つの処理スレッドを割り当てる。

【0093】

図９Ａに示すように、現在決定される３つの使用可能なＧＰＵに対して、スケジューリングプロセスは、３つの処理スレッド１、２及び３をそれぞれ、この３つのＧＰＵのレンダリング時間処理に割り当てることができるため、後続の各ＧＰＵのリソース割り当ては、対応する処理スレッドによって実行することができる。

【0094】

ステップ(4)では、複数のアプリケーションプロセスを起動し、前記複数のアプリケーションプロセスの各アプリケーションプロセスは、前記スケジューリングプロセスによって予め構築されたスケジューリングライブラリを含んでもよい。

【0095】

任意選択で、該スケジューリングライブラリは、該複数のアプリケーションプロセスで共有されてよく、アプリケーションプロセスとスケジューリングプロセスとの情報のやり取りは、該スケジューリングライブラリによって実現されてもよい。アプリケーションプロセスが起動した後、スケジューリングライブラリは、該アプリケーションプロセスの情報をスケジューリングプロセスに送信して登録させることができ、アプリケーションプロセスの登録操作は、同期操作である。データの逆流を低減するために、登録後にアプリケーションプロセスは、メッセージを送信し続け、スケジューリングプロセスは、イベントを共有することによりアプリケーションプロセスに対する処理を通知することができる。

【0096】

ステップ(5)では、前記複数のアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスのスケジューリングライブラリ及び前記割り当てスレッドにより、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサ及び前記グラフィックスプロセッサに対応する処理スレッドを割り当てる。

【0097】

図９Ａに示すように、３つのアプリケーションプロセスにそのグラフィックレンダリング処理のためのＧＰＵを割り当てることができ、例えば、ＧＰＵ１には、グラフィックレンダリングのためにアプリケーションプロセス１及び２が割り当てられ、ＧＰＵ３には、グラフィックレンダリングのためにアプリケーションプロセス３が割り当てられ、ＧＰＵ２には、この３つのアプリケーションプロセスの処理が割り当てられない。スケジューリングプロセス上でアプリケーションプロセスの登録操作を完了した後、対応する登録情報、例えば、割り当てられたＧＰＵのインデックス及びそれに対応する処理スレッドなどの情報を各アプリケーションプロセスに返すことができる。

【0098】

ステップ(6)では、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する処理スレッドにより、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定して、前記アプリケーションプロセスへのリソース割り当て命令を決定し、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである。

【0099】

上記のようなスケジューリングサービスのレンダリング処理操作は、スケジューリングプロセスにおける対応する処理スレッドによって行うことができ、例えば、ＧＰＵ１に対応する処理スレッド１は、アプリケーションプロセス１及び２のレンダリング時間を処理することができ、現在の所定リソースにおけるこの２つのアプリケーションプロセスに使用可能な残りのリソース量を決定し、現在の所定リソースにおけるこの２つのアプリケーションプロセスに使用可能な残りのリソース量に基づいて、対応するリソース割り当て命令を決定することを含む。各アプリケーションプロセスは、対応するリソース割り当て命令を受信した後、前記リソース割り当て命令に基づいて、対応するＧＰＵに処理タスクを送信してＧＰＵに処理させるか否かを決定する。

【0100】

以上より、第１増分を取得する方式は、ＧＰＵによる処理タスクの処理方式によって異なる。例えば、非同期レンダリングの場合、第１増分は、スケジューリングライブラリがＧＰＵから信号インターセプションにより直接推定してもよく、同期レンダリングの場合、第１増分は、スケジューリングライブラリがＧＰＵからクエリ命令により取得してもよく、即ち、ＧＰＵからスケジューリングライブラリへの実線に沿って引き返す。

【0101】

本願の実施形態によれば、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられ、前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにする。上記のように、現在の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにすることにより、現在の所定リソースにおけるアプリケーションプロセスによって使用されるリソース量を所望のリソース量、即ち、そのリソース需要重みに対応するリソース需要量により近づけることができる。したがって、アプリケーションプロセスに対するオンデマンドリソース割り当てを実現し、ＧＰＵリソースの効率的な使用を実現することができる。

【0102】

図９Ｂは、本願の実施形態に係るグラフィックスプロセッサのリソース管理方法のスケジューリングロジックを示す概略図である。任意選択で、本願のグラフィックスプロセッサのリソース管理方法は、一般的なグラフィックスシステムの現在の設計に基づいて、それぞれスケジューリングクライアント（ＳｃｈｅｄｕｌｉｎｇＣｌｉｅｎｔ）、スケジューリングサービス（ＳｃｈｅｄｕｌｉｎｇＳｅｒｖｉｃｅ）及びスケジューリング（Ｓｃｈｅｄｕｌｉｎｇ）である３つのランタイムライブラリに関わる。そのうち、スケジューリングクライアントとスケジューリングサービスは、関数インジェクションと外部のイベントとの通信方式のみを処理し、コアロジックは、スケジューリングにある。図９Ｂに示すように、図９Ｂ中の様々な関数（例えば、ＲｅｓｏｕｒｃｅＳｃｈｅｄｕｌｉｎｇ、ＳｃｈｅｄｕｌｉｎｇＰｒｏｔｏｃｏｌなど）を呼び出して、レンダリング時間を収集して計算し、レンダリング時間に基づいてレンダリングするか否かを計算することにより、各アプリケーションプロセスへのリソース割り当て命令を決定してもよい。

【0103】

図１０は、本願の実施形態に係るグラフィックスプロセッサのリソース管理装置１０００を示す概略図である。

【0104】

前記グラフィックスプロセッサのリソース管理装置１０００は、プロセッサ決定モジュール１００１と、プロセッサ割り当てモジュール１００２と、残りリソース決定モジュール１００３と、リソース割り当てモジュール１００４とを含んでもよい。

【0105】

本願の実施形態によれば、プロセッサ決定モジュール１００１は、アプリケーションプロセスを処理可能な複数のグラフィックスプロセッサを決定するように構成されてもよい。

【0106】

任意選択で、プロセッサ決定モジュール１００１は、上述したステップ２０１で説明した動作を実行してもよい。

【0107】

任意選択で、アプリケーションプロセスは、ゲームプロセス、ビデオプロセス、及び会議プロセスなどの様々なアプリケーションプロセスであってもよく、それに対応して、ゲームインスタンスなどのアプリケーションプロセスのグラフィックレンダリングタスクについて、決定されたＧＰＵは、一定のレンダリング計算を実行する能力を有するＧＰＵであるべきである。

【0108】

プロセッサ割り当てモジュール１００２は、処理対象の複数のアプリケーションプロセスを取得し、前記複数のアプリケーションプロセスの各アプリケーションプロセスに、前記複数のグラフィックスプロセッサのうちの１つのグラフィックスプロセッサを割り当てるように構成されてもよい。

【0109】

任意選択で、プロセッサ割り当てモジュール１００２は、上述したステップ２０２で説明した動作を実行してもよい。

【0110】

任意選択で、各ユーザ端末がアプリケーションを起動した後、サーバ側は、対応するアプリケーションプロセスをそれぞれ登録することができ、各アプリケーションプロセスにそのグラフィックレンダリング処理用のＧＰＵを割り当てることを含む。ＧＰＵの計算性能の制限を満たすことを保証する場合、複数のアプリケーションプロセスを同一のＧＰＵに割り当てることができ、即ち、同一のＧＰＵ上で複数のアプリケーションプロセスの処理タスクを同時に実行するが、ＧＰＵに割り当てられる負荷は、該ＧＰＵの計算性能の制限を超えてはいけない。

【0111】

残りリソース決定モジュール１００３は、１つのグラフィックスプロセッサに割り当てられる少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記グラフィックスプロセッサの現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するように構成されてもよく、前記使用可能な残りのリソース量は、前記グラフィックスプロセッサの過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量に関連付けられる。

【0112】

任意選択で、残りリソース決定モジュール１００３は、上述したステップ２０３で説明した動作を実行してもよい。過去の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量に基づいて、現在の所定リソースにおけるその使用可能な残りのリソース量を決定することにより、過去のリソース割り当てにおける誤差に基づいて、現在のリソース割り当てを調整して、該リソース割り当ての誤差を低減し、さらに解消することができる。

【0113】

リソース割り当てモジュール１００４は、前記現在の所定リソースにおける前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに使用可能な残りのリソース量に基づいて、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスへのリソース割り当て命令を決定するように構成されてもよく、前記リソース割り当て命令は、前記アプリケーションプロセスに対して処理を行うか否かを指示するものである。前記リソース割り当て命令は、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにするために用いられる。

【0114】

任意選択で、リソース割り当てモジュール１００４は、上述したステップ２０４で説明した動作を実行してもよい。上記のように、現在の所定リソースにおけるアプリケーションプロセスに使用可能な残りのリソース量が所定の目標値に達するようにすることにより、現在の所定リソースにおけるアプリケーションプロセスによって使用されるリソース量を所望のリソース量、即ち、そのリソース需要重みに対応するリソース需要量により近づけることができる。したがって、アプリケーションプロセスに対するオンデマンドリソース割り当てを実現し、ＧＰＵリソースの効率的な使用を実現することができる。

【0115】

一実施形態において、前記複数のアプリケーションプロセスの各アプリケーションプロセスは、所定のリソース需要重みを有し、前記装置は、
前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を取得し、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量を決定するように構成される使用済みリソース決定モジュールをさらに備え、
前記残りリソース決定モジュールは、さらに、前記過去の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量、及び前記アプリケーションプロセスのリソース需要重みに基づいて、前記現在の所定リソースにおける前記アプリケーションプロセスに使用可能な残りのリソース量を決定するように構成され、
前記リソース割り当て命令は、前記アプリケーションプロセスの第１誤差を第２誤差よりも大きくするために用いられ、前記第１誤差は、前記アプリケーションプロセスのリソース需要重みと、前記過去の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差であり、前記第２誤差は、前記アプリケーションプロセスのリソース需要重みと、前記現在の所定リソースにおける前記アプリケーションプロセスによって使用されるリソースの割合との誤差である。

【0116】

一実施形態において、前記リソース割り当て命令は、対応するアプリケーションプロセスが対応するグラフィックスプロセッサに処理タスクを送信して前記グラフィックスプロセッサに処理させるか否かを指示するものであり、前記グラフィックスプロセッサによる前記処理タスクの処理は、前記アプリケーションプロセスによる前記グラフィックスプロセッサのリソースの使用に対応し、
前記使用済みリソース決定モジュールは、さらに、前記現在の所定リソースにおける前記アプリケーションプロセスの使用済みリソース量の第１増分を決定するように構成され、前記第１増分は、前記アプリケーションプロセスに対応するグラフィックスプロセッサによる前記アプリケーションプロセスからの処理タスクの前回の処理に対応する。

【0117】

一実施形態において、前記リソース割り当てモジュールは、さらに、前記少なくとも１つのアプリケーションプロセスの各アプリケーションプロセスに対して、前記アプリケーションプロセスに対応する現在の所定リソースにおける使用可能な残りのリソース量がゼロ以下である場合、前記アプリケーションプロセスへのリソース割り当て命令が前記アプリケーションプロセスに対して処理を行わないことを指示すると決定し、前記少なくとも１つのアプリケーションプロセスのうち、使用可能な残りのリソース量がゼロより大きい他のアプリケーションプロセスに対して、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するように構成される。

【0118】

一実施形態において、前記他のアプリケーションプロセスの各アプリケーションプロセスの優先度は、前記アプリケーションプロセスの処理待ち時間の長さ、及びその最新の第１増分を決定する時間的順序に関連付けられ、
前記リソース割り当てモジュールは、さらに、前記他のアプリケーションプロセスの各アプリケーションプロセスに対して、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在する場合、前記アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、前記アプリケーションプロセスへのリソース割り当て命令を決定し、処理待ち時間の長さが所定の条件を満たすアプリケーションプロセスが存在しない場合、前記他のアプリケーションプロセスの各アプリケーションプロセスの最新の第１増分を決定する時間的順序に基づいて、各アプリケーションプロセスへのリソース割り当て命令を決定するように構成される。

【0119】

本願の別の態様によれば、グラフィックスプロセッサのリソース管理機器をさらに提供する。図１１は、本願の実施形態に係るグラフィックスプロセッサのリソース管理機器２０００の概略図を示す。

【0120】

図１１に示すように、前記グラフィックスプロセッサのリソース管理機器２０００は、１つ又は複数のプロセッサ２０１０と、１つ又は複数のメモリ２０２０とを含んでもよい。前記メモリ２０２０には、コンピュータ読み取り可能なコードが記憶され、前記コンピュータ読み取り可能なコードが前記１つ又は複数のプロセッサ２０１０によって実行されると、上記のようなグラフィックスプロセッサのリソース管理方法が実行されることができる。

【0121】

本願の実施形態に係るプロセッサは、信号処理能力を有する集積回路チップであってもよい。上記プロセッサは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は他のプログラマブルロジックデバイス、ディスクリートゲート又はトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントであってもよい。本願の実施形態に開示される各方法、ステップ及びロジックブロック図を実現又は実行することができる。汎用プロセッサは、マイクロプロセッサ又は任意の一般的なプロセッサなどであってもよく、Ｘ８６アーキテクチャ又はＡＲＭアーキテクチャであってもよい。

【0122】

一般的に、本願の様々な例示的な実施形態は、ハードウェア又は専用回路、ソフトウェア、ファームウェア、ロジック、又はそれらの任意の組み合わせで実施されてもよい。いくつかの態様は、ハードウェアで実施され、他の態様は、コントローラ、マイクロプロセッサ、又は他のコンピューティング機器によって実行され得るファームウェア又はソフトウェアで実施されてもよい。本願の実施形態の様々な態様は、ブロック図、フローチャート、又は他の何らかの画像表現を使用して例示及び説明されたが、本明細書に記載されるこれらのブロック、装置、システム、技術又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又はロジック、汎用ハードウェア又はコントローラ又は他のコンピューティング機器、又はそれらのいくつかの組み合わせで実施されてもよいことを理解されたい。

【0123】

例えば、本願の実施形態に係る方法又は装置は、図１２に示すコンピューティング機器３０００のアーキテクチャによって実現されてもよい。図１２に示すように、コンピューティング機器３０００は、バス３０１０と、１つ又は複数のＣＰＵ３０２０と、リードオンリーメモリ（ＲＯＭ）３０３０と、ランダムアクセスメモリ（ＲＡＭ）３０４０と、ネットワークに接続される通信ポート３０５０と、入力／出力コンポーネント３０６０と、ハードディスク３０７０とを含んでもよい。コンピューティング機器３０００における記憶機器、例えば、ＲＯＭ３０３０又はハードディスク３０７０は、本願に係るグラフィックスプロセッサのリソース管理方法の処理及び／又は通信に用いられる様々なデータ又はファイル、及びＣＰＵにより実行されるプログラム命令を記憶することができる。コンピューティング機器３０００は、ユーザインタフェース３０８０をさらに含んでもよい。もちろん、図１１に示すアーキテクチャは、例示的なものに過ぎず、異なる機器を実現する場合、実際の必要に応じて、図１２に示すコンピューティング機器における１つ又は複数のコンポーネントを省略することができる。

【0124】

本開示の別の態様によれば、コンピュータ読み取り可能な記憶媒体をさらに提供する。図１３は、本願に係る記憶媒体の概略図４０００を示す。

【0125】

図１３に示すように、前記コンピュータ記憶媒体４０２０には、コンピュータ読み取り可能な命令４０１０が記憶される。前記コンピュータ読み取り可能な命令４０１０がプロセッサによって実行されると、以上の図面を参照して説明した本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を実行することができる。本願の実施形態に係るコンピュータ読み取り可能な記憶媒体は、揮発性メモリ又は不揮発性メモリであってもよく、揮発性メモリ及び不揮発性メモリの両方を含んでもよい。不揮発性メモリは、リードオンリーメモリ（ＲＯＭ）、プログラマブルリードオンリーメモリ（ＰＲＯＭ）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）又はフラッシュメモリであってもよい。揮発性メモリは、外部キャッシュとして用いられるランダムアクセスメモリ（ＲＡＭ）であってもよい。制限的ではなく、例示的な説明によって、多くの形式のＲＡＭが使用でき、例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）、ダブルデータレート同期式ダイナミックランダムアクセスメモリ（ＤＤＲＳＤＲＡＭ）、強化型同期ダイナミックランダムアクセスメモリ（ＥＳＤＲＡＭ）、同期リンクダイナミックランダムアクセスメモリ（ＳＬＤＲＡＭ）及びダイレクトランバスランダムアクセスメモリ（ＤＲＲＡＭ）が挙げられる。なお、本明細書で説明された方法のメモリは、これら及び任意の他の適切なタイプのメモリを含むが、それらに限定されないことを意図する。なお、本明細書で説明された方法のメモリは、これら及び任意の他の適切なタイプのメモリを含むが、それらに限定されないことを意図する。

【0126】

本願の実施形態によれば、コンピュータ命令を含み、該コンピュータ命令は、コンピュータ読み取り可能な記憶媒体に記憶される、コンピュータプログラム製品又はコンピュータプログラムがさらに提供される。コンピュータ機器のプロセッサは、コンピュータ読み取り可能な記憶媒体から該コンピュータ命令を読み取り、プロセッサは、該コンピュータ命令を実行して、該コンピュータ機器に本願の実施形態に係るグラフィックスプロセッサのリソース管理方法を実行させる。

【0127】

本願の実施形態は、グラフィックスプロセッサのリソース管理方法、装置、機器、コンピュータ読み取り可能な記憶媒体及びコンピュータプログラム製品を提供する。

【0128】

【0129】

【0130】

なお、図面におけるフローチャート及びブロック図は、本願の様々な実施形態に係るシステム、方法及びコンピュータプログラム製品の実現可能なアーキテクチャ、機能及び操作を示す。これに関して、フローチャート又はブロック図における各ブロックは、１つのモジュール、プログラムセグメント又はコードの一部を表すことができ、前記モジュール、プログラムセグメント又はコードの一部は、規定されたロジック機能を実現するための少なくとも１つの実行可能な指令を含む。なお、いくつかの代替的な実現において、ブロックで表示された機能は、図面で表示された順序と異なる順序で発生することができる。例えば、連続して示された２つのブロックは、実際には、基本的に並行して実行される場合や、逆の順序で実行される場合があり、これは、関連する機能によって決定される。ブロック図及び／又はフローチャートにおける各ブロック、及びブロック図及び／又はフローチャートにおけるブロックの組み合わせは、規定された機能又は操作を実行する専用のハードウェアに基づくシステムによって実現されてもよく、専用のハードウェアとコンピュータ命令の組み合わせによって実現されてもよいことにも留意されたい。

【0131】

【0132】

以上で詳細に説明したような本願の例示的な実施形態は、例示的なものに過ぎず、限定的なものではない。当業者であれば、本願の原理及び精神から逸脱することなく、これらの実施形態又はその特徴に対して様々な修正及び組み合わせを行うことができ、このような修正が本願の範囲内にあることを理解すべきである。

【図1】