JP2013041361A - リソース調停システム及び調停方法 - Google Patents

Abstract

【課題】複数のデバイス（例えば、プロセッサ等）が使用するリソース調停システムにおいて、デバイスの処理への影響を抑制しつつ、効果的なリソースの割り付けを可能とする。
【解決手段】
リソース毎に設けられ、リソースが属するグループを示す第１の識別子ｇｉｄ＿ｒｓを有するリソースレジスタ１０と、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子ｇｉｄ＿ｒｑを有するリクエストレジスタ１１とを備えている。第１のデバイスが実行予定の処理について、予約用グループを示す第２の識別子ｇｉｄ＿ｒｑを有する第１のリクエストがなされ、第１のリクエストを受けた第１のリソースが解放されたとき、第１のリソースに係る第１の識別子ｇｉｄ＿ｒｓを、予約用グループを示すものに変更し、第１のリソースに係る第１の識別子ｇｉｄ＿ｒｓがすべて予約用グループを示すものに変更されたとき、その情報を第１のデバイスに通知する。
【選択図】図２

Description

本発明は、プロセッサ、ハードウェアアクセラレータ及びリソースを含むシステムの動作に関し、特にリソースを調停するシステム及び調停の方法に関する。

ＤＴＶ、ムービー及び携帯電話といった動画や音声を扱うメディア処理では、複数のプロセッサ、複数のハードウェアアクセラレータ、メモリ、入出力デバイス、通信デバイス及びグラフィック用デバイス等からなるシステムが用いられている。一般的に、このシステムによって処理されるアプリケーションは複数あるとともに、使用するアプリケーションはユースケース毎に異なっており、更に複数の処理が同時に行われるケースが多い。例えば、動画ストリーム数の増減や同時録画の開始等、システムに要求される処理はユースケースに応じて変化する。

したがって、最適なプロセッサ性能、アクセラレートするために必要とされるハードウェアアクセラレータの種別、及び最適なメモリサイズ等は、ユースケースに応じて異なったものとなる。このため、複数のユースケースを処理するためには、限られたリソースを効果的に配分する仕組みが必要である。例えば、リソースのうちの１つであるメモリには共有メモリ、物理的に異なるメモリデバイス及び古典的なページング技術による複数のページ等のように様々なタイプのものがあり、バスアクセスの権利として扱われることもあるが、これらを効果的に利用する必要がある。ここで、リソースとは、プロセッサから見たハードウェアアクセラレータ、メモリ及び入出力デバイス等であり、リソースはプロセッサによって管理されるとともに、必要に応じてプロセッサから利用される。また、プロセッサも複数あり、アプリケーションに要求されるプロセッサ数もユースケースに応じて異なり一様ではない。

従来の調停システムとしては、例えば、複数のプロセッシング要素と小規模かつシンプルなハードウェアアクセラレータとを用いたシステムにおいて、選択されたハードウェアアクセラレータへのアクセスを可能とするためのビットをレジスタに設けたものや（例えば、特許文献１）、デバイス上の共有リソースを動的に調停するシステムなどがある（例えば、特許文献２参照）。

具体的には、特許文献１に開示された調停システムは、プロセッシング要素により設定されたレジスタに従って選択されたハードウェアアクセラレータに対して、プロセッシング要素の所有権を付与することにより、プロセッシング要素からハードウェアアクセラレータへのアクセスを可能とするものである。

特許文献２に開示された調停システムは、リソースの割り付けをリクエストするリクエストアプリケーションと、リソースを所有する所有アプリケーションとを備えており、現在の所有者がリソースのリリース先として望んでいるアプリケーションやグループを識別するリストを備えている。そして、所有アプリケーションに関する情報である所有者情報をリクエストアプリケーションに関する情報であるリクエスト者情報に関連付けてリソース単位での調停を行うものである。

特表２００７−５２０７６６号公報 特表２００８−５００６４８号公報

