JP4801371B2 - マルチメディアコンソール上のシステムアプリケーション - Google Patents

Description

本発明は、一般には、マルチメディアコンソールの分野に関する。より詳細には、本発明は、マルチメディアコンソール上でシステム機能を実施するシステムおよび方法を対象とする。

ビデオゲームコンソールなどのマルチメディアコンソールは従来、開発者の「邪魔にならない」オペレーティングシステムを提供してきた。具体的には、従来のビデオゲームコンソール上では、ゲーム開発者は、ハードウェアのほとんどすべての制御を与えられており、オペレーティングシステムは、マルチメディアアプリケーションによって駆動される。ゲームソフトウェアはしばしば特定のプラットフォーム向けに開発されているので、使用可能なハードウェアリソース（メモリ、プロセッサなど）およびその特性（メモリサイズ、プロセッサ速度など）はよく知られている。このアーキテクチャは、開発者に完全な自律性、およびあらゆるＣＰＵサイクルがどのように使用されるかを洞察する力をもたらす。したがって、ソフトウェア開発者は、ハードウェアリソースの使用を管理し、最大にし、また高パフォーマンスのマルチメディアアプリケーションを提供することができる。たとえば、ソフトウェアゲーム開発者は、同じ量のメモリが常に使用可能であり、ＣＰＵが別のアプリケーション、またはゲームリリース後に取り入れられたシステム機能（ｓｙｓｔｅｍ ｆｅａｔｕｒｅ）によって消費されないなどと確信することができる。

この手法の欠点は、ユーザに提供することが望まれるどんなシステム機能もがマルチメディアアプリケーション内に組み込まれなれければならないことである。この手法は、マルチメディア開発者がプログラミングに大きな投資を行うことを必要とする。別の欠点は、それぞれのマルチメディアアプリケーションがシステムリソースに対するそれ独自の特有のユーザインターフェースを提供するので、ユーザの経験が、異なるマルチメディアアプリケーション間で著しく異なり得ることである。

一連のリソース制御のもう一方の側は、アプリケーションがオペレーティングシステムの基本的な機能に対して制限された制御を有する従来のパーソナルコンピュータ（ＰＣ）において見られる。この手法は、アプリケーションによってそれが制御されることを必要とせずに、オペレーティングシステム内に多大な機能をもたらす。さらにこの手法は、複数のアプリケーションが互いに認識することを必要とせずに、複数のアプリケーションが同時に実行されることを実現する。この手法の欠点は、アプリケーションが各ＣＰＵサイクルをほとんど制御できず、それが実行中の唯一のアプリケーションでないと想定するように設計されなければならないことである。したがって、アプリケーションには、ある量の物理ＲＡＭを得られるという、またはかなりの量のＣＰＵ時間を消費する別のアプリケーションによってリソース不足にならない（ｇｅｔ ｓｔａｒｖｅｄ）という特別な保証はない。

マルチメディアコンソールのパワーが増すにつれて、開発者がシステムリソースのほとんどすべての制御を有する既存のマルチメディアコンソールオペレーティングシステムの利点を維持しながらマルチメディアアプリケーションにシステムサービスを提供する需要が恐らく高まる。

したがって、システムの動作およびハードウェアのリソースに対するマルチメディアアプリケーションの高いレベルの制御を維持しながら、より多くのシステム機能を可能にするためにマルチメディアコンソール上でシステムサービスを提供するためのシステムおよび方法が求められている。

本発明は、マルチメディアコンソールのハードウェアリソースに対するかなりの制御をマルチメディアが保持することを可能しながら、システムアプリケーションを介してシステム機能を提供することによって、既存のマルチメディアコンソールの制限に対処するシステムおよび方法を対象とする。マルチメディアコンソールの所定量のハードウェアリソースがシステムアプリケーション用に予約され、ハードウェアリソースの残りは、マルチメディアアプリケーションによって制御される。このようにして、マルチメディアアプリケーションは、ハードウェアリソースをほとんど制御できない、従来のパーソナルコンピューティング（ＰＣ）オペレーティングシステム上で実行されるアプリケーションとは異なり、ハードウェアリソースに対してかなりの制御を保持する。したがって、マルチメディアアプリケーションは、従来のシステムで必要とされるようなシステム機能を直接にサポートする必要がなく、依然としてシステム機能が提供され得る。システムアプリケーションは予約されたハードウェアリソースを介してシステム機能を提供し、マルチメディアアプリケーションは、残りのハードウェアリソース上で実行される。さらに、予約されたリソースの量は、グラフィック処理装置によって生成された割込みに基づくものとすることができる。このようにして、システムアプリケーションは、ハードウェアリソースの需要が少ない可能性が高いときに実行され得る。

本明細書で説明するシステムおよび方法は、セットトップボックス、組込みシステムなど、他の制限付きの環境で実施することができる。本発明の追加の特徴は、添付の図面を参照して進行する、例示的な実施形態についての以下の詳細な説明から明らかになる。

前述の要約、および例示的な実施形態についての以下の詳細な説明は、添付の図面と併せ読む場合によりよく理解される。本発明について説明するために本発明の例示的な実施形態が図面に示されているが、しかし、本発明は、開示する具体的な方法および手段に限定されない。

図１に、本発明の態様が実施され得るマルチメディアコンソール１００の機能構成要素を示す。マルチメディアコンソール１００は、レベル１（Ｌ１）キャッシュ１０２、レベル２（Ｌ２）キャッシュ１０４およびフラッシュＲＯＭ（読取り専用メモリ）１０６を含む中央処理装置（ＣＰＵ）１０１を含む。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、一時的にデータを格納し、したがってメモリアクセスサイクルの数を減らし、それによって処理速度およびスループットを改善する。マルチメディアコンソール１００が電源投入される場合、フラッシュＲＯＭ１０６は、ブートプロセスの最初のフェーズの間にロードされる実行可能コードを格納し得る。代替として、最初のブートフェーズの間にロードされる実行可能コードは、ＦＬＡＳＨメモリ装置（図示せず）内に格納され得る。さらに、ＲＯＭ１０６は、ＣＰＵ１０１とは別個に置くことができる。

グラフィック処理装置（ＧＰＵ：ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１０８およびビデオエンコーダ／ビデオコーデック（コーダ／デコーダ）１１４は、高速および高解像度グラフィック処理のためのビデオ処理パイプラインを形成する。データは、バスを介してグラフィック処理装置（ＧＰＵ）１０８からビデオエンコーダ／ビデオコーデック１１４に運ばれる。ビデオ処理パイプラインは、テレビまたは他の表示装置への伝送のため、Ａ／Ｖ（オーディオ／ビデオ）ポート１４０にデータを出力する。メモリコントローラ１１０は、それだけに限定されないが、ＲＡＭ（ランダムアクセスメモリ）などの様々なタイプのメモリ１１２へのプロセッサアクセスを実行するために、ＧＰＵ１０８およびＣＰＵ１０１に接続される。

マルチメディアコンソール１００は、好ましくはモジュール１１８上で実装されたＩ／Ｏコントローラ１２０、システム管理コントローラ１２２、オーディオ処理装置１２３、ネットワークインターフェースコントローラ１２４、第１のＵＳＢホストコントローラ１２６、第２のＵＳＢホストコントローラ１２８、およびフロントパネルＩ／Ｏサブアセンブリ１３０を含む。ＵＳＢコントローラ１２６および１２８は、周辺コントローラ１４２（１）〜１４２（２）、無線アダプタ１４８および外部メモリ装置１４６（フラッシュメモリ、外部ＣＤ／ＤＶＤ ＲＯＭドライブ、取出し可能媒体など）のホストとして働く。ネットワークインターフェース１２４および／または無線アダプタ１４８は、ネットワーク（インターネット、ホームネットワークなど）へのアクセスを提供し、またイーサネット（登録商標）カード、モデム、Ｂｌｕｅｔｏｏｔｈモジュール、ケーブルモデムなどを含めて、多岐にわたる様々な有線または無線のインターフェース構成要素のうちのいずれかであり得る。

ブートプロセスの間にロードされるアプリケーションデータを格納するために、システムメモリ１４３が設けられる。メディアドライブ１４４が設けられ、それは、ＤＶＤ／ＣＤドライブ、ハードドライブまたは他の取出し可能メディアドライブなどを含み得る。メディアドライブ１４４は、マルチメディアコンソール１００の外部にあることも、内部にあることもある。アプリケーションデータは、マルチメディアコンソール１００による実行、再生などのために、メディアドライブ１４４を介してアクセスすることができる。メディアドライブ１４４は、シリアルＡＴＡバスや他の高速接続（ＩＥＥＥ１３９４など）を介してＩ／Ｏコントローラ１２０に接続される。

システム管理コントローラ１２２は、マルチメディアコンソール１００の可用性の保証に関する様々なサービス機能を提供する。オーディオ処理装置１２３およびオーディオコーデック１３２は、ハイファイおよびステレオ処理を含む対応するオーディオ処理パイプラインを形成する。オーディオデータは、通信リンクを介してオーディオ処理装置１２３とオーディオコーデック１３２の間で運ばれる。オーディオ処理パイプラインは、外部のオーディオプレーヤ、またはオーディオ機能を備える装置による複製のために、Ａ／Ｖポート１４０にデータを出力する。

フロントパネルＩ／Ｏサブアセンブリ１３０は、パワーボタン１５０および取出しボタン１５２の機能、ならびに任意のＬＥＤ（発光ダイオード）またはマルチメディアコンソール１００の外面上に露出された他のインジケータをサポートする。システム電力供給モジュール１３６は、マルチメディアコンソール１００の構成要素に電力を供給する。ファン１３８は、マルチメディアコンソール１００内の回路を冷却する。

ＣＰＵ１０１、ＧＰＵ１０８、メモリコントローラ１１０、およびマルチメディアコンソール１００内の様々な他の構成要素は、シリアルおよびパラレルバス、メモリバス、周辺バス、および様々なバス構造のいずれかを使用するプロセッサまたはローカルバスを含めて、１つまたは複数のバスを介して相互接続される。

マルチメディアコンソール１００が電源投入され、または再ブートされる場合、アプリケーションデータは、システムメモリ１４３からメモリ１１２および／またはキャッシュ１０２、１０４内にロードされ、ＣＰＵ１０１上で実行され得る。アプリケーションは、マルチメディアコンソール１００上で使用可能な様々なメディアタイプに移動する場合に、一貫したユーザ体験を提供するグラフィカルユーザインターフェースを提示し得る。動作において、メディアドライブ１４４内に含まれるアプリケーションおよび／または他のメディアがメディアドライブ１４４から起動されまたは再生されて、マルチメディアコンソール１００に追加の機能を提供し得る。