しかしながら、規模が大きく複雑な（不均質な）ハードウェアアクセラレータ(リソース）からなるシステムでは、プロセッサ毎に利用するリソース数も不均質であり、共有して使用するリソースと供給しないリソースとが混在する。特許文献１の調停システムは、このようなシステムにおいてリソース割り付けを調停するのに好適ではない。

また、論理的に１つの機能を実行（処理）するためには所定のリソースを確保する必要があり、リソースをまとめて確保したいリクエスト者にとっては、一括して確保できるか、そうでないかが重要である。特許文献１の調停システムは、このような一括した確保に対する開示はなされていない。

特許文献２の調停システムは、所有者情報をリクエスト者情報に関連付けて、リソース単位でリソースを現在の所有者から確保する技術であるが、このようにリソース単位で現在の所有者からリソースを確保する場合、各リソースの所有者への解放要求等の通知が必要であり、所有者の現在の処理に影響を与えてしまうこととなる。また、リソース単位で所有者からリソースを確保するよりも、解放されたリソースが所定数を満たした段階で一括して確保した方が効果的なリソースの割り付けが可能となる。

さらに、リソースのうちの１つであるメモリには、プロセッサが計算に用いるワークメモリのように局所的に共有されることなく使用されるメモリだけでなく、複数のプロセッサから同一のプログラムコードが格納されるページとして共有されるメモリがある。また、異なるアプリケーション間でのデータ受け渡し時に共有メモリがデータフローを構成する場合がある。

特許文献２では、共有リソースの管理に対する開示がされていない。具体的には、所有者情報とリクエスト者情報とが異なる場合におけるリソース共有の概念が開示されていない。従って、所有者情報とリクエスト者情報とが異なるリクエストが発生した場合に、同一機能の最優先処理に対するリソースの割り付けと、異なる機能の優先処理に対するリソースの割り付けとを両立することができない。その結果、効果的なリソースの割り付けができないという課題がある。

上記の点に鑑み、本発明は、複数のデバイスが使用するリソースを調停するリソース調停システムにおいて、デバイス（例えば、リクエストされたリソースを所有するデバイスやリクエスト主体となるデバイス）の処理への影響を抑制しつつ、効果的なリソースの割り付けを可能とするリソース調停システムを提供することを目的とする。

本発明の第１態様は、プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するリソース調停システムであって、１つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第１の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子を少なくとも有するリクエストレジスタとを備えている。前記リソース調停システムは、第１のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第２の識別子を有する第１のリクエストがなされた場合において、前記第１のリクエストの対象となる第１のリソースが解放されたとき、当該第１のリソースのリソースレジスタの前記第１の識別子を、前記予約用グループを示すものに変更し、前記第１のリクエストの対象となるすべての前記第１のリソースについてリソースレジスタの前記第１の識別子が前記予約用グループを示すものに変更されたとき、その情報を前記第１のデバイスに通知する。

この第１態様によると、リソース調停システムは、第１のリクエストの対象となる第１のリソースが解放されたとき、予約用グループに第１のリソースを確保し、第１のリクエストの対象となるすべての第１のリソースについてリソースレジスタの第１の識別子が予約用グループを示すものに変更されたとき、その情報を第１のデバイスに通知する。このように、リソースが解放されてから予約用グループにリソースを確保（第１の識別子を予約用グループを示すものに変更）するため、現在の所有者（デバイス）へのリソースの解放要求を出していない。また、第１のデバイスはすべての第１のリソースが確保されてから、その情報の通知を受けるので、すべての第１のリソースが確保されたのを確認してから実行予定の処理を開始することができる。これにより、第１のリソースがすべて使用可能となったときに処理が開始でき、例えば、処理の途中にリソースが不足して処理の中断や待ちの状態になることを回避できる。一方で、デバイス及びリソースがすべて使用可能でなければ、例えば、デバイスが別の処理を行うなどの判断材料とできる。このように、本態様のリソース調停システムは、現在の所有者への影響を抑制しつつ、効果的にリソースを割り付けることができる。

そして、前記第１態様のリソース調停システムは、前記第１のリクエストの対象となる前記第１のリソースが解放されたとき、当該第１のリソースのリソースレジスタの前記第１の識別子を、未使用の空きグループを示すものに一旦変更した後、前記予約用グループを示すものに変更するのが好ましい。

そして、前記第１態様のリソース調停システムは、第２のデバイスが実行予定の処理についてなされた第２のリクエストにおいて、当該第２のリクエストに係る前記第２の識別子が示す第１のグループと、前記第２のリクエストの対象となる第２のリソースのリソースレジスタの前記第１の識別子が示す第２のグループとが同じ場合、前記第２のリソースの解放後、前記第２のデバイスに前記第２のリソースを割り付ける一方、前記第１のグループと前記第２のグループとが異なる場合、前記第２のリソースが解放され、かつ、当該第２のリソースのリソースレジスタの前記第１の識別子が前記空きグループを示すものに変更された後に、前記第２のデバイスに前記第２のリソースを割り付けるのが好ましい。

このように、第２のリソースが属する第２のグループと第２のデバイスが属する第１のグループとが異なる場合は、空きグループを介して割り付けることにより、すべてのグループのデバイスからのリクエストに対する優先順位等を考慮した最適な（効果的な）リソースの割り付けを実現することができる。一方、第２のリソースが属する第２のグループと第２のデバイスが属する第１のグループとが同じ場合、第２のリソースの解放後に（空きグループを介さない）第２のデバイスへの第２のリソースの割り付けを実施することにより、同じグループ内でのリソースの割り付けを他グループのデバイスからのリクエストの影響を受けずに割り付け及び処理の開始をすることが可能となるとともに、処理中の他グループのデバイスにその影響が及ばない。

そして、前記第１態様のリソース調停システムは、同一のリソースに対する複数のリクエストの優先順位を、所定の条件に基づいて、決定するのが好ましい。

これにより、例えば先ほどの予約用グループへの第１のリソースの割り付けを優先順位を高く設定して行うことができる。これにより、予約用グループに第１のリソースが一括して確保（割り付け）されるまでの時間が短縮される。また、例えばリソースのうち確保するまで処理が実行できないリソースがある場合等にそのリソースの優先順位を高く設定することができる。このように、一括確保されるまでの時間短縮や処理の実行に不可欠なリソースの優先確保等が実現され、さらに効果的なリソースの割り付けが可能となる。

そして、前記第１態様のリソース調停システムのリソースレジスタは、所定の条件に合致する前記リソースからなるリソースグループに属するか否かを示す第５の識別子を有するのが好ましい。そして、複数の前記デバイスによる共有が可能な共有リソースは、前記リソースレジスタが、共有可能数と同数設けられており、前記共有リソースの各リソースレジスタの前記第５の識別子は、同一リソースグループに属することを示しているのが好ましい。そして、前記第１態様のリソース調停システムは、前記共有リソースが異なる２つ以上の前記グループに属することの許可又は不許可を示す第６の識別子を少なくとも有するグローバルレジスタを備えており、前記リソースレジスタは、前記リソースが所有されているか否かを示す第９の識別子を有しており、前記リソースが解放されたとき、前記第１及び第９の識別子の少なくともいずれか一方が、リソースの解放を示すものであるのが好ましい。そして、前記第１態様のリソース調停システムは、前記第６の識別子が前記許可を示す前記共有リソースは、当該共有リソースへの第２のリクエストに係る前記第２の識別子が示すグループに関わらず、前記共有可能数の範囲内において前記第２のリクエスト毎にそれぞれ調停される一方、前記第６の識別子が前記不許可を示す前記共有リソースは、当該共有リソースへの前記第２のリクエストに係る前記第２の識別子が示す第１のグループと、前記共有リソースの各リソースレジスタの前記第１の識別子が示す第２のグループのうちの少なくとも１つとが異なるとき、当該第１の識別子が前記第１グループと異なるグループを示した前記リソースレジスタがすべて解放を示した後に調停されるのが好ましい。

このように、グループを越えた共有を許可するか否かを判別して、リソースの割り付けを管理することにより、リソースをグループを越えて活用（共有）することができる。これにより、さらに効果的なリソースの割り付けが可能となる。

そして、前記第１態様のリソース調停システムは、第２のデバイスが実行予定の処理についてなされた第２のリクエストにおいて、当該第２リクエストに係る前記第２の識別子が示すグループと、前記第２のリクエストの対象となる、第３のデバイスに割り付けられた第２のリソースのリソースレジスタの前記第１の識別子が示すグループとが同一か否か、及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて、前記第３のデバイスへの前記第２のリソースの解放要求の通知並びに前記第２のデバイスへの競合発生の通知、調停によるリソース確保ありの通知及び調停によるリソース確保なしの通知のうちの少なくともいずれか１つの通知を行うか否かを決定するのが好ましい。

このように、第２リクエストに係る第２の識別子が示すグループと、第２のリクエストの対象となる第２のリソースが属するグループとが同一か否か及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて通知を実施することにより、第２のリソースの所有者である第３のデバイスの処理への影響を抑制することができる。例えば、優先順位が所定の優先順位よりも低いリクエストに関する各通知を行わないこととすれば、各通知による第２のデバイス及び第３のデバイスの処理への影響を与えずにすむ。

本発明の第２態様は、プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するシステムにおけるリソース調停方法であって、前記システムは、１つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第１の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子を少なくとも有するリクエストレジスタとを備え、前記リソース調停方法は、第１のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第２の識別子を有する第１のリクエストがなされた場合において、前記第１のリクエストの対象となる第１のリソースが解放されたとき、前記第１のリソースのリソースレジスタの前記第１の識別子を、前記予約用グループを示すものに変更するステップと、前記第１のリクエストの対象となるすべての前記第１のリソースについてリソースレジスタの前記第１の識別子が前記予約グループを示すものに変更されたとき、その情報を前記第１のデバイスに通知するステップとを備えている。

本発明によれば、実行予定の処理のグループに割り付けられたデバイス及びリソースを、デバイスの処理（機能の実行）への影響を抑制しつつ、一括して確保することができる。これにより、例えばリクエストされたリソースを所有するデバイスやリクエスト主体となるデバイス（リクエストにおいてリソースの割り付け先となるデバイス）のようなデバイスの処理への影響を抑制しつつ、効果的にリソースを割り付けることが可能なリソース調停システムを提供することができる。

本発明の実施形態に係るリソース調停システムの構成を示す図である。 本発明の実施形態に係るレジスタの構成例を示す図である。 構成要素例及びそれらの識別子を示す図である。 本発明の実施形態に係るリソース割り付け状況を示す図である。 図４のケース０におけるリソースレジスタの設定値を示す図である。 図４のケース０からケース１における調停後のリソースレジスタの設定値を示す図である。 図４のケース１からケース２における調停後のリソースレジスタの設定値を示す図である。 図４のケース２からケース３における調停後のリソースレジスタの設定値を示す図である。

以下、本発明の実施形態について図面を参照しながら説明する。

図１は本発明の一実施形態に係る調停システムの構成例を示す図である。

図１において、プロセッサ１とハードウェアアクセラレータ２とリソース３とは、選択ユニット４に接続されている。

プロセッサ１は、ハードウェアアクセラレータ２及びリソース３を使って、映像処理、音声処理及びグラフィック処理等を実行するデバイスである。

ハードウェアアクセラレータ２は、映像処理、音声処理及びグラフィック処理等の主要部分あるいはすべてをアクセラレートするためにハードウェア化されており、プロセッサ１から制御される。

リソース３は、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、及びプロセッサ１とハードウェアアクセラレータ２とリソース３との接続バス等からなる。また、本実施形態においては、プロセッサ１から見たハードウェアアクセラレータ２もリソースに含むものとする。すなわち、ハードウェアアクセラレータ２は、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、及び接続バス等のリソース３を使用して映像処理及び音声処理等の処理を行うデバイスである一方、プロセッサ１から制御されるリソースでもある。本実施形態において、デバイスとは、プロセッサ１及びハードウェアアクセラレータ２を指すものとする。

実行する処理に応じて、必要なプロセッサ１の数、ハードウェアアクセラレータ２の数及びタイプ並びにリソース３の数等は異なる。

なお、リソース３の１つであるメモリは、複数のデバイス（プロセッサ１及びハードウェアアクセラレータ２）からのアクセスが同時に可能な共有リソース（共有メモリ）であってもよい。例えば、２つのハードウェアアクセラレータ２からのリードとライトとが同時に可能なメモリであってもよい。これにより、例えば、ハードウェアアクセラレータ２がメモリにライトしたデータを、他のハードウェアアクセラレータ２がリードすることができる。

また、リソース３の１つであるメモリは、物理メモリに限定されず、アドレス管理された論理アドレスの一部分であってもよいし、ページング方式やセグメント方式に基づいて管理されるメモリの一部分であってもよい。

また、共有リソースはメモリに限定されない。例えば、共有リソースは時分割で利用される入出力デバイスや、ハードウェアアクセラレータ２であってもよい。例えば、共有リソースとして使用されるハードウェアアクセラレータ２は、複数のプロセッサ１から利用され、データ処理、映像処理及び音声処理などの複数の処理を並列に実行し、異なる処理結果を生成するものであってもよい。

選択ユニット４は、内部に有するレジスタ５の情報（後述の各識別子）に基づいて、リソース３を所有するデバイス１，２への解放要求を通知する。また、リソース３の使用要求であるリクエストを受け、調停によりリソース３を割り付けるデバイス１，２を決定し、決定したデバイス１，２からリソース３へのアクセスが可能となるように接続関係を変更する。なお、以下ではリソース３を割り付けたデバイス１，２をそのリソース３の所有者１，２と記載し、デバイス１，２からリソース３へアクセスができる状態を、デバイスがリソース３を所有している、又は確保していると記載する。

具体的には、例えば、プロセッサ１とリソース３（ハードウェアアクセラレータ２を含む）との間の制御バスや、ハードウェアアクセラレータ２とリソース３（ハードウェアアクセラレータ２は含まない）との間のデータバス等の物理的な接続が変更される。なお、接続関係の変更は物理的な接続の変更に限定されない。例えば、プロセッサ１から特定のリソース３（ハードウェアアクセラレータ２を含む）に関するアクセス権や、ハードウェアアクセラレータ２から特定のリソース３（ハードウェアアクセラレータ２を含まない）へのアクセス権が変更されることによっても、接続関係の変更がなされる。

また、本実施形態では、後述する１つの機能の処理を実行するために割り付けられたデバイス１，２及びリソース３の集まりであるグループがあり、選択ユニット４はこのグループによるリソース３の割り付けの管理を行う。また、実行予定の処理に必要なリソース３を割り付ける予約用グループに対してのリソース３の割り付けも行う。

そして、選択ユニット４とリクエストを行ったデバイス１，２（以下リクエスト者１，２と記載する。）との間では、リソース３のリクエスト、調停及び解放に係る情報を交換する。例えば、リクエスト及びリクエスト者１，２を示す情報、リクエストに対する調停結果、競合を示す情報及び所有するリソース３の解放要求を示す情報等を交換する。デバイス１，２は、この選択ユニット４と交換する情報をリソース３の解放の判断材料とする。

＜レジスタ＞
図２は、本実施形態に係るレジスタ５の構成例を示す図である。レジスタ５は、プロセッサ１及びハードウェアアクセラレータ２並びに選択ユニット４からリード及びライト（設定及び更新）ができる。本実施形態では、レジスタ５はリソースレジスタ１０、リクエストレジスタ１１及びグローバルレジスタ１２を備えている。

リソースレジスタ１０はリソース３毎に設けられる。例えば、リソース３がｎ個（ｎは自然数）の場合、リソースレジスタ１０はｎ個用意される。そして、リソースレジスタ１０は、リソース３が属するグループを示す第１の識別子であるリソースグループビット（ｇｉｄ＿ｒｓ）、リソース３が割り付けられたデバイス１，２又はリソース３の割り付け先の候補となるデバイス１，２である候補デバイスを示す第３の識別子であるリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）、リソース３が所有されているか否かを示す第９の識別子である所有ビット（ｏｗｎｅｒｓｈｉｐ：以下ｏｗｎｅｒと表記する）、所定の条件に合致するリソース３からなるリソースグループｒｇ０〜ｒｇ３に属するか否かを示す第５の識別子である特定リソースビット（ｒｇ０〜ｒｇ３）、及びリソース３が異常であることを示す第８の識別子であるエラービット（ｅｒｒｏｒ）を有している。

本実施形態では、特定リソースビット（ｒｇ０〜ｒｇ３）は、後述する共有リソースの共有可能数用意された各リソースレジスタが同一の共有リソースに属するか否かを示すもの（ｒｇ０，ｒｇ１）、及び各処理の実行に必要なリソースの集まりを示すもの（ｒｇ２，ｒｇ３）を含んでいる。なお、特定リソースビット（ｒｇ０〜ｒｇ３）が示す各リソースグループを構成するリソース３の条件は、ここで述べたものに限らない。

なお、共有リソース３については、複数となる所有者１，２を識別するために、共有可能な所有者１，２と同数のリソースレジスタ１０が用意される。

リクエストレジスタ１１は、リソース３の使用を要求するリクエストを格納するものである。本実施形態では、リクエスト毎にリクエストレジスタは設けられる。したがって、デバイス１，２からｍ個（ｍは自然数）のリクエストが発生した場合、リクエストレジスタ１１がｍ個用意される。なお、リソースレジスタ及びリクエストレジスタを各１個用意し、それぞれ領域を分割してリソース及びリクエストを管理してもよいし、リソース間及びリクエスト間で所定のビットを共有して使用してもよい。

そして、リクエストレジスタ１１は、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子であるリクエストグループビット（ｇｉｄ＿ｒｑ）、リクエスト対象となるリソースを割り付けるデバイスを示す第１０の識別子であるビット（ｒｑｉｄ＿ｒｑ）、リクエストの優先順位を示す第４の識別子である優先順位ビット（ｐｒｉｏｒｉｔｙ）、及びリクエストの対象であるリソース３又はリソースグループｒｇ０〜ｒｇ３を示す第７の識別子であるリクエスト対象ビット（ｒｉｄ）を有している。

グローバルレジスタ１２は、リソースグループｒｇ０〜ｒｇ３のリソース３について、異なるグループのデバイス１，２による共有の許可又は不許可を示す第６の識別子である共有ビット（ｒｇ０＿ｔｙｐｅ〜ｒｇ３＿ｔｙｐｅ）を有している。

また、図２には各レジスタ１０，１１，１２の初期値（ｉｎｉｔｉａｌ）の一例を記載している。

＜構成要素＞
図３は本実施形態に係る調停システムの構成要素例を示す図である。

図３（ａ）に示すように、リソースのリクエスト者は、デバイスであるプロセッサＰＥ０〜ＰＥ３（図１におけるプロセッサ１）及びハードウェアアクセラレータＨＡ０〜ＨＡ２（図１におけるハードウェアアクセラレータ２）からなり、リソースレジスタ１０におけるリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）及びリクエストレジスタ１１におけるビット（ｒｑｉｄ＿ｒｑ）に設定される識別子ｒｑｉｄによって識別される。本実施形態では、識別子ｒｑｉｄとして、プロセッサＰＥ０〜ＰＥ３にはそれぞれ“０”〜“３”が付与されており、ハードウェアアクセラレータＨＡ０〜ＨＡ２にはそれぞれ“４”〜“６”が付与されている。また、リクエスト者が“未設定”であることを示す識別子ｒｑｉｄとして“１５”が付与されている。なお、識別子ｒｑｉｄはあらかじめ付与されていてもよいし、例えば実行開始前等に付与されてもよい。

図３（ｂ）に示すように、リソース３は、Ｒ０〜Ｒ３，Ｒ４−０，Ｒ４−１，Ｒ５−０，Ｒ５−１，Ｒ６（以下、Ｒ０〜Ｒ６と記載する）及びハードウェアアクセラレータＨＡ０〜ＨＡ２からなる。ここで、リソースＲ４−０，Ｒ４−１及びリソースＲ５−０，Ｒ５−１は、それぞれ２つのデバイスによる共有が可能な共有リソースＲ４，Ｒ５を表している。このように、リソース３が共有リソースの場合、共有可能数分のリソースレジスタ１０を用意するとともに、共有可能数分の異なる識別子（本実施形態ではｒｉｄ＝“４”，“５”および“６”，“７”の各２つの識別子）を用意し、別々のリソース（Ｒ４−０，Ｒ４−１およびＲ５−０，Ｒ５−１）として扱うものとする。なお、本実施形態では２つのデバイスによる共有が可能な共有リソースＲ４，Ｒ５の例を示しているが、例えば共有リソースＲ４が３つのデバイスによる共有が可能な場合には、リソースＲ４−０，Ｒ４−１，Ｒ４−２の３つのリソースとして扱う。リソースＲ０〜Ｒ３，Ｒ６は共有リソース３ではない。また、図３では示されていないが、ハードウェアアクセラレータＨＡ０はリソースＲ０、ハードウェアアクセラレータＨＡ１はリソースＲ１、及びハードウェアアクセラレータＨＡ２はリソースＲ２をそれぞれの処理に用いるものとする。

図３（ｂ）の右側の４列は各リソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２と関連付けされたリソースグループｒｇ０〜ｒｇ３の一例を示している。本実施形態において、特定リソースビット（ｒｇ０〜ｒｇ３）は図３（ｂ）のようにあらかじめ設定されているものとする。なお、特定リソースビット（ｒｇ０〜ｒｇ３）の設定はこれに限定されず、例えば実行開始前等にプロセッサＰＥ０〜ＰＥ３が設定又は変更できるようにしてもかまわない。

図３（ｂ）において、各リソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２には、リクエストレジスタ１１におけるリクエスト対象ビット（ｒｉｄ）に設定するための識別子ｒｉｄが付与されている。例えば、リソースＲ０には識別子ｒｉｄとして“０”が付与されており、デバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２からリソースＲ０をリクエストする際には、リクエスト対象ビット（ｒｉｄ）に“０”が設定される。同様に、他のリソースＲ１〜Ｒ６，ＨＡ０〜ＨＡ２にもそれぞれ“１”〜“１１”の識別子ｒｉｄが付与されている。また、リクエストするリソースが“未設定”であることを示す識別子ｒｉｄとして“３１”が付与されている。なお、識別子ｒｉｄはあらかじめ付与されていてもよいし、例えば実行開始前等に付与されてもよい。

特定リソースビット（ｒｇ０）は、共有リソースＲ４を示しており、リソースＲ４−０，Ｒ４−１に“１”が設定され、それ以外のリソースＲ０〜Ｒ３，Ｒ５−０，Ｒ５−１，Ｒ６，ＨＡ０〜ＨＡ２には“０”が設定されている。また、特定リソースビット（ｒｇ０）に係る共有ビット（ｒｇ＿ｔｙｐｅ、図２のグローバルレジスタ１２におけるｒｇ０＿ｔｙｐｅ）は“０”が設定されており、共有リソースＲ４はグループを越えた共有が不許可であることを示している。

同様に、特定リソースビット（ｒｇ１）は、共有リソースＲ５を示しており、リソースＲ５−０，Ｒ５−１に“１”が設定され、それ以外のリソースＲ０〜Ｒ３，Ｒ４−０，Ｒ４−１，Ｒ６，ＨＡ０〜ＨＡ２には“０”が設定されている。また、特定リソースビット（ｒｇ１）に係るグループ共有ビット（ｒｇ＿ｔｙｐｅ、図２のグローバルレジスタ１２におけるｒｇ１＿ｔｙｐｅ）は“１”が設定されており、共有リソースＲ５はグループを越えた共有が許可されることを示している。

特定リソースビット（ｒｇ２）は、映像処理に係る機能の実行に必要なリソースからなるリソースグループｒｇ２を示しており、リソースＲ１，Ｒ４−０，Ｒ４−１，Ｒ５−０，ＨＡ１に“１”が設定されている。また、特定リソースビット（ｒｇ２）に係る共有ビット（ｒｇ＿ｔｙｐｅ、図２のグローバルレジスタ１２におけるｒｇ２＿ｔｙｐｅ）には“０”が設定されている。

特定リソースビット（ｒｇ３）は、グラフィック処理に係る機能の実行に必要なリソースからなるリソースグループｒｇ３を示しており、リソースＲ１，Ｒ６，ＨＡ１に“１”が設定されている。また、特定リソースビット（ｒｇ３）に係る共有ビット（ｒｇ＿ｔｙｐｅ、図２のグローバルレジスタ１２におけるｒｇ３＿ｔｙｐｅ）には“０”が設定されている。

具体的には、リソースＲ４−０，Ｒ４−１は、特定リソースビット（ｒｇ０）及び共有ビット（ｒｇ＿ｔｙｐｅ）の値からグループを越えた共有を許可されていない共有リソースＲ４であり、両方が特定リソースビット（ｒｇ２）に係る映像処理用のリソース３として設定されているため、この映像処理が行われているときには、リソースＲ４−０，Ｒ４−１は映像処理用として原則使用される。これに対して、リソースＲ５−０，Ｒ５−１は特定リソースビット（ｒｇ１）及び共有ビット（ｒｇ＿ｔｙｐｅ）の値からグループを越えた共有を許可された共有リソースＲ５であるため、例えばリソースＲ５−０が特定リソースビット（ｒｇ２）の映像処理に使用されていたとしても、リソースＲ５−１は他のグループによる使用が可能である。

なお、リクエスト対象ビット（ｒｉｄ）には、図４（ｂ）に示す識別子ｒｉｄに加えて、特定リソースビット（ｒｇ０〜ｒｇ３）によって示されたリソースグループｒｇ０〜ｒｇ３を示す識別子（図示せず）を設定することも可能である。例えば、図４（ｂ）で使用していない識別子“１２”〜“３０”を使用してもよい。

図４は本実施形態に係る調停システムによるリソース割り付け状況を示す図である。

図４は各ケース０〜３において、リソースグループビット（ｇｉｄ＿ｒｓ）及びリクエストグループビット（ｇｉｄ＿ｒｑ）に設定される識別子ｇｉｄ、並びに識別子ｇｉｄが設定された第０〜第４グループＧ０〜Ｇ４のリソース割り付け状況を示している。例えば、第０グループＧ０には、識別子ｇｉｄとして“０”が付与されている。同様に、第１〜第４グループＧ１〜Ｇ４にはそれぞれ識別子ｇｉｄとして“１”〜“４”が付与されている。このように、１つの機能を実行するために割り付けられたデバイス及びリソースの集まりを、グループとして管理する。また、識別子ｇｉｄとして“１５”が付与された未使用のグループを空きグループＧ１５として使用する。そして、デバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２に確保されていないリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２は空きグループＧ１５に割り付けるものとする。

＜Ａ．ケース０からケース１への移行に係る動作＞
図４において、ケース０はいずれの処理にもリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２が確保されていない状況を示しており、リソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２は空きグループＧ１５に割り付けされている。図５は、ケース０における各リソースのリソースレジスタ１０の各ビットの値を示している。識別子ｒｉｄとして“０”が付与されているリソースＲ０には、リソースグループビット（ｇｉｄ＿ｒｓ）として空きグループを示す“１５”が設定されており、リクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）として未設定であることを示す“１５”が設定されている。リソースＲ０はいずれのデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２からも所有（確保）されておらず、エラーは発生していないため、所有ビット（ｏｗｎｅｒ）及びエラービット（ｅｒｒｏｒ）には、それぞれ“０”が設定されている。特定リソースビット（ｒｇ０〜ｒｇ４）は図３と同じ値となっている。リソースＲ１〜Ｒ６，ＨＡ〜ＨＡ２のリソースレジスタ１０にも同様に値が設定されている。

図４に示すように、ケース１では第０〜第２グループＧ０〜Ｇ２において、それぞれ映像処理、音声処理及びシステム処理が実施される。これに伴い、第０グループＧ０では、映像処理用として、プロセッサＰＥ０はリソースＲ４−０，Ｒ４−１，Ｒ５−０を確保する。同様に、プロセッサＰＥ１はハードウェアアクセラレータＨＡ１を確保し、ハードウェアアクセラレータＨＡ１はリソースＲ１を確保する。第１グループＧ１では、音声処理用として、プロセッサＰＥ２はハードウェアアクセラレータＨＡ２とリソースＲ５−１を確保し、ハードウェアアクセラレータＨＡ２はリソースＲ２を確保する。第２グループＧ２では、システム処理用として、プロセッサＰＥ３はリソースＲ３を確保し、ハードウェアアクセラレータＨＡ０はリソースＲ０を確保する。なお、第２グループＧ２におけるシステム処理では、プロセッサＰＥ３とハードウェアアクセラレータＨＡ０とは独立して処理を実施するものとし、プロセッサＰＥ３によってハードウェアアクセラレータＨＡ０は確保されないものとする。

ここで、選択ユニット４による調停は、所定期間内に発生したリクエストに対してまとめて行われるものとする。本実施形態では、所定の期間として、例えばケース０の開始からケース０からケース１への移行までの期間のように各ケース間の開始からそのケースから次のケースへの移行までの期間とする。なお、所定の期間は上記の期間に限定されず、変更されてもかまわない。

以下に、各デバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２がリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２を確保する状況について説明する。

（Ａ−１．プロセッサＰＥ１によるハードウェアアクセラレータＨＡ１の確保）
ケース０において、ハードウェアアクセラレータＨＡ１のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝未設定、ｒｑｉｄ＿ｒｓ＝未設定、ｏｗｎｅｒ＝０
が設定されている。ここで、リソースグループビット（ｇｉｄ＿ｒｓ）は識別子ｇｉｄとして“１５”が設定されている。以下において説明の便宜上、リソースグループビット（ｇｉｄ＿ｒｓ）に“１５”が設定される場合は、“未設定”と記述する。同様にリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）は識別子ｒｑｉｄとして空きグループＧ１５を示す“１５”が設定されているが、説明の便宜上“未設定”と記述する。また、リソースレジスタ１０のうち、エラービット（ｅｒｒｏｒ）について記述がされていない（記述を省略している）場合は、識別子として“０”が設定されているものとする。また、特定リソースビット（ｒｇ０〜ｒｇ４）について記述がされていない（記述を省略している）場合は、図３と同じ値になっているものとする。

プロセッサＰＥ１は、ハードウェアアクセラレータＨＡ１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＰＥ１、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝ＨＡ１
を設定する。ここで、ビット（ｒｑｉｄ＿ｒｑ）には、プロセッサＰＥ１を示す識別子ｒｑｉｄとして“１”が設定されるが、説明の便宜上“ＰＥ１”と記載する。同様に、リクエスト対象ビット（ｒｉｄ）には、ハードウェアアクセラレータＨＡ１を示す識別子ｒｉｄとして“１０”が設定されるが、説明の便宜上“ＨＡ１”と記載する。プロセッサＰＥ１は、上記のようにリクエストグループビット（ｇｉｄ＿ｒｑ）を“０”に設定して、リソースを割り付けるグループＧ０を示すことにより、ハードウェアアクセラレータＨＡ１を第０グループＧ０の映像処理で使用することを示している。

なお、以下においてリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）、リソースグループビット（ｇｉｄ＿ｒｓ）、ビット（ｒｑｉｄ＿ｒｑ）及びリクエスト対象ビット（ｒｉｄ）の設定は、設定値（数字）ではなく、デバイス名ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２及びリソース名Ｒ０〜Ｒ６，ＨＡ０〜ＨＡ２を用いて記載する。

ケース０において、ハードウェアアクセラレータＨＡ１はデバイスＰＥ０〜ＰＥ３のいずれにも所有されていないため、リクエストにおいてリソースの割り付け先となるデバイス（リクエスト主体となるデバイス）ＰＥ１が属するグループＧ０に関係なく所定期間内に発生したリクエストに対して調停が行われる。

ケース０からケース１にかけて、ハードウェアアクセラレータＨＡ１に対するリクエストはプロセッサＰＥ１からのみであるため、競合は発生しない。したがって、選択ユニット４は、調停の結果としてハードウェアアクセラレータＨＡ１の所有者をプロセッサＰＥ１に決定し、ハードウェアアクセラレータＨＡ１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝０（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ１（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はプロセッサＰＥ１にハードウェアアクセラレータＨＡ１が確保されたことを通知する。このようにして、プロセッサＰＥ１によってハードウェアアクセラレータＨＡ１は確保される。

ここで、選択ユニット４は、プロセッサＰＥ１からのハードウェアアクセラレータＨＡ１のリクエストに係るリクエストレジスタ１１をリセットする。具体的には、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝未設定（←“０”）、ｒｑｉｄ＿ｒｑ＝未設定（←“ＰＥ１”）、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝未設定（←“ＨＡ１”）
を設定する。

上記と同様のフローによりプロセッサＰＥ２，ＰＥ３はそれぞれハードウェアアクセラレータＨＡ２，ＨＡ０を確保する。このとき、選択ユニット４はハードウェアアクセラレータＨＡ２のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝１（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ２（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。また、選択ユニット４はハードウェアアクセラレータＨＡ０のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝２（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。

同様に、ハードウェアアクセラレータＨＡ０〜ＨＡ２はそれぞれリソースＲ０〜Ｒ２を確保する。このとき、選択ユニット４はリソースＲ０〜Ｒ２のリソースレジスタ１０の設定をそれぞれ、リソースＲ０は、
ｇｉｄ＿ｒｓ＝２（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＨＡ０（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
リソースＲ１は、
ｇｉｄ＿ｒｓ＝０（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＨＡ１（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
リソースＲ２は、
ｇｉｄ＿ｒｓ＝１（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＨＡ２（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。

同様にプロセッサＰＥ０はリソースＲ５−０を確保する。このとき、選択ユニット４はリソースＲ５−０のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝０（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ０（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。

（Ａ−２．プロセッサＰＥ０によるリソースＲ４−０，Ｒ４−１の確保）
ケース０において、リソースＲ４−０，Ｒ４−１のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝未設定、ｒｑｉｄ＿ｒｓ＝未設定、ｏｗｎｅｒ＝０
が設定されている。

プロセッサＰＥ０は、リソースＲ４−０，Ｒ４−１に対するリクエストとしてリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＰＥ０、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝ｒｇ０
を設定する。このとき、リクエスト対象ビット（ｒｉｄ）には共有リソースＲ４を示すリソースグループｒｇ０を指す識別子ｒｇ０が設定されている。このように、リソースグループｒｇ０〜ｒｇ３をリクエストの対象とするときは、そのリソースグループを示す識別子ｒｇ０〜ｒｇ３をリクエスト対象ビット（ｒｉｄ）に設定する。

ケース０において、リソースＲ４−０，Ｒ４−１はともにデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２いずれにも所有されていないため、リクエスト主体となるデバイスＰＥ０が属するグループＧ０に関係なく所定期間内に発生したリクエストに対して調停される。

ここで、ケース０からケース１にかけてのリソースＲ４−０，Ｒ４−１に対するリクエストはプロセッサＰＥ０からのみであるため、競合は発生しない。また、リソースＲ４−０，Ｒ４−１の共有ビット（ｒｇ＿ｔｙｐｅ）は“０”であるが、両方のリソースＲ４−０，Ｒ４−１ともに第０グループＧ０を示すリクエストを受けているので割り付けが可能である。したがって、選択ユニット４は調停の結果として、リソースＲ４−０，Ｒ４−１の所有者をプロセッサＰＥ０に決定し、リソースＲ４−０，Ｒ４−１のそれぞれのリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝０（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ０（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４は、プロセッサＰＥ０にリソースＲ４−０，Ｒ４−１が確保されたことを通知する。このようにして、プロセッサＰＥ０によってリソースＲ４−０，Ｒ４−１は確保される。

（Ａ−３−１．プロセッサＰＥ２によるリソースＲ５−１の確保）
ここでは、リソースＲ５−０はプロセッサＰＥ０によって既に確保されているものとして説明する。

ケース０において、リソースＲ５−１のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝未設定、ｒｑｉｄ＿ｒｓ＝未設定、ｏｗｎｅｒ＝０
が設定されている。

プロセッサＰＥ２は、リソースＲ５−１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝１、ｒｑｉｄ＿ｒｑ＝ＰＥ２、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ５−１
を設定する。リソースＲ５−０，Ｒ５−１の共有ビット（ｒｇ＿ｔｙｐｅ）は“１”であり、各グループを越えた共有が許可される。すなわち、リソースＲ５−０，Ｒ５−１は、それぞれのリソースグループビット（ｇｉｄ＿ｒｓ）が異なってもよい。したがって、リクエスト者ＰＥ２が設定するリクエストグループビット（ｇｉｄ＿ｒｑ）が示すグループＧ１に関わらず、リソースＲ５−０，Ｒ５−１の各リソースレジスタ１０のうちいずれかの一方が解放を示していれば、それぞれ（Ｒ５−０，Ｒ５−１）をリクエスト対象としたリクエストに対して、それぞれに調停される。

ここで、ケース０からケース１にかけてのリソースＲ５−１に対するリクエストはプロセッサＰＥ２からのみであるため、競合は発生しない。したがって、選択ユニット４は、調停の結果としてリソースＲ５−１の所有者をプロセッサＰＥ２に決定し、リソースＲ５−１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝１（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ２（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４は、プロセッサＰＥ２にリソースＲ５−１が確保されたことを通知する。このようにして、プロセッサＰＥ２によってリソースＲ５−１は確保される。

（Ａ−３−２．プロセッサＰＥ２によるリソースＲ５−１の確保の他の例）
ここで、上記のＡ−３−１の他の例として、共有リソースＲ５の共有ビット（ｒｇ＿ｔｙｐｅ）が“０”のときのプロセッサＰＥ２によるリソースＲ５−１のリクエストの例について説明する。本説明は、上記のＡ−３−１と対比させるためのものであり、図３（ｂ）に示した共有ビット（ｒｇ＿ｔｙｐｅ）とは異なる設定の例である。なお、ここでもリソースＲ５−０はプロセッサＰＥ０によって既に確保されているものとして説明する。

上記のＡ−３−１と同様に、ケース０において、リソースＲ５−１のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝未設定、ｒｑｉｄ＿ｒｓ＝未設定、ｏｗｎｅｒ＝０
が設定されている。また、プロセッサＰＥ２は、リソースＲ５−１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝１、ｒｑｉｄ＿ｒｑ＝ＰＥ２、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ５−１
を設定する。先ほどの仮定により、リソースＲ５−０，Ｒ５−１の共有ビット（ｒｇ＿ｔｙｐｅ）は“０”であり、各グループを越えた共有が許可されない。リクエスト者（リクエスト主体となるデバイス）ＰＥ２が第１グループＧ１の音声処理においてリソースＲ５−１を確保するためには、第０グループＧ０の映像処理においてリソースＲ５−０を使用するプロセッサＰＥ０からリソースＲ５−０が解放される必要があり、選択ユニット４はプロセッサＰＥ０からリソースＲ５−０が解放されてから、すなわちリソースＲ５−０のリソースグループビット（ｇｉｄ＿ｒｓ）が“未設定”となってから調停を行う。このように、グループＧ０〜Ｇ３を越えた共有を許可されないリソースＲ５−０，Ｒ５−１に関して、共有リソースＲ５−０のリソースグループビット（ｇｉｄ＿ｒｓ）の示すグループＧ０と共有リソースＲ５−１のリクエスト主体となるデバイスＰＥ２の属するグループＧ１とが異なる場合は、特定リソースビット（ｒｇ１）に示された共有リソースＲ５（Ｒ５−０，Ｒ５−１）がすべて解放されてから調停が行われる。

なお、以降の説明では共有リソースＲ５（Ｒ５−０，Ｒ５−１）の共有ビット（ｒｇ＿ｔｙｐｅ）は“１”として説明を行う。すなわち、リソースＲ５−１はケース０からケース１への移行に伴いプロセッサＰＥ２に確保されており、リソースＲ５−１のリソースレジスタ１０の設定は、ｇｉｄ＿ｒｓ＝１、ｒｑｉｄ＿ｒｓ＝ＰＥ２、ｏｗｎｅｒ＝１、ｒｇ０＝０、ｒｇ１＝１、ｒｇ２＝０、ｒｇ３＝０となっているものとして以降の説明を行う。

（Ａ−４．プロセッサＰＥ３によるリソースＲ３の確保）
ここでは、リソースＲ３はプロセッサＰＥ２からもリクエストされている、すなわち競合が発生しているものとして説明する。

ケース０において、リソースＲ３のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝未設定、ｒｑｉｄ＿ｒｓ＝未設定、ｏｗｎｅｒ＝０
が設定されている。

プロセッサＰＥ２は、リソースＲ３に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝１、ｒｑｉｄ＿ｒｑ＝ＰＥ２、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ３
を設定する。プロセッサＰＥ３は、リソースＲ３に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝２、ｒｑｉｄ＿ｒｑ＝ＰＥ３、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ３
を設定する。ここで、プロセッサＰＥ３は優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”を設定している。

このとき、リクエスト者ＰＥ２，ＰＥ３のリソースＲ３に対するリクエストにおいて、競合が発生している。優先順位ビット（ｐｒｉｏｒｉｔｙ）は調停の優先順位を示すため、リクエスト者ＰＥ３のリクエストが優先される。この結果、選択ユニット４は調停の結果としてリソースＲ３の所有者をプロセッサＰＥ３に決定し、リソースＲ３のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝２（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はプロセッサＰＥ３にリソースＲ３が確保されたことを通知する。一方で、選択ユニット４はプロセッサＰＥ２にリソースＲ３が確保されなかったことは通知しない。

ここで、選択ユニット４は、プロセッサＰＥ３からのリソースＲ３のリクエストに係るリクエストレジスタ１１をリセットする。具体的には、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝未設定、ｒｑｉｄ＿ｒｑ＝未設定、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝未設定
を設定する。なお、プロセッサＰＥ２からのリソースＲ３のリクエストに係るリクエストレジスタ１１はリセットしない。

このように、複数のリクエスト者ＰＥ２，ＰＥ３からのリクエストが発生した場合には、所定の優先順位に従って調停される。ここでは、そのリソースを確保するまで処理を実行できないリクエスト者について、優先順位を高く設定するものとしている。すなわち、デバイスＰＥ３がリソースＲ３を確保するまでシステム処理を実行することができないものとし、デバイスＰＥ３について、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”を設定し、優先順位を高くしている。なお、優先順位の設定はここで示した条件に限られるものではなく、他の条件に基づいて優先順位付けしてもよい。

ここで、選択ユニット４は、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“０”が設定されているプロセッサＰＥ２には調停の結果としてリソース確保がなされなかったことを通知していない。このように、本実施形態では、リソースが確保された場合の通知は、いかなるリクエスト主体にも実施する一方、リソースが確保されなかった場合の通知は、リクエスト主体が属するグループがリソースが属するグループと同じか異なるかによらず、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”のときのみ実施するものとする。

このように、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“０”が設定されているリクエスト主体となるデバイスＰＥ２には、リソースが確保されなかったことを通知しないことにより、リクエスト主体となるデバイスＰＥ２の処理に影響を与えずにすむ。

図６はケース０からケース１への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース０においては、すべてのリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２が空きグループＧ１５に属しており、ケース０からケース１への移行に伴いリソースＲ０〜Ｒ５（Ｒ５−０，Ｒ５−１），ＨＡ０〜ＨＡ２はいずれかのデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２に確保され、リソースＲ６のみがケース１においていずれのデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２にも確保されず、空きグループＧ１５に属している。

＜Ｂ．ケース１からケース２への移行に係る動作＞
次に、図４においてケース１からケース２への移行に係る動作について説明する。図４に示すように、ケース２ではリソースＲ３の所有者がプロセッサＰＥ３からプロセッサＰＥ２に変更されており、リソースＲ４−１の所有者がプロセッサＰＥ０からハードウェアアクセラレータＨＡ１に変更されている。また、後述するグラフィック処理（機能処理）に使用するリソースＲ１，Ｒ６，ＨＡ１を割り付ける予約用グループが第３グループＧ３に作成されている。

（Ｂ−１．リソースＲ３の所有者の変更）
図６に示すように、ケース１において、リソースＲ３のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝２、ｒｑｉｄ＿ｒｓ＝ＰＥ３、ｏｗｎｅｒ＝１
が設定されている。

プロセッサＰＥ２はリソースＲ３に対するリクエストとしてリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝１、ｒｑｉｄ＿ｒｑ＝ＰＥ２、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ３
を設定する。ここで、優先順位ビット（ｐｒｉｏｒｉｔｙ）は先ほどの“０”から“１”に変更され、優先順位が高くなったものとする。

選択ユニット４はリクエスト主体となるデバイスＰＥ２にリソースＲ３に係る調停結果として、競合が発生していることを通知する。本実施形態では、リクエスト主体が属するグループが、リソースが属するグループと同じか異なるかによらず、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”のときのみリクエスト主体に競合発生を通知するものとする。

なお、競合発生の通知はこれに限定されない。例えば、リクエスト主体が属するグループが、リソースが属するグループと異なる場合に、競合発生を通知するものとしてもよい。

一方で、選択ユニット４はプロセッサＰＥ３に、所有するリソースＲ３の解放要求を示す情報を通知する。本実施形態では、リクエストの割り付け先となるデバイスが属するグループＧ１が、リソースが属するグループと異なっており、かつ、リクエストレジスタ１１の優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”のときのみ、所有者に解放要求を通知するものとする。

なお、解放要求の通知はこの条件に限定されない。例えば、リソースのリソースグループビット（ｇｉｄ＿ｒｓ）と、リクエスト者が設定したリクエストグループビット（ｇｉｄ＿ｒｑ）とが示す識別子ｇｉｄが異なる場合、優先順位ビット（ｐｒｉｏｒｉｔｙ）の値に関わらず所有者に解放要求を通知するものとしてもよい。

プロセッサＰＥ３は選択ユニット４からの解放要求の通知をリソースＲ３の解放の判断材料とし、リソースＲ３を解放が可能となった時点で解放する。この解放のとき、プロセッサＰＥ３はリソースＲ３のリソースレジスタ１０の各ビットを、
ｇｉｄ＿ｒｓ＝未設定（←“２”）、ｒｑｉｄ＿ｒｓ＝未設定（←“ＰＥ３”）、ｏｗｎｅｒ＝０（←“１”）
と更新する。

これにより、解放されたリソースＲ３は空きグループＧ１５に属し、リクエスト主体となるデバイスＰＥ２が属するグループＧ１（リクエスト先のグループＧ１）に関係なく、所定期間内に受けたリクエスト者ＰＥ２からのリクエストに対して調停されることとなる。

選択ユニット４は、調停の結果としてリソースＲ３の所有者をプロセッサＰＥ２に決定し、リソースＲ３のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝１（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ２（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はプロセッサＰＥ２にリソースＲ３が確保されたことを通知する。このようにして、プロセッサＰＥ２によってリソースＲ３は確保される。

このように、グループＧ０〜Ｇ４の移動を伴う所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２の変更が発生する場合、リソースは空きグループＧ１５を介して調停される。

（Ｂ−２−１．リソースＲ４−１の所有者の変更）
ここでは、ハードウェアアクセラレータＨＡ１はリソースＲ４−１が確保されなければ処理が継続できなくなるものとする。このような状況は、例えばリソースＲ４−１にプロセッサＰＥ０の処理結果が格納されており、ハードウェアアクセラレータＨＡ１がそれを利用して処理する場合などに発生する。また、リソースＲ４−１はプロセッサＰＥ１からもリクエストされているものとする。

図６に示すように、ケース１において、リソースＲ４−１，Ｒ４−０のリソースレジスタ１０の各ビットには、
ｇｉｄ＿ｒｓ＝０、ｒｑｉｄ＿ｒｓ＝ＰＥ０、ｏｗｎｅｒ＝１
が設定されている。

プロセッサＰＥ１は、リソースＲ４−１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＰＥ１、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ４−１
を設定する。プロセッサＰＥ０は、リソースＲ４−１のリクエストに係るリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＨＡ１、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ４−１
を設定する。ここで、プロセッサＰＥ０は、ハードウェアアクセラレータＨＡ１がリソースＲ４−１を確保しなければ処理が継続できないため、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”を設定する。なお、上記のように、リクエスト者ＰＥ０とリクエスト主体となるデバイスＨＡ１とが異なってもよい。

選択ユニット４は、リソースＲ４−１に係るリソースレジスタ１０のリソースグループビット（ｇｉｄ＿ｒｓ）及びリクエスト者ＰＥ１，ＰＥ０からのリクエストに係るリクエストレジスタ１１のリクエストグループビット（ｇｉｄ＿ｒｑ）から、リクエスト主体となるデバイスＰＥ１，ＨＡ０の属するグループＧ０と、リソースＲ４−１の属するグループＧ０とが同じであることを確認する。一方で、選択ユニット４はリクエスト主体となるデバイスＨＡ０にリソースＲ４−１に係る調停結果として、競合が発生していることを通知する。ここで、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“０”を設定しているプロセッサＰＥ１には競合が発生していることを通知しない。このように、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“０”を設定しているデバイスＰＥ１に競合の発生を通知しないことにより、デバイスＰＥ１の処理に影響を与えずにすむ。

そして、ハードウェアアクセラレータＨＡ１はこの調停結果の情報を、例えば競合が解決されるまで実行可能な処理を実施したり、電力をセーブしたりする判断材料とする。ここで、選択ユニット４は、リソースＲ４−１の属するグループＧ０と同じグループＧ０のリクエスト主体となるデバイスＰＥ１，ＨＡ０に係るリクエストであるため、所有者ＰＥ０への解放要求を通知しない。なお、解放要求の通知はこの条件に限定されない。例えば、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”のときに、グループが同じであるか否かに関わらず所有者に解放要求を通知してもよい。

なお、解放要求が通知されない場合、そのリソースの所有者がそのリソースを不要となり解放するまで待つこととなる。つまり該当の処理が終わるまで（例えば、ケースが切り替わるまで）解放しないことが明らかである場合には、解放要求の通知をしないこととしてもよい。

プロセッサＰＥ０は処理結果をリソースＲ４−１に格納した後、リソースＲ４−１を解放する。このとき、プロセッサＰＥ０は同一グループＧ０内のリクエスト主体となるデバイスＰＥ１，ＨＡ１への解放とするために、リソースＲ４−１のリソースレジスタ１０の各ビットを、
ｇｉｄ＿ｒｓ＝０、ｒｑｉｄ＿ｒｓ＝ＰＥ０、ｏｗｎｅｒ＝０（←“１”）
と更新して、解放する。このように、同じグループＧ０内のリクエスト主体となるデバイスＰＥ１，ＨＡ１への解放の場合、リソースグループビット（ｇｉｄ＿ｒｓ）は“未設定”に更新しない。すなわち、このときのリソースＲ４−１は空きグループＧ１５には属しない。なお、このようにリソースグループビット（ｇｉｄ＿ｒｓ）が空きグループＧ１５を介さずにリソースＲ４−１が解放されたときに、調停システム４は、例えばビット（ｏｗｎｅｒ）が“０”になっていることからリソースＲ４−１が解放されたことを確認することができる。

解放されたリソースＲ４−１は、第０グループＧ０を示す識別子（ｇｉｄ＝０）がリソースグループビット（ｇｉｄ＿ｒｓ）に設定されており、リクエストグループビット（ｇｉｄ＿ｒｑ）が示す第０グループＧ０に属する各リクエスト者ＰＥ１，ＨＡ１から所定期間内に受けたリクエストに対して調停されることとなる。

選択ユニット４は調停の結果として、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”であるハードウェアアクセラレータＨＡ１をリソースＲ４−１の所有者に決定し、リソースＲ４−１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝０、ｒｑｉｄ＿ｒｓ＝ＨＡ１（←“ＰＥ０”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はハードウェアアクセラレータＨＡ１にリソースＲ４−１が確保されたことを通知する。このようにして、ハードウェアアクセラレータＨＡ１によってリソースＲ４−１は確保される。

以上のように、同じグループＧ０内のリクエスト主体となるデバイスＰＥ１，ＨＡ１への解放の場合、リソースグループビット（ｇｉｄ＿ｒｓ）を空きグループＧ１５を示す値に更新しないことにより、リソースＲ４−１を同じグループＧ０内で割り付けし、交換することができる。これにより、リソースＲ４−１を他のグループＧ１〜Ｇ４のリクエスト主体となるデバイス（リクエスト者）ＰＥ２，ＰＥ３，ＨＡ０，ＨＡ２から保護することができる。

（Ｂ−２−２．リソースＲ４−１の所有者の変更の他の例）
リソースＲ４−１の所有者がプロセッサＰＥ０からハードウェアアクセラレータＨＡ１に変更される状況の他の例を以下に説明する。なお、上記の“Ｂ−２−１”と同一事項に関しては説明を省略する。

プロセッサＰＥ１は、リソースＲ４−１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＰＥ１、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ４−１
を設定する。プロセッサＰＥ０は、リソースＲ４−１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝０、ｒｑｉｄ＿ｒｑ＝ＨＡ１、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ４−１
を設定する。すなわち、この例では、プロセッサＰＥ１も優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”を設定しているものとする。

選択ユニット４は、リクエスト主体となるデバイスＨＡ１，ＰＥ１にリソースＲ４−１に係る調停結果として、競合が発生していることを通知する。

プロセッサＰＥ０は処理結果をリソースＲ４−１に格納した後、リソースＲ４−１を解放する。このとき、プロセッサＰＥ０はハードウェアアクセラレータＨＡ１への解放とするために、リソースＲ４−１のリソースレジスタ１０の各ビットを、
ｇｉｄ＿ｒｓ＝０、ｒｑｉｄ＿ｒｓ＝ＨＡ１（←“ＰＥ０”）、ｏｗｎｅｒ＝０（←“１”）
と更新して、解放する。このように、リソースＲ４−１の解放先を指定したい場合、デバイスＰＥ０は解放先として指定するデバイスＨＡ１をリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）に設定する。

ここでは、所定の優先順位として、リクエスト主体となるデバイスＨＡ１，ＰＥ１に係るリクエストレジスタの優先順位ビット（ｐｒｉｏｒｉｔｙ）は両方ともに“１”であるが、リクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）に設定されたリクエスト主体となるデバイスＨＡ１が優先される。したがって、選択ユニット４は調停の結果として、リソースＲ４−１の所有者をハードウェアアクセラレータＨＡ１に決定し、リソースＲ４−１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝０、ｒｑｉｄ＿ｒｓ＝ＨＡ１、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はハードウェアアクセラレータＨＡ１にリソースＲ４−１が確保されたことを通知する。一方で、プロセッサＰＥ１にリソースＲ４−１が確保されなかったことを通知する。このようにして、ハードウェアアクセラレータＨＡ１によってリソースＲ４−１は確保される。そして、プロセッサＰＥ１はこのリソースＲ４−１が確保されなかった情報を、例えば競合が解決されるまで実行可能な処理を実施したり、電力をセーブしたりする判断材料とする。

なお、この例のように、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”が設定されたリクエストが重複した場合、競合発生の通知を受けたリクエスト主体同士で割り付け先にするデバイスである候補デバイスを決定し、これらのリクエスト主体のうちのいずれか１つがリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）に、決定した候補デバイスを示す識別子を設定してもよい。

また、例えば、選択ユニット４の動作をモニタリングするプロセッサＰＥ０〜ＰＥ３を用意し、優先順位が同じである等の理由により、選択ユニット４がリソースの割り付けをしない期間が一定以上経過したとき、このモニタリングするプロセッサＰＥ０〜ＰＥ３が、優先するデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２を決定し、リクエストされているリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２のリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）にその決定したデバイスＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２を示す識別子を設定してもよい。

また、プロセッサＰＥ０は、処理結果をリソースＲ４−１に格納する前に、リソースＲ４−１のリクエストを行っているが、処理結果を格納した後に、リクエストを行ってもよい。その場合、リクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）を設定するプロセッサＰＥ０のリクエストが優先されるため、リクエスト主体となるデバイスＨＡ１，ＰＥ１へのリソースＲ４−１に係る競合の発生の通知はなくてもよい。

＜Ｂ−３．予約用グループＧ３へのリソースＲ６の確保＞
ここで、プロセッサＰＥ３は、未使用のグループであるＧ３を予約グループとして使用するものとする。

プロセッサＰＥ３は、リソースＨＡ１に対するリクエストとして、リクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝３、ｒｑｉｄ＿ｒｑ＝ＰＥ３、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝ＨＡ１
を設定する。同様に、リソースＲ１，Ｒ６に対するリクエストとして、それぞれリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝３、ｒｑｉｄ＿ｒｑ＝ＰＥ３、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ１
及び、
ｇｉｄ＿ｒｑ＝３、ｒｑｉｄ＿ｒｑ＝ＰＥ３、ｐｒｉｏｒｉｔｙ＝０、ｒｉｄ＝Ｒ６
を設定する。

ケース１において、リソースＲ６は空きグループＧ１５に属するため、リクエスト者（リクエスト主体となるデバイス）ＰＥ３がリクエストするグループＧ３に関係なく所定期間内に発生したリクエストに対して調停が行われる。

ここで、ケース１からケース２にかけてリソースＲ６に対するリクエストはプロセッサＰＥ３からのみであるため、競合は発生しない。したがって、選択ユニット４は、調停の結果としてリソースＲ６の所有者をプロセッサＰＥ３に決定し、リソースＲ６のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝３（←“未設定”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３（←“未設定”）、ｏｗｎｅｒ＝１（←“０”）
と更新する。その後、選択ユニット４はプロセッサＰＥ３にリソースＲ６が確保されたことを通知する。このようにして、プロセッサＰＥ３によってリソースＲ６は予約グループＧ３に確保される。

一方で、ケース１において、リソースＨＡ１はプロセッサＰＥ１に確保され、リソースＲ１はハードウェアアクセラレータＨＡ１に確保されている。すなわち、競合が発生している。

選択ユニット４は、リクエストレジスタ１１の優先順位ビット（ｐｒｉｏｒｉｔｙ）が“０”であるため、リクエスト主体となるデバイスＰＥ３にリソースＨＡ１，Ｒ１に競合が発生していることを通知しない。

また、リクエスト主体となるデバイスＰＥ３が属するグループＧ３が、リソースＨＡ１，Ｒ１が属するグループＧ０と異なっているものの、リクエストレジスタ１１の優先順位ビット（ｐｒｉｏｒｉｔｙ）が“０”であるため、所有者ＰＥ１、ＨＡ１に解放要求を通知しない。これにより、所有者ＰＥ１，ＨＡ１の処理に影響を与えずにすむ。

したがって、ケース１からケース２にかけては、予約グループＧ３へのリクエストに対して、リソースＲ６のみがプロセッサＰＥ３により予約グループＧ３に確保される。

図７はケース１からケース２への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース１においては、リソースＲ６が空きグループＧ１５に属しており、ケース１からケース２への移行に伴い空きグループＧ１５に属するリソースはなくなっている。

＜Ｃ．ケース２からケース２’への移行に係る動作＞
ケース２’とは、ケース２からケース３への移行に係る途中の状態を示しているものとする。

図４に示すように、ケース２’では、リソースＨＡ１，Ｒ１のそれぞれの所有者がデバイスＰＥ３，ＨＡ１からプロセッサＰＥ３に変更されている。また、リソースＲ４−１がハードウェアアクセラレータＨＡ１から解放され、空きグループＧ１５に属するリソースとなっている。また、プロセッサＰＥ３のシステム処理が終了し、リソースＨＡ０，Ｒ０が解放され、ともに空きグループＧ１５に属している。

＜Ｃ−１．予約用グループＧ３へのリソースＲ１，ＨＡ１の確保＞
グラフィック処理に係るリソースグループｒｇ３は特定リソースビット（ｒｇ３）にあらかじめ設定されており、リソースＲ１，Ｒ６，ＨＡ１からなる。

プロセッサＰＥ３は、リソースグループｒｇ３に対するリクエストとしてリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝３、ｒｑｉｄ＿ｒｑ＝ＰＥ３、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝ｒｇ３
を設定する。このように、リソースグループｒｇ３単位でリクエストする場合には、リクエスト者ＰＥ３はリクエスト対象ビット（ｒｉｄ）にリソースグループｒｇ３を示す識別子ｒｇ３を設定する。すると、リソースグループｒｇ３に係るリソースＲ１，Ｒ６，ＨＡ１への一括のリクエストが行われる。また、優先順位ビット（ｐｒｉｏｒｉｔｙ）は先ほどの“０”から“１”に変更され、優先順位が高くなったものとする。ここで、リソースＲ６は、予約グループＧ３に既に確保されているため、実際には、リソースＲ１，ＨＡ１へのリクエストが行われる。

ケース２において、ハードウェアアクセラレータＨＡ１はプロセッサＰＥ１に所有されており、リソースＲ１はハードウェアアクセラレータＨＡ１に所有されている。

選択ユニット４は、リクエスト主体となるデバイスＰＥ３に調停結果を示す情報として、リソースＲ１，ＨＡ１の競合が発生したことを通知する。一方で、選択ユニット４は、リソースＨＡ１，Ｒ１の解放要求を示す情報をそれぞれの所有者ＰＥ１，ＨＡ１に通知する。このとき、リクエストグループビット（ｇｉｄ＿ｒｑ）が予約用グループＧ３を示すリクエストであり、かつ、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”に設定されているため、選択ユニット４はリソースＨＡ１，Ｒ１の所有者ＰＥ１，ＨＡ１に予約用グループＧ３を要求先としたリクエストであることを併せて通知する。本実施形態では、上記のように、予約用グループＧ３を要求先としたリクエストであることをリクエストグループビット（ｇｉｄ＿ｒｑ）が予約用グループＧ３を示しており、かつ、優先順位ビット（ｐｒｉｏｒｉｔｙ）が“１”に設定されている（所定の優先順位以上）ときに行うものとする。なお、所定の優先順位以上とは、これに限定されず、例えば、リソースグループｒｇ３がリクエスト対象ビット（ｒｉｄ）に設定されているときとしてもよい。

プロセッサＰＥ１及びハードウェアアクセラレータＨＡ１は、予約用グループＧ３を要求先とするリクエストであることを認識し、この情報を解放の判断基準とする。その後、プロセッサＰＥ１及びハードウェアアクセラレータＨＡ１は、それぞれハードウェアアクセラレータＨＡ１及びリソースＲ１を解放する。これにより、リソースＨＡ１，Ｒ１及びハードウェアアクセラレータＨＡ１に確保されていたリソースＲ４−１は空きグループＧ１５に属するリソースとなる。

選択ユニット４は、リソースＨＡ１，Ｒ１が空きグループＧ１５に属するリソースとなったことを検出し、これらのリソースＨＡ１，Ｒ１を優先して調停する。本実施形態では、リクエストレジスタ１１のリクエスト対象ビット（ｒｉｄ）にリソースグループｒｇ０〜ｒｇ３が設定された場合、調停のときの優先順位が高くなるものとする。

選択ユニット４は、調停の結果としてリソースＨＡ１，Ｒ１の所有者をプロセッサＰＥ３に決定し、リソースＲ１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝３（←“未設定”←“０”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３（←“未設定”←“ＨＡ１”）、ｏｗｎｅｒ＝１（←“０”←“１”）
と更新する。同様に、リソースＨＡ１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝３（←“未設定”←“０”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３（←“未設定”←“ＰＥ１”）、ｏｗｎｅｒ＝１（←“０”←“１”）
と更新する。

次に、ハードウェアアクセラレータＨＡ１がリソースＲ１を確保する状況について説明する。

プロセッサＰＥ３は先ほど確保したリソースＲ１に係るリソースレジスタ１０を、
ｇｉｄ＿ｒｓ＝３、ｒｑｉｄ＿ｒｓ＝ＨＡ１（←“ＰＥ３”）、ｏｗｎｅｒ＝０（←“１”）
と更新する。

一方で、ハードウェアアクセラレータＨＡ１は、リソースＲ１のリクエストに係るリクエストレジスタ１１の各ビットに、
ｇｉｄ＿ｒｑ＝３、ｒｑｉｄ＿ｒｑ＝ＨＡ１、ｐｒｉｏｒｉｔｙ＝１、ｒｉｄ＝Ｒ１
を設定する。

選択ユニット４は調停の結果として、リクエスト主体となるデバイスＨＡ１とリソースＲ１に係るリソースレジスタ１０のリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）とが等しいハードウェアアクセラレータＨＡ１をリソースＲ１の所有者ＨＡ１と決定し、リソースＲ１のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝３、ｒｑｉｄ＿ｒｓ＝ＨＡ１、ｏｗｎｅｒ＝１（←“０”）
と更新する。なお、本実施形態では、リソースＲ１の所有者がプロセッサＰＥ３に一度更新された後でハードウェアアクセラレータＨＡ１に更新されるため、明示的にリソースＲ１の割り付けを制御している。

ケース２’において、システム処理が終了し、プロセッサＰＥ３及びハードウェアアクセラレータＨＡ０は、それぞれ確保していたリソースＨＡ０，Ｒ０を解放する。このとき、
プロセッサＰＥ３はリソースＨＡ０のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝未設定（←“２”）、ｒｑｉｄ＿ｒｓ＝未設定（←“ＰＥ３”）、ｏｗｎｅｒ＝０（←“１”）
と更新する。また、ハードウェアアクセラレータＨＡ０はリソースＲ０のリソースレジスタ１０の設定を、
ｇｉｄ＿ｒｓ＝未設定（←“２”）、ｒｑｉｄ＿ｒｓ＝未設定（←“ＨＡ０”）、ｏｗｎｅｒ＝０（←“１”）
と更新する。これにより、ケース２’において、リソースＨＡ０，Ｒ０，Ｒ４−１が空きグループＧ１５に属するリソースとなる。

なお、例えばリソースの不足が顕著ではないような場合に、ハードウェアアクセラレータＨＡ０は、優先順位ビット（ｐｒｉｏｒｉｔｙ）に“１”が設定されたリクエストが発生するまで、リソースＲ０の解放を待つこととしてもよい。

＜Ｄ．ケース２’からケース３への移行に係る動作＞
上記のようにケース２からケース２’を介したケース３への移行において、リソースグループｒｇ３のすべてのリソースＲ１，Ｒ６，ＨＡ１が予約グループＧ３に確保され（グラフィック処理に使用可能となり）、かつ、プロセッサＰＥ３がシステム処理を終了しているため、プロセッサＰＥ３はグラフィック処理を実施するために、リソースＲ１，Ｒ６，ＨＡ１のリソースグループビット（ｇｉｄ＿ｒｓ）を一括して“３”から“２”に更新する。具体的には、リソースＨＡ１のリソースレジスタ１０は
ｇｉｄ＿ｒｓ＝２（←“３”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３、ｏｗｎｅｒ＝１
となり、リソースＲ１のリソースレジスタ１０の設定は、
ｇｉｄ＿ｒｓ＝２（←“３”）、ｒｑｉｄ＿ｒｓ＝ＨＡ１、ｏｗｎｅｒ＝１
となり、リソースＲ６のリソースレジスタ１０の設定は、
ｇｉｄ＿ｒｓ＝２（←“３”）、ｒｑｉｄ＿ｒｓ＝ＰＥ３、ｏｗｎｅｒ＝１
となる。更新が終了した後、プロセッサＰＥ３及びハードウェアアクセラレータＨＡ１は第２グループＧ２において、グラフィック処理を実行する。

図８はケース２からケース３への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース２においては、空きグループＧ１５に属するリソースはなく、ケース２からケース３への移行に伴い空きグループＧ１５にはリソースＲ０，Ｒ４−１，ＨＡ０が属している。

以上のように、予約用グループＧ３を設けて、グラフィック処理（１つの処理）に必要なリソースＲ１，Ｒ６，ＨＡ１を予約用グループＧ３を用いてリクエストすることにより、一括して所定の機能の処理（本実施形態では、グラフィック処理）に使用するリソースＲ１，Ｒ６，ＨＡ１を確保することができる。これにより、例えば１つの機能の処理に使用する複数のリソースＲ１，Ｒ６，ＨＡ１をまとめてリクエストするデバイスＰＥ３（ＨＡ１）にとって利便性が高まるとともに、機能の処理に使用する所定数以上（すべて）のリソースＲ１，Ｒ６，ＨＡ１を一括確保することによりリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２の利用率が上がる。また、リソースＲ１，Ｒ６，ＨＡ１がすべて使用可能となったところでリソースＲ１，Ｒ６，ＨＡ１のリソースグループビット（ｇｉｄ＿ｒｓ）を一括して更新してから、機能処理（グラフィック処理）を実施することにより、グループＧ３を再度未使用の予約用グループＧ３として活用することができる。

また、リソースグループｒｇ０〜ｒｇ３を用いたリクエストの優先順位を上げることと予約グループＧ３の活用とを併用することにより、機能処理に使用するリソースＲ１，Ｒ６，ＨＡ１を一括して優先順位を上げて予約グループＧ３に確保することができる。これにより、機能処理に使用するリソースＲ１，Ｒ６，ＨＡ１を一括して確保する時間を短縮することができる。

なお、リソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２の異常が所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２や選択ユニット４により検出された場合には、所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２又は選択ユニット４は異常があるリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２のリソースレジスタ１０のエラービット（ｅｒｒｏｒ）を“１”に設定し、選択ユニット４はビット（ｏｗｎｅｒ）を“１”に設定するものとしてもよい。そして、所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２や選択ユニット４によって正常になったことが確認された場合、所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２や選択ユニット４がエラービット（ｅｒｒｏｒ）を“０”に設定し、選択ユニット４がビット（ｏｗｎｅｒ）を“０”に設定することによってリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２が再度リクエストを受けることができる状態となるようにしてもよい。これにより、異常があるリソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２は、異常状態が正常になるまでリクエスト主体となるデバイス（リクエスト者）ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２から隔離され、正常になった時点でリクエストを受けることができる。

また、上記の説明では、プロセッサＰＥ３はグラフィック処理を実施するために、リソースＲ１，Ｒ６，ＨＡ１のリソースグループビット（ｇｉｄ＿ｒｓ）を一括して“３”から“２”に更新した後にグラフィック処理を実行するものとしたが、更新を行わずに予約グループＧ３においてグラフィック処理を実行してもよい。

また、本実施形態では、映像処理などの機能を１つの機能として記載いたが、例えば映像処理の機能を複数に分割してそれぞれを１つの機能として考えてもよい。

また、特定リソースビット（ｒｇ２，ｒｇ３）は、それぞれ映像処理、グラフィック処理の実行に必要なリソースグループを示しているが、例えば音声処理やシステム処理のような他の処理の実行に必要なリソースグループを示す特定リソースビットを作成してもよい。

また、予約用グループ、空きグループの作成は本実施形態に限定されない。例えば、未使用の別のグループＧ４を予約用グループ又は空きグループとして使用（作成）してもよい。また、複数の予約用グループを作成してもよい。また、予約グループ、空きグループは既存の未使用のグループを使ってもいいし、新規に作成してもよい。

また、本実施形態では、優先順位ビット（ｐｒｉｏｒｉｔｙ）よりもリクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）の方が優先されるが、優先順位は使用するシステム等に応じて設定を変更することが可能であり、例えば、リクエスト者識別ビット（ｒｑｉｄ＿ｒｓ）よりも優先順位ビット（ｐｒｉｏｒｉｔｙ）の優先順位が高くてもかまわない。

また、本実施形態では、レジスタ５は選択ユニット４に備えられているものとして説明したがこれに限定されない。例えば、選択ユニット４の外部にあるレジスタを活用してもよい。

また、所有ビット（ｏｗｎｅｒ）は、選択ユニット４が設定するものとしたが、これに限定されない。例えば、リソースＲ０〜Ｒ６，ＨＡ０〜ＨＡ２の所有者ＰＥ０〜ＰＥ３，ＨＡ０〜ＨＡ２が設定してもよい。

本発明に係るリソース調停システム及び調停方法は、映像処理、音声処理及びグラフィック処理等のメディア処理のためのシステム等に有用である。また、プロセッサが搭載されたテレビ、ムービー、パソコン及び携帯電話などの用途に有用である。

１ プロセッサ（デバイス）
２ ハードウェアアクセラレータ（デバイス、リソース)
３ リソース
１０ リソースレジスタ
１１ リクエストレジスタ
１２ グローバルレジスタ
ＰＥ０〜ＰＥ３ プロセッサ（デバイス）
ＨＡ０〜ＨＡ２ ハードウェアアクセラレータ（デバイス、リソース)
Ｒ０〜Ｒ３ リソース
Ｒ４（Ｒ４−０，Ｒ４−１） 共有リソース（リソース）
Ｒ５（Ｒ５−０，Ｒ５−１） 共有リソース（リソース）
Ｒ６ リソース
ｇｉｄ＿ｒｓ リソースグループビット（第１の識別子）
ｇｉｄ＿ｒｑ リクエストグループビット（第２の識別子）
ｒｑｉｄ＿ｒｓ リクエスト者識別ビット（第３の識別子）
ｐｒｉｏｒｉｔｙ 優先順位ビット（第４の識別子）
ｒｇ０，ｒｇ１，ｒｇ２，ｒｇ３ 特定リソースビット（第５の識別子）
ｒｇ＿ｔｙｐｅ 共有ビット（第６の識別子）
ｒｉｄ リクエスト対象ビット（第７の識別子）
ｅｒｒｏｒ エラービット（第８の識別子）
ｏｗｎｅｒｓｈｉｐ 所有ビット（第９の識別子）
ｒｑｉｄ＿ｒｑ ビット（第１０の識別子）
Ｇ０ 第０グループ（グループ）
Ｇ１ 第１グループ（グループ）
Ｇ２ 第２グループ（グループ）
Ｇ３ 第３グループ（予約用グループ）
Ｇ４ 第４グループ（グループ）
Ｇ１５ 空きグループ