マルチメディアコンソール１００は、単にシステムをテレビまたは他の表示装置に接続することによって、スタンドアロンのシステムとして動作させることができる。このスタンドアロンモードでは、マルチメディアコンソール１００は、１人または複数のユーザがシステムと対話し、映画を鑑賞し、音楽を聴くことなどを可能にする。しかし、ネットワークインターフェース１２４または無線アダプタ１４８を介して使用可能になるブロードバンド接続の統合により、マルチメディアコンソール１００は、より大規模なネットワークコミュニティに参加する一員として動作させることができる。

図２に、図１の例示的なマルチメディアコンソールのさらなる詳細を示す。図２に示すように、ＣＰＵ１０１は、３つのＣＰＵ、ＣＰＵ１０１Ａ、ＣＰＵ１０１ＢおよびＣＰＵ１０１Ｃを含む。図示するように、それぞれのＣＰＵは、対応するＬ１キャッシュ１０２（たとえばそれぞれＬ１キャッシュ１０２Ａ、１０２Ｂおよび１０２Ｃ）を含む。図示するように、それぞれのＣＰＵ１０１Ａ〜Ｃは、Ｌ２キャッシュ１０４と通信している。したがって、個々のＣＰＵ１０１Ａ、ＢおよびＣは、Ｌ２キャッシュ１０４を共有する。Ｌ２キャッシュ１０４は複数のＣＰＵ間で共有されるので、システムアプリケーション用にＬ２キャッシュの一部を予約するための技術を実装することは複雑となる可能性がある。３つのＣＰＵが示されているが、任意の数のＣＰＵが存在し得る。

図１および２に示すマルチメディアコンソールは、たとえばゲームなどのマルチメディアアプリケーションを実行するために使用され得る典型的なマルチメディアコンソールである。マルチメディアアプリケーションは、たとえばシステム設定、音声チャット、ネットワーク化されたゲーム、ネットワークを介して他のユーザと対話する能力、電子メール、ブラウザアプリケーションなどを含めたシステム機能を付けて向上させることができる。こうしたシステム機能によって、たとえばそれぞれ異なる場所にいるプレーヤがインターネットを介して共通のゲームをプレーすることができるなど、マルチメディアコンソール１００の機能の改善が可能になる。

またシステム機能は、時間の経過につれて更新され、またはマルチメディアアプリケーションに追加されることができる。本明細書で説明するシステムおよび方法は、こうしたシステム機能を提供するために開発者にシステムアプリケーションに対してかなりの修正を行うことを求めるのではなく、マルチメディア開発者が、マルチメディアアプリケーションと連携して働く別個のシステムアプリケーションを介してシステム機能を提供できるようにする。たとえば、システムアプリケーションは、ネットワーク能力（ｎｅｔｗｏｒｋｅｄ ｃａｐａｂｉｌｉｔｙ）に関する機能を実施することができ、それによって、マルチメディア（ゲームなど）開発者によってほとんど作業を行わずに、マルチメディアアプリケーションをネットワーク化された能力を提供するように容易に適応させることができる。従来のアーキテクチャでは、マルチメディア開発者は、ネットワーク能力を提供するようにマルチメディアアプリケーションを修正するのに多大な開発努力を払わなければならないことがある。開発者によっては、関連コストのため、こうした機能の開発を見送ることがある。こうした機能を実施するシステムアプリケーションは、マルチメディア開発者に、そうでない場合よりも多くの機能を含めるように促し得る。

アプリケーション／オペレーティングシステムを対象とするシステムおよび方法が提供される。従来のマルチメディアコンソールオペレーティングシステムとは異なり、このシステムおよび方法は、開発者が直接マルチメディアアプリケーション内でシステム機能へのユーザアクセスを明示的に取り入れまたは扱うことなしに、システムアプリケーションを使用してシステム機能を実施できるようにする。システムアプリケーションを介してシステム機能へのアクセスを提供することによって、ユーザは、マルチメディアアプリケーションからシステムリソースの制御を不確かに取り上げることなしに、ＰＣオペレーティングシステムのような同時アプリケーションおよび豊富なシステム機能の利益を得ることができる。ゲーム開発者などのマルチメディア開発者は一般に、システム動作は経時的に安定および決定的であると想定するので、システムアプリケーションは、製品の存続期間にわたって一定量のシステムリソースを取り、それが実行時に様々なリソースシグニチャ（ｓｉｇｎａｔｕｒｅ）を提示しないように制限され得る。このシステムおよび方法は、マルチメディアアプリケーションにシステム機能を提供するシステムアプリケーションによって使用するために、マルチメディアコンソールハードウェアリソースの一部を予約する。システムアプリケーションについて一貫した不変のリソース使用のシグニチャを提供するために、複数の異なるシステムリソースが管理され得る。こうしたリソースは、ＣＰＵ、キャッシュメモリ、メインメモリおよびオーディオチャネル、ゲームコントローラ入力などを含み得る。

次に図３を参照すると、マルチメディアコンソール上でシステムアプリケーションを提供するための例示的な方法のフローチャートが示されている。図３に示すように、マルチメディアコンソール１００が電源投入されまたは再ブートされる場合、ステップ３００で、マルチメディアコンソール１００は、オペレーティングシステムカーネルをブートする。たとえば、マルチメディアコンソール１００は、オペレーティングシステムカーネルを開始するために、ＲＯＭ１０６に格納されたブートコードを実行し得る。