Claims (22)

1. プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するリソース調停システムであって、
   １つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、
   前記リソース毎に設けられ、当該リソースが属するグループを示す第１の識別子を少なくとも有するリソースレジスタと、
   前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子を少なくとも有するリクエストレジスタとを備え、
   第１のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第２の識別子を有する第１のリクエストがなされた場合において、
   前記第１のリクエストの対象となる第１のリソースが解放されたとき、当該第１のリソースのリソースレジスタの前記第１の識別子を、前記予約用グループを示すものに変更し、
   前記第１のリクエストの対象となるすべての前記第１のリソースについてリソースレジスタの前記第１の識別子が前記予約用グループを示すものに変更されたとき、その情報を前記第１のデバイスに通知する
   ことを特徴とするリソース調停システム。
2. 請求項１記載のリソース調停システムにおいて、
   前記第１のリクエストの対象となる前記第１のリソースが解放されたとき、当該第１のリソースのリソースレジスタの前記第１の識別子を、未使用の空きグループを示すものに一旦変更した後、前記予約用グループを示すものに変更する
   ことを特徴とするリソース調停システム。
3. 請求項２記載のリソース調停システムにおいて、
   第２のデバイスが実行予定の処理についてなされた第２のリクエストにおいて、当該第２のリクエストに係る前記第２の識別子が示す第１のグループと、前記第２のリクエストの対象となる第２のリソースのリソースレジスタの前記第１の識別子が示す第２のグループとが同じ場合、前記第２のリソースの解放後、前記第２のデバイスに前記第２のリソースを割り付ける一方、
   前記第１のグループと前記第２のグループとが異なる場合、前記第２のリソースが解放され、かつ、当該第２のリソースのリソースレジスタの前記第１の識別子が前記空きグループを示すものに変更された後に、前記第２のデバイスに前記第２のリソースを割り付ける
   ことを特徴とするリソース調停システム。
4. 請求項１記載のリソース調停システムにおいて、
   前記リソースレジスタは、前記リソースが所有されているか否かを示す第９の識別子を有しており、
   前記リソース調停システムは、前記第１及び第９の識別子の少なくともいずれか一方に基づいて、リソースの解放を判断する
   ことを特徴とするリソース調停システム。
5. 請求項１記載のリソース調停システムにおいて、
   同一のリソースに対する複数のリクエストの優先順位を、所定の条件に基づいて、決定する
   ことを特徴とするリソース調停システム。
6. 請求項５記載のリソース調停システムにおいて、
   前記リクエストは、前記リクエストレジスタに当該リクエストの優先順位を示す第４の識別子を有しており、
   前記リソース調停システムは、前記第４の識別子が示す優先順位に基づいて調停を行う
   ことを特徴とするリソース調停システム。
7. 請求項５記載のリソース調停システムにおいて、
   前記リソースレジスタは、前記リソースが割り付けられたデバイス又は当該リソースの割り付け先の候補となる候補デバイスを示す第３の識別子を有しており、
   前記リクエストは、前記リクエストレジスタにリクエスト対象となるリソースを割り付けるデバイスを示す第１０の識別子を有しており、
   前記リソース調停システムは、リクエスト対象となる第２のリソースのリソースレジスタの前記第３の識別子に示された前記候補デバイスと前記第１０の識別子が示すデバイスとが同一であるリクエストを、同一でないリクエストよりも優先する
   ことを特徴とするリソース調停システム。