ステップ３０５で、オペレーティングシステムカーネルは、システムアプリケーション用のリソースを予約する。たとえば、オペレーティングシステムカーネルは、システムアプリケーション用に所定の量のメモリ（５ＭＢなど）を予約することができ、この予約されたメモリを一般にマルチメディアアプリケーションが使用できるようにしない。カーネル、ドライバ、システムアプリケーションおよび他のシステム関連コードは、この予約されたメモリ内に常駐し得る。システムアプリケーションがメモリの全体量より少ない量を必要とする場合、カーネルは一般に、マルチメディアアプリケーションが一定量の使用可能メモリを見ることができるように所定量のメモリをさらに割り当て、予約する。具体的には、メモリ予約は、起動カーネル、システムアプリケーションおよびドライバを含むのに十分なほど大きいことがある。この予約によって、マルチメディアコンソールの存続期間にわたって新しいシステムアプリケーションおよびドライバを受け入れ、またシステムアプリケーションおよびドライバの占有スペースの予想された任意のサイズ拡大が可能になり得る。さらに、オペレーティングシステムカーネルは、マルチメディアアプリケーションとシステムアプリケーションの間の通信において使用するために、第２の所定量のメモリを予約することができる。

ステップ３０５で、オペレーティングシステムカーネルは、システムアプリケーションによって使用するための所定の数のオーディオチャネル（モノラルストリーム）を予約することもできる。たとえば、典型的なマルチメディアコンソールでは、およそ３００個の使用可能チャネルのうちから１０個のオーディオチャネルが予約され得る。このようにして、予約されたオーディオチャネルは、左右の音声効果のため７．１オーディオおよび追加の２音声をサポートし得る。予約されたチャネルは一般に、マルチメディアアプリケーション（ゲームなど）によって使用できるようにしない。

この例示的な１組のリソースが、予約され得るシステムリソースの限定的または網羅的なリストであることは意図されていない。こうしたリソースはシステムブート時に予約されるので、予約されたリソースは、マルチメディアアプリケーションから見ると存在しない。

ステップ３１０で、オペレーティングシステムカーネルは、ドライバをロードする。ドライバは、割込みを設定するＧＰＵドライバを含み得る。この割込みは、ＧＰＵ割込み、たとえばビデオ出力がビデオ表示装置上の所定の走査線に達した場合に割込みを生成するプログラマブルな走査線とすることができ、また別の適切な割込みソースでもよい。ＧＰＵ割込みを使用して、ＧＰＵビデオフレームとの同期を保つことができ、またシステムアプリケーションは、ＧＰＵからの走査線割込みに応答してスケジューリングされ得る。

ステップ３１５で、ＧＰＵ割込みが発生する場合、オペレーティングシステムカーネルは、システムアプリケーションマネージャ（ＳＡＭ：ｓｙｓｔｅｍ ａｐｐｌｉｃａｔｉｏｎ ｍａｎａｇｅｒ）スレッドを開始する。ＳＡＭスレッドは、どのシステムアプリケーションがどのＣＰＵ上で実行され、またいつそれが実行されるかを管理する。

ステップ３２０で、ＳＡＭスレッドは、実行される各システムアプリケーションについてシステムアプリケーションＳＡスレッドを作成する。

ステップ３２５で、オペレーティングシステムカーネルは、ＳＡＭスレッドの実行をスケジューリングする。

ステップ３３０で、ＳＡＭスレッドは、どのＳＡスレッドを実行するかを順次指示し、ステップ３３５で、指示されたＳＡスレッドが実行される。カーネルは一般に、ＣＰＵ上のＳＡスレッドの実際のスケジューリングを取り扱う。

ステップ３４０で、システムアプリケーション終了割込み（ＧＰＵ垂直ブランク割込み（ＶＢＩ：ｖｅｒｔｉｃａｌ ｂｌａｎｋ ｉｎｔｅｒｒｕｐｔなど）がＧＰＵによって生成されていない場合、この方法は、ステップ３３０に戻って、別のＳＡスレッドを実行する。システムアプリケーション終了割込みが生成された場合、ステップ３４５で、オペレーティングシステムカーネルは、ＳＡＭスレッドを停止する。ステップ３３０または３３５の間のいずれかの時点でシステムアプリケーション終了割込みが生成された場合もまた、現在実行中のＳＡスレッドが停止され、後で実行するためにスケジューリング変更され得る。

上述したように、図２の例示的なマルチメディアコンソール１００は、３つのＣＰＵを含む。（たとえば図３に関連して上記で説明したように割込みを介して実施される）ＣＰＵ時間の予約は、様々なやり方でＣＰＵ間で分配され得る。たとえば、マルチメディアアプリケーション（ゲームなど）は、第１ＣＰＵ１０１Ａ上にシステムアプリケーションが実行されていない状態で、第１ＣＰＵ１０１Ａ上で実行され得る（また他のＣＰＵ上で実行することもできる）。システムアプリケーションは、場合によっては他の２つのＣＰＵ、１０１Ｂおよび１０１Ｃ上でスケジューリングされ得る。システムアプリケーションは、ＣＰＵ１０１Ｂ上のＸ％のＣＰＵ処理時間、およびＣＰＵ１０１Ｃ上のＹ％のＣＰＵ処理時間でスケジューリングされ得る。さらに、Ｘ％およびＹ％の処理時間は、ビデオフレーム処理の終了時にスケジューリングされ得る。Ｘ％とＹ％の処理時間は、等しいことも（すなわち対称）、等しくない（すなわち非対称）のこともある。さらに、Ｘ％およびＹ％の処理時間の判断は、システムアプリケーションの設計要件に基づき得る。

システムアプリケーションの実行は、マルチメディアコンソールの典型的な特性を利用するために、周知の時間（ビデオフレーム処理の終了時など）にスケジューリングされ得る。たとえば、システムアプリケーションは、ほとんどのＣＰＵ処理が終了したはずのビデオフレーム終了時に実行され得る。システムアプリケーションは、時間の影響を受けやすいまたは時間依存型の（ｔｉｍｅ−ｃｒｉｔｉｃａｌ）コード（音声チャットオーディオ、ネットワークインターフェースなど）が十分な実行時間を得ることができるように、定期的に実行することができる。さらに、ＣＰＵ１０１Ｂは時間依存型のシステムアプリケーション（音声など）用に予約することができ、ＣＰＵ１０１Ｃは、非時間依存型のシステムアプリケーション（電子メールなど）用に予約することができる。

システムアプリケーションが予約されたＣＰＵ時間を使用しない場合、このシステムは、残りの処理時間をするために、アイドル状態のシステムスレッドをスケジューリングすることができる。このようにして、マルチメディアアプリケーションには、比較的に一定のシステムリソースのシグニチャが見える。

ビデオフレームの最後にシステムアプリケーションを実行することによって、ほとんどのマルチメディアアプリケーションはビデオフレーム終了の前に完了されているので、キャッシュメモリ（具体的にはＬ２キャッシュ１０４）への影響が低減され得る。これによって、Ｌ２キャッシュ１０４を直接に管理する複雑な努めが回避される（たとえばシステムアプリケーション用にＬ２キャッシュ１０４の別個の部分を直接に予約する）。そうではなく、図４に示すように、システムアプリケーションは、（ＣＰＵへのＧＰＵ割込みに基づいて）ビデオフレームの最後に予測可能な一定の頻度で実行される。ほとんどのマルチメディアアプリケーションがビデオフレームの終了前に処理を完了し（またはほとんどそうであり）、したがってこの特定の時点で実行されているシステムアプリケーションは、Ｌ２キャッシュの使用に混乱を生じさせる可能性が低いと予想される。

図２の各ＣＰＵの処理の時系列図である図４に示すように、ＣＰＵ１０１Ａは、マルチメディアアプリケーション（ゲームコードなど）だけを実行する。ＣＰＵ１０１Ｂおよび１０１Ｃは、ＧＰＵ割込みによる中断までマルチメディアアプリケーションを実行する（またＣＰＵ１０１Ｂおよび１０１Ｃは、図４に示す第１の時間部分ではどのマルチメディアアプリケーションコードをも実行していないことがある）。図示するように、ＣＰＵ１０１Ｃは、第１のＧＰＵ割込み時までマルチメディアアプリケーションを実行する。その時点で、ＣＰＵ１０１Ｃは、システムアプリケーション（ＳＡ）を実行し始める。同様に、ＣＰＵ１０１Ｂは、第２のＧＰＵ割込み時までマルチメディアアプリケーションを実行する。その時点で、ＣＰＵ１０１Ｂは、システムアプリケーション（ＳＡ）を実行し始める。またシステムアプリケーションマネージャ（ＳＡＭ）は、ＣＰＵ１０１Ｂ上でも実行され得るが、ＣＰＵ１０１Ｃ上で実行される。さらに、ＣＰＵ予約量は、予約されたＣＰＵ使用がシステムアプリケーションによって使用されていない場合には任意の未使用サイクルを消費するアイドル状態スレッドを使用することによって、実質上一定レベルに維持することができる。

システムアプリケーションはユーザ入力を見込み得るが、しかし、従来のマルチメディアアプリケーションは、（たとえばゲームコントローラの「ゲームパッド」入力、コントローラ１４２（１）および１４２（２）を介した）ユーザ入力に対する完全な制御を有する。したがって、ユーザ入力またはゲームコントローラ入力は、マルチメディアアプリケーションとシステムアプリケーションの間で適切に共有することができる。ある実施形態では、ユーザ入力は、システムアプリケーションとマルチメディアアプリケーションの間で透過的に共有される。一般にゲームは、ゲーム入力装置からシステムアプリケーションへとユーザ入力フォーカスを失う時、またはそれがゲームに再び戻される時を認識していない。ユーザ入力フォーカスがシステムアプリケーションに切り換えられる場合に、ゲームパッドの状態（どのボタンが押下されているか）が維持される。それが入力フォーカスをもたない間にゲームによってゲームパッド上に設定された状態は、ユーザ入力フォーカスがゲームに戻されるまでキューに入れられ、維持され得る。たとえば、システムアプリケーションに入力フォーカスがある間にゲームがゲームパッド振動状態（ゲームパッド内で振動生成モータが実行されて、ゲームパッド自体を振動させる状態など）を設定する場合、この振動状態は、ユーザ入力フォーカスがマルチメディアアプリケーションに戻された場合に整合性が取れるようにキューに入れられる（更新される）。入力装置は、予約されるリソースではないが、それぞれが装置の適切なフォーカスを有するように、システムアプリケーションとマルチメディアアプリケーションの間で切り換えられる。アプリケーションマネージャは、マネージャアプリケーションの知識なしに入力ストリームの切換えを制御することができ、ドライバは、フォーカス切換えに関する状態情報を維持することができる。ユーザがシステムアプリケーションなどと対話する場合のマルチメディアアプリケーションの停止など、他のタイプのユーザインタラクションが可能である。