8. 請求項７記載のリソース調停システムにおいて、
   優先順位が同等である複数の前記リクエストが前記第２のリソースに対して発生した場合に、当該リクエストにおいて、前記第１０の識別子が示す割り付け先デバイス同士で前記候補デバイスを決定し、当該割り付け先デバイスのうちいずれか１つが、前記第２のリソースのリソースレジスタの前記第３の識別子を、決定した前記候補デバイスを示すものに変更する
   ことを特徴とするリソース調停システム。
9. 請求項５記載のリソース調停システムにおいて、
   第２のデバイスが実行予定の処理についてなされた第２のリクエストにおいて、当該第２リクエストに係る前記第２の識別子が示すグループと、前記第２のリクエストの対象となる、第３のデバイスに割り付けらた第２のリソースのリソースレジスタの前記第１の識別子が示すグループとが同一か否か、及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて、前記第３のデバイスへの前記第２のリソースの解放要求の通知並びに前記第２のデバイスへの競合発生の通知、調停によるリソース確保ありの通知及び調停によるリソース確保なしの通知のうちの少なくともいずれか１つの通知を行うか否かを決定する
   ことを特徴とするリソース調停システム。
10. 請求項５記載のリソース調停システムにおいて、
    前記第１のリクエストの優先順位が所定の優先順位以上に設定されているとき、
    前記第１のリソースが割り付けられている各デバイスに、前記第１のリソースの解放要求と、前記第１のリクエストが前記予約用グループに係るリクエストであることとを通知する
    ことを特徴とするリソース調停システム。