システムアプリケーション用に予約された一部の時間の間にＣＰＵ上でシステムアプリケーションが実行されている場合に、高優先度のタスク（たとえばオーディオチャネル用の特定のデジタル符号化などのマルチメディアアプリケーションタスクなど）が実行されるべきケースが存在し得る。たとえば、オーディオタスクを実行すべきであり、またはユーザが望ましくない可聴のポップ音を聞き得る場合が存在し得る。しかし同時に、システムアプリケーションが、その仕事を完了するのに十分なほどのプロセッサ時間を受け取るのが望ましい。そうでない場合、たとえば時間切れのダウンロードなど、望ましくない様々な結果が生じ得る。このような状況では、（ＳＡＭと連携する）カーネルは、システムアプリケーション「時間枠（ｗｉｎｄｏｗ）」の間（ＧＰＵ割込みとＶＢＩ割込みの間など）に高優先度タスクをスケジューリングし得る。さらに、（ＳＡＭと連携する）カーネルは、システムアプリケーション時間枠の間の高優先度タスクのそのスケジューリングのためにシステムアプリケーションがどのくらいのプロセッサ時間を失ったかを追跡し得る。（ＳＡＭと連携する）カーネルは、ＶＢＩの後（次のビデオフレーム開始時など）にシステムアプリケーションを実行することによって、この失われたプロセッサ時間をシステムアプリケーションに「返す（ｃｒｅｄｉｔ ｂａｃｋ）」する。したがって、実際に、システムアプリケーションは、結局は同じ量の処理時間を受け取ることになり、時間内で実行がシフトされる。しかし、このビデオフレームの開始に再スケジューリングすることは、ビデオフレームの最後の場合よりも大きいＬ２キャッシュへの影響があり得る。またシステムアプリケーションは、ビデオフレームの開始時の一部のプロセッサ時間の間にさえ、高優先度タスクによって中断され得る。

図５に、高優先度タスクに対処するための例示的なフローチャートが示されている。ステップ５１０で、カーネルは、システムアプリケーションの時間枠（ＧＰＵ割込みと、システムアプリケーションを実行するために予約されたＶＢＩとの間の時間など）においてＣＰＵ上でシステムアプリケーションが実行されている間に高優先度タスクが保留されていると判断する。ステップ５１５で、カーネルは、システムアプリケーション時間枠内で実行されているシステムアプリケーションを停止する。ステップ５２０で、高優先度タスクを、停止されたシステムアプリケーションをかつて実行していたＣＰＵ上で実行するようにスケジューリングする。ステップ５２５で、カーネルは、前に停止されたシステムアプリケーションを次のビデオフレームの最初（ＶＢＩの後など）に実行するようにスケジューリングする。

図６は、図５のフローチャートの実施について図示する、図２の各ＣＰＵの処理の時系列図である。図６に示すように、ＣＰＵ１０１Ａは、マルチメディアアプリケーション（ゲームコードなど）だけを実行する。ＣＰＵ１０１Ｂおよび１０１Ｃは、ＧＰＵ割込みによる中断までマルチメディアアプリケーションを実行する。図示するように、ＣＰＵ１０１Ｃは、第１のＧＰＵ割込み時までマルチメディアアプリケーションを実行する。その時点で、ＣＰＵ１０１Ｃは、ＳＡおよびＳＡＭを実行し始める。同様に、ＣＰＵ１０１Ｂは、第２のＧＰＵ割込み時までマルチメディアアプリケーションを実行する。その時点で、ＣＰＵ１０１Ｂは、ＳＡを実行し始める。しかし、ＣＰＵ１０１Ｂ上で実行されているＳＡは、保留中の高優先度タスク（ＨＰ：ｈｉｇｈ ｐｒｉｏｒｉｔｙ）のためにカーネルによって中断される。次いで、カーネルは、ＨＰをＣＰＵ１０１Ｂ上で実行されるようにスケジューリングする。システムアプリケーション「時間枠」内に処理時間が残っていない場合、カーネルは、前に停止されたＳＡを、次のＶＢＩの後にＣＰＵ１０１Ｂ上で実行されるようにスケジューリングする。

上述したように、システムアプリケーションは、マルチメディアアプリケーションが実行されている間にシステム機能を提供する。ユーザは、要望に応じて、システムアプリケーションとも、マルチメディアアプリケーションとも対話することができる。既存のオペレーティングシステムアーキテクチャが、マルチメディアアプリケーションがマルチメディアアプリケーション機能とシステム機能の両方を管理することを求める場合、本明細書で説明したシステムおよび方法は、別個のシステムアプリケーションのためのハードウェアリソースを提供する。したがって、マルチメディアアプリケーションはマルチメディアアプリケーション機能を管理することができ、システム機能は、システムアプリケーションを介して提供され得る。