11. 請求項１記載のリソース調停システムにおいて、
    前記リソースレジスタは、所定の条件に合致する前記リソースからなるリソースグループに属するか否かを示す第５の識別子を有する
    ことを特徴とするリソース調停システム。
12. 請求項１１記載のリソース調停システムにおいて、
    複数の前記デバイスによる共有が可能な共有リソースは、前記リソースレジスタが、共有可能数と同数設けられており、
    前記共有リソースの各リソースレジスタの前記第５の識別子は、同一リソースグループに属することを示している
    ことを特徴とするリソース調停システム。
13. 請求項１２記載のリソース調停システムにおいて、
    前記共有リソースが異なる２つ以上の前記グループに属することの許可又は不許可を示す第６の識別子を少なくとも有するグローバルレジスタを備えており、
    前記リソースレジスタは、前記リソースが所有されているか否かを示す第９の識別子を有しており、前記リソースが解放されたとき、前記第１及び第９の識別子の少なくともいずれか一方が、リソースの解放を示すものであり、
    前記リソース調停システムは、
    前記第６の識別子が前記許可を示す前記共有リソースは、当該共有リソースへの第２のリクエストに係る前記第２の識別子が示すグループに関わらず、前記共有可能数の範囲内において前記第２のリクエスト毎にそれぞれ調停される一方、
    前記第６の識別子が前記不許可を示す前記共有リソースは、当該共有リソースへの前記第２のリクエストに係る前記第２の識別子が示す第１のグループと、前記共有リソースの各リソースレジスタの前記第１の識別子が示す第２のグループのうちの少なくとも１つとが異なるとき、当該第１の識別子が前記第１グループと異なるグループを示した前記リソースレジスタがすべて解放を示した後に調停される
    ことを特徴とするリソース調停システム。