上記内容が示しているように、本発明は、マルチメディアコンソール上でシステムアプリケーションを提供することを対象としている。本明細書で開示した広範な発明の概念から逸脱せずに、上述の例示的な諸実施形態に対して変更が行われ得ることが理解されよう。たとえば、例示的な一実施形態は３つのＣＰＵを用いて実施されるように上記で説明されているが、本発明は、任意の数のＣＰＵで実施され得ることが理解されよう。さらに、例示的な実施形態はメモリ予約として説明されているが、ＣＰＵ時間およびオーディオチャネル、他のマルチメディアコンソールリソースを予約することもできる。したがって、本発明は、開示した特定の諸実施形態に限定されないが、添付の特許請求の範囲によって定義される本発明の精神および範囲内のすべての修正を網羅することを意図している。

本発明の態様が実施され得る例示的なマルチメディアコンソールを示すブロック図である。 本発明の態様が実施され得る図１の例示的なマルチメディアコンソールをより詳細に示すブロック図である。 本発明の一態様による、マルチメディアコンソール上のシステムアプリケーションを介してシステム機能を提供するための方法のフローチャートである。 本発明の一態様による、マルチメディアコンソール上のシステムアプリケーションを介してシステム機能を提供するための例示的なタイミングを示す図である。 本発明の一態様による、高優先度タスクの処理を含む、マルチメディアコンソール上のシステムアプリケーションを介してシステム機能を提供するための方法の別のフローチャートである。 本発明の一態様による、高優先度タスクの処理を含む、マルチメディアコンソール上のシステムアプリケーションを介してシステム機能を提供するための例示的なタイミングを示す図である。

符号の説明

１００ マルチメディアコンソール
１０１ 中央処理装置
１０２ レベル１キャッシュ
１０４ レベル２キャッシュ
１０８ グラフィック処理装置
１１０ メモリコントローラ
１１２ メモリ
１１４ ビデオエンコーダ／ビデオコーデック
１２０ Ｉ／Ｏコントローラ
１２２ システム管理コントローラ
１２３ オーディオ
１２６ ＵＳＢコントローラ
１２８ ＵＳＢコントローラ
１３０ フロントパネルＩ／Ｏサブアセンブリ
１３２ オーディオコーデック
１３６ システムパワー供給モジュール
１３８ ファン
１４０ Ａ／Ｖポート
１４２ コントローラ（１）
１４２ コントローラ（２）
１４３ システムメモリ
１４４ メディアドライブ
１４６ メモリ装置
１４８ 無線アダプタ

Claims (34)

1. 中央処理装置、グラフィック処理装置およびメモリを含むマルチメディアコンソール上でシステムアプリケーションを提供するための方法であって、
   前記マルチメディアコンソールの所定量のハードウェアリソースを予約するステップと、
   前記所定量の予約されたハードウェアリソースを実質上使用して前記システムアプリケーションを実行するステップと、
   残りの予約されていない前記ハードウェアリソースを実質上使用してマルチメディアアプリケーションを実行するステップと
   を含むことを特徴とする方法。
2. 前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーション用に所定量のメモリを予約するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記マルチメディアアプリケーションと前記システムアプリケーションの間の通信を実施するために、第２の所定量のメモリを予約するステップをさらに含むことを特徴とする請求項２に記載の方法。
4. 前記所定量のハードウェアリソースを予約するステップは、マルチメディアアプリケーションに関連するシステムアプリケーションをサポートするために決定された所定量のメモリを予約するステップを含むことを特徴とする請求項２に記載の方法。
5. 複数のシステムアプリケーションのうちのどのシステムアプリケーションが実行されるかを優先順位付けするシステムアプリケーションマネージャを実行するステップをさらに含むことを特徴とする請求項１に記載の方法。
6. 前記システムアプリケーションはネットワーク能力を提供することを特徴とする請求項１に記載の方法。
7. 複数のシステムアプリケーションのうちのどのシステムアプリケーションが実行されるかを優先順位付けし、また前記複数のシステムアプリケーションの各システムアプリケーションが、前記グラフィック処理装置によって生成される所定数のフレームごとに少なくとも１回実行されるようにスケジューリングさせるシステムアプリケーションマネージャを実行するステップをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記所定量のハードウェアリソースを予約するステップは、少なくとも１つのオーディオチャネルを予約するステップを含むことを特徴とする請求項１に記載の方法。
9. 前記所定量のハードウェアリソースを予約するステップは、少なくとも１０個のオーディオチャネルを予約するステップを含むことを特徴とする請求項１に記載の方法。
10. 前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションの実行のために中央処理装置時間の一部を予約するステップを含むことを特徴とする請求項１に記載の方法。
11. 前記予約されたプロセッサ使用が前記システムアプリケーションによって使用されていない場合、アイドル状態のスレッドを含むシステムアプリケーションの実行のために、前記一部の中央処理装置時間の間の未使用のプロセッササイクルを消費するステップをさらに含むことを特徴とする請求項１０に記載の方法。
12. 前記マルチメディアアプリケーションと前記システムアプリケーションの間で入力装置を共有するステップをさらに含むことを特徴とする請求項１に記載の方法。
13. 前記マルチメディアコンソールは第１および第２の中央処理装置を含み、前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションの実行のために前記第２中央処理装置の一部の処理時間を予約し、前記第１処理装置の一部の処理時間を予約せず、それによって前記第１中央処理装置は前記マルチメディアアプリケーションの実行専用になるステップを含むことを特徴とする請求項１に記載の方法。
14. 前記マルチメディアコンソールは第１、第２および第３の中央処理装置を含み、前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションの実行のために前記第２および第３中央処理装置の一部の処理時間を予約し、前記第１中央処理装置の一部の処理時間を予約せず、それによって前記第１中央処理装置は前記マルチメディアアプリケーションの実行専用になるステップを含むことを特徴とする請求項１に記載の方法。
15. 前記第２中央処理装置の前記予約された部分の処理時間は、前記第３中央処理装置の前記予約された部分の処理時間と同じであることを特徴とする請求項１４に記載の方法。
16. 前記第２中央処理装置の前記予約された部分の処理時間は、前記第３中央実行装置の前記予約された部分の処理時間と異なることを特徴とする請求項１４に記載の方法。
17. 前記第２中央処理装置は時間依存型のシステムアプリケーションを実行し、前記第３中央処理装置は、非時間依存型のシステムアプリケーションを実行することを特徴とする請求項１４に記載の方法。
18. 中央処理装置と
    グラフィック処理装置と、
    前記グラフィック処理装置と通信する書込み可能メモリと、
    前記中央処理装置と通信する第２のメモリとを含むマルチメディアコンソールであって、
    前記第２メモリは、予約された所定量のハードウェアリソースを使用してシステムサービスを提供するシステムアプリケーションを実行するために、前記マルチメディアコンソールの前記所定量のハードウェアリソースの予約を実施する実行可能コードを含み、
    前記システムアプリケーションは、前記マルチメディアコンソール上で実行されるマルチメディアアプリケーションと並列に実行され、前記マルチメディアアプリケーションは、前記実行可能コードによって予約されないシステムリソースを制御し、前記マルチメディアアプリケーションは、実質上残りの予約されない前記ハードウェアリソース内で実行される
    ことを特徴とするマルチメディアコンソール。