14. 請求項１１記載のリソース調停システムにおいて、
    前記第５の識別子は、１つの処理の実行に必要な前記リソースからなるリソースグループに属するか否かを示すものである
    ことを特徴とするリソース調停システム。
15. 請求項１１記載のリソース調停システムにおいて、
    前記リクエストは、前記リクエストレジスタにリクエストの対象である前記リソース又は前記リソースグループを示す第７の識別子を有しており、
    前記リソース調停システムは、前記第７の識別子が前記リソースグループを示すリクエストを、前記第７の識別子が前記リソースを示すリクエストより優先する
    ことを特徴とするリソース調停システム。
16. 請求項１５記載のリソース調停システムにおいて、
    前記第７の識別子が前記リソースグループを示す第２のリクエストの場合、前記リソースグループに属する第２のリソースが割り付けられている各デバイスに前記第２のリソースの解放要求を通知する
    ことを特徴とするリソース調停システム。
17. 請求項１１記載のリソース調停システムにおいて、
    前記第５の識別子が同一の前記リソースグループに属することを示す複数の第２のリソースに、前記予約用グループを示す前記第２の識別子を有する第２のリクエストがなされた場合において、
    前記第２のリソースがすべて前記予約用グループに割り付けられた後に、前記第２のリソースのリソースレジスタの前記第１の識別子を一括して別のグループに更新する
    ことを特徴とするリソース調停システム。
18. 請求項１記載のリソース調停システムにおいて、
    前記リソースレジスタは、前記リソースが異常であることを示す第８の識別子を有しており、
    前記リソース調停システムは、前記第８の識別子が前記リソースの異常を示したとき、異常である前記リソースを調停の対象から外す一方、前記第８の識別子が正常であることを示したときに再び調停の対象とする
    ことを特徴とするリソース調停システム。
19. 請求項１記載のリソース調停システムにおいて、
    前記リソースは、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、前記ハードウェアアクセラレータ、及び前記プロセッサと前記ハードウェアアクセラレータと前記リソースとの接続バスのうちの少なくとも１つを含んでいる
    ことを特徴とするリソース調停システム。
20. 請求項１記載のリソース調停システムにおいて、
    前記ハードウェアアクセラレータは、映像処理ハードウェアアクセラレータである
    ことを特徴とするリソース調停システム。
21. 請求項１記載のリソース調停システムにおいて、
    前記ハードウェアアクセラレータは、音声処理ハードウェアアクセラレータである
    ことを特徴とするリソース調停システム。
22. プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するシステムにおけるリソース調停方法であって、
    前記システムは、
    １つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、
    前記リソース毎に設けられ、当該リソースが属するグループを示す第１の識別子を少なくとも有するリソースレジスタと、
    前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第２の識別子を少なくとも有するリクエストレジスタとを備え、
    前記リソース調停方法は、
    第１のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第２の識別子を有する第１のリクエストがなされた場合において、
    前記第１のリクエストの対象となる第１のリソースが解放されたとき、前記第１のリソースのリソースレジスタの前記第１の識別子を、前記予約用グループを示すものに変更するステップと、
    前記第１のリクエストの対象となるすべての前記第１のリソースについてリソースレジスタの前記第１の識別子が前記予約グループを示すものに変更されたとき、その情報を前記第１のデバイスに通知するステップとを備えている
    ことを特徴とするリソース調停方法。

Images