19. 前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーション用に所定量のメモリを予約するステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
20. 前記第２メモリは、前記マルチメディアアプリケーションと前記システムアプリケーションの間の通信を実施するために第２の所定量のメモリを予約するための実行可能コードをさらに含むことを特徴とする請求項１９に記載のマルチメディアコンソール。
21. 前記所定量のハードウェアリソースを予約するステップは、マルチメディアアプリケーションと関連するシステムアプリケーションをサポートするために決定された所定量のメモリを予約するステップを含むことを特徴とする請求項１９に記載のマルチメディアコンソール。
22. 前記第２メモリは、複数のシステムアプリケーションのうちのどのシステムアプリケーションが実行されるかを優先順位付けするシステムアプリケーションマネージャを実行するための実行可能コードをさらに含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
23. 前記システムアプリケーションはネットワーク能力を提供することを特徴とする請求項１８に記載のマルチメディアコンソール。
24. 前記第２メモリは、複数のシステムアプリケーションのうちのどのシステムアプリケーションが実行されるかを優先順位付けするシステムアプリケーションマネージャを実行し、また前記複数のシステムアプリケーションの各システムアプリケーションが、前記グラフィック処理装置によって生成される所定数のフレームごとに少なくとも１回実行されるようにスケジューリングさせるための実行可能コードをさらに含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
25. 前記所定量のハードウェアリソースを予約するステップは、少なくとも１つのオーディオチャネルを予約するステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
26. 前記所定量のハードウェアリソースを予約するステップは、少なくとも１０個のオーディオチャネルを予約するステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
27. 前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションを実行するために一部の中央処理装置時間を予約するステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
28. 前記第２メモリは、前記予約されたプロセッサ使用が前記システムアプリケーションによって使用されない場合は、アイドル状態のスレッドを含む前記システムアプリケーションを実行するために、前記一部の中央処理装置時間の間の未使用のプロセッササイクルを消費するための実行可能コードをさらに含むことを特徴とする請求項２７に記載のマルチメディアコンソール。
29. 前記第２メモリは、前記マルチメディアアプリケーションと前記システムアプリケーションの間の入力装置共有を実施する実行可能コードをさらに含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
30. 前記中央処理装置は第１および第２の処理装置を含み、前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションを実行するために前記第２中央処理装置の一部の処理時間を予約し、前記第１中央処理装置の一部の処理時間を予約せず、それによって前記第１中央処理装置は前記マルチメディアアプリケーションの実行専用になるステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
31. 前記中央処理装置は第１、第２および第３の中央処理装置を含み、前記所定量のハードウェアリソースを予約するステップは、前記システムアプリケーションを実行するために前記第２および第３中央処理装置の一部の処理時間を予約し、前記第１中央処理装置の一部の処理時間を予約せず、それによって前記第１中央処理装置は前記マルチメディアアプリケーションの実行専用になるステップを含むことを特徴とする請求項１８に記載のマルチメディアコンソール。
32. 前記第２中央処理装置の前記予約された一部の処理時間は、前記第３中央処理装置の前記予約された一部の処理時間と同じであることを特徴とする請求項３１に記載のマルチメディアコンソール。
33. 前記第２中央処理装置の前記予約された一部の処理時間は、前記第３中央処理装置の前記予約された一部の処理時間と異なることを特徴とする請求項３１に記載のマルチメディアコンソール。
34. 前記第２中央処理装置は時間依存型システムアプリケーションを実行し、前記第３中央処理装置は、非時間依存システムアプリケーションを実行することを特徴とする請求項３１に記載のマルチメディアコンソール。

Images