JP7266640B2 - アプリケーション移行のためのシステム及び方法 - Google Patents

Description

（関連出願の相互参照）
本願は、２０１５年１２月２日に出願された米国特許出願第１４／９５６，５１１号の利益を主張するものであり、この内容は、本明細書中に完全に記載されているように参照により援用される。

開示された実施形態は、概して、グラフィックスシステム及び方法に関し、特に、着脱可能（detachable）なグラフィックスシステム及び方法に関する。

着脱可能又は切替可能（switchable）なグラフィックスは、高性能な個別のグラフィックス処理装置（graphics processing unit：ＧＰＵ）のグラフィカル処理能力と、統合されたＧＰＵの電力効率との両方を利用する技術である。一般に、着脱可能なグラフィックスの技術では、３Ｄアプリケーションに必要な場合にのみ個別のＧＰＵを使用し、残りの時間には統合されたＧＰＵの機能が使用される。

しかしながら、アプリケーションの実行中に個別のＧＰＵをシステムに追加するには、新たに使用可能な個別のＧＰＵを利用するために、アプリケーションを再起動する必要がある。同様に、アプリケーションが個別のＧＰＵ上で実行されている間に個別のＧＰＵをシステムから取り外すには、個別のＧＰＵが取り外し可能になる前にアプリケーションを閉じる必要がある。さらに、現在のシステムでは、ＧＰＵを取り外すための明示的なユーザ対話が必要であり、システムに追加された新たなＧＰＵは、３Ｄアプリケーションが再開されるまで使用されないことになる（つまり、ユーザの知識と、アプリケーションの再起動と、が必要になる）。

ドッキング可能なデバイスとドッキングステーションとの間でアプリケーションの移行をシームレスに行う方法及び装置について記載されている。ドッキング可能なデバイスはプロセッサを含み、ドッキングステーションは高性能なプロセッサを含む。この方法は、少なくとも１つのアプリケーションが動作している間に、ドッキング可能なデバイスのドッキング状態を判別することを含む。ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行は、ドッキング可能なデバイスがドッキング状態に移行しているときに開始される。ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行は、ドッキング可能なデバイスがドッキング解除状態に移行しているときに開始される。アプリケーションは、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行中、又は、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行中に実行され続ける。

添付の図面と併せて例として与えられる以下の説明から、より詳細な理解が得られるであろう。

１つ以上の開示された実施形態を実装することができる例示的なデバイスのブロック図である。 特定の実施形態による、ドッキング可能なデバイス及びドッキングステーションの例示的なブロック図である。 特定の実施形態による、アプリケーションの移行の例示的なハイレベルフローチャートである。

着脱可能なグラフィックスシステムは、多数の方法で実装することができる。例えば、個別のグラフィックス処理ユニット（discrete graphics processing unit：ｄＧＰＵ）を含むドッキングステーションとドッキングすることができるドッキング可能なデバイス（例えば、タブレット、ラップトップ、ノートブック及び他の同様なデバイス等）が利用可能であり、又は、利用可能になる。概して、ドッキング可能なデバイスがドッキングされると、アプリケーションは、着脱可能なグラフィックスプロファイル（例えば、ＡＭＤのＰｏｗｅｒＸｐｒｅｓｓ（ＰＸ）プロファイル等）で指定されている場合に、ｄＧＰＵで実行することができる。ＰＸプロファイルについて言及しているが、他の着脱可能なグラフィックスプロファイルソリューション又は実装も、同様に適用可能である。ｄＧＰＵで実行されているアプリケーションは、ドッキング可能なデバイスがドッキングステーションからドッキング解除されている場合に、統合されたＧＰＵ又は高速処理ユニット（accelerated processing unit：ＡＰＵ）に移行される。アプリケーションは、ドッキング可能なデバイスがドッキングステーションと再度ドッキングすると、ｄＧＰＵに戻される。移行処理が完了する前のドッキング解除を防ぐために、メカニカルロックが使用される。カーネルモードドライバ（kernel mode driver：ＫＭＤ）は、ｄＧＰＵにおいてＤｉｒｅｃｔＸデバイスが生成されていない場合に、ロックの解除を可能にする。本明細書ではＤｉｒｅｃｔＸについて言及しているが、現実的な３次元（three-dimensional：３Ｄ）グラフィックスと、没入感のある音楽及び音響効果とを提供するプログラムを可能にする、ディスプレイやオーディオカードの性能にアクセス可能な他のアプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）も、同様に適用可能である。

ＰＸマルチＧＰＵソリューションでは、３Ｄアプリケーションは、節電するために統合されたＧＰＵ、又は、追加のパフォーマンスを実現する高性能なＧＰＵの何れかで動作する。この判断は、アプリケーションのロード時に行われるため、アプリケーションがロードされると、当該アプリケーションが常に同じＧＰＵで動作する。アプリケーションの移行により、アプリケーションの実行中に３Ｄアプリケーションを（アプリケーションを再ロードすることなく）ＧＰＵ間で移行することができる。これにより、現在実行中の３Ｄアプリケーション及びユーザエクスペリエンスに影響を与えることなく、個別／高性能のＧＰＵをシステムに追加したり、システムから取り外したりすることができるシステムフォームファクタが可能になる。ドッキング状態とドッキング解除状態との間のシームレスな遷移は、他のＧＰＵ上の３Ｄアプリケーションの状態の再生成に必要な全てのデータの維持と、必要なデータの当該他のＧＰＵへの転送と、によって実現される。ＧＰＵを取り外すには、全ての状態情報をＧＰＵ上で破棄する必要があり、これにより、ＧＰＵを取り外してもよい（アプリケーションが以前のＧＰＵから新たなＧＰＵに完全に移行される）。

図１は、１つ以上の開示された実施形態を実装することができる例示的なデバイス１００のブロック図である。デバイス１００は、例えば、コンピュータ、ゲームデバイス、ハンドヘルドコンピュータ、セットトップボックス、テレビ、携帯電話又はタブレットコンピュータを含んでもよい。デバイス１００は、プロセッサ１０２と、メモリ１０４と、ストレージ１０６と、１つ以上の入力デバイス１０８と、１つ以上の出力デバイス１１０と、を含む。また、デバイス１００は、オプションとして、入力ドライバ１１２及び出力ドライバ１１４を含んでもよい。デバイス１００は、図１に示されていない追加のコンポーネントを含んでもよいことが理解されるであろう。

プロセッサ１０２は、中央処理装置（central processing unit：ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、同じダイ上に配置されたＣＰＵ及びＧＰＵ、又は、１つ以上のプロセッサコアを含んでもよく、各プロセッサコアは、ＣＰＵであってもよいしＧＰＵであってもよい。メモリ１０４は、プロセッサ１０２と同じダイ上に配置されてもよいし、プロセッサ１０２とは別に配置されてもよい。メモリ１０４は、例えば、ランダムアクセスメモリ（random access memory：ＲＡＭ）、ダイナミックＲＡＭ又はキャッシュ等の揮発性又は不揮発性メモリを含んでもよい。

ストレージ１０６は、例えば、ハードディスクドライブ、ソリッドステートドライブ、光ディスク又はフラッシュドライブ等の固定又は取り外し可能なストレージを含んでもよい。入力デバイス１０８は、キーボード、キーパッド、タッチスクリーン、タッチパッド、検出器、マイクロフォン、加速度計、ジャイロスコープ、バイオメトリックスキャナ、又は、ネットワーク接続（例えば、無線ＩＥＥＥ８０２信号の送信及び／又は受信のためのワイヤレスローカルエリアネットワークカード）を含んでもよい。出力デバイス１１０は、ディスプレイ、スピーカ、プリンタ、触覚フィードバックデバイス、１つ以上のライト、アンテナ、又は、ネットワーク接続（例えば、無線ＩＥＥＥ８０２信号の送信及び／又は受信のためのワイヤレスローカルエリアネットワークカード）を含んでもよい。

入力ドライバ１１２は、プロセッサ１０２及び入力デバイス１０８と通信し、プロセッサ１０２が入力デバイス１０８から入力を受信することを可能にする。出力ドライバ１１４は、プロセッサ１０２及び出力デバイス１１０と通信し、プロセッサ１０２が出力デバイス１１０に出力を送信することを可能にする。入力ドライバ１１２及び出力ドライバ１１４はオプションのコンポーネントであって、入力ドライバ１１２及び出力ドライバ１１４が存在しない場合には、デバイス１００が同じように動作することに留意されたい。

図２は、特定の実施形態による、ドッキング可能なデバイス２００及びドッキングステーション２５０の例示的なブロック図である。ドッキング可能なデバイス２００は、ユーザモードドライバ（user mode driver：ＵＭＤ）２０５と、カーネルモードドライバ（kernel mode driver：ＫＭＤ）２１０と、メモリ２１２と、統合されたＧＰＵ（integrated GPU：ｉＧＰＵ）２１５と、オペレーティングシステム（operating system：Ｏ／Ｓ）２２５を含むＣＰＵ２２０と、を含む。ｉＧＰＵ２１５及びＣＰＵ２２０として図示されているが、高速処理装置（accelerated processing unit：ＡＰＵ）が使用されてもよい。アプリケーション２３５は、ユーザによって起動されると、ドッキング可能なデバイス２００上で動作する。ドッキングステーション２５０は、ｄＧＰＵ２６５を含む。

概して、着脱可能なグラフィックスプロファイル内の設定及びドッキング可能なデバイス２００が最初にドッキングステーション２５０にドッキングされたときのドライバ構成に応じて、Ｏ／Ｓ２２５は、ｉＧＰＵ２１５及びｄＧＰＵ２６５を認識する。アプリケーション移行構成では、ｄＧＰＵ２６５に関してＯ／Ｓ２２５に見える２つの状態が存在する。ドッキング可能なデバイス２００がドッキングステーション２５０にドッキングされると、ｄＧＰＵ２６５は、「物理的」状態でＯ／Ｓ２２５に見える。ＵＭＤ２０５及びＫＭＤ２１０は、必要に応じてｄＧＰＵ２６５に仕事を提出する。ドッキング可能なデバイス２００がドッキングステーション２５０とドッキング解除されると、Ｏ／Ｓ２２５は、図２において仮想ｄＧＰＵ２６５’と示されている「仮想」ｄＧＰＵ２６５を見る。ＵＭＤ２０５及びＫＭＤ２１０は、仮想ｄＧＰＵ２６５’に提出された仕事がないことを保証する。ドッキング可能なデバイス２００及びドッキングステーション２５０は、図２に示されていない追加のコンポーネントを含み得ることが理解されるであろう。

初期構成の後、Ｏ／Ｓ２２５は、実行中、２つのＧＰＵ（すなわち、ｉＧＰＵ２１５と、ドッキング可能なデバイス２００がドッキングされたときのｄＧＰＵ２６５及びドッキング可能なデバイス２００がドッキング解除されたときの仮想ｄＧＰＵ２６５’の何れかと）を常に「見る」ことになる。つまり、ドッキング解除状態では、ｄＧＰＵ２６５は、Ｏ／Ｓ２２５に関して仮想モード（すなわち、論理エンティティであって、物理エンティティではない）にある。Ｏ／Ｓ２２５は、常に両方のＧＰＵを見ているので、アプリケーションの移行は、ｉＧＰＵ２１５とｄＧＰＵ２６５との間でシームレスである。仮想ｄＧＰＵ２６５’は、ドライバ及び他のそのような関連する仕様を含む能力に関してｄＧＰＵ２６５と同様に生成され、処理される。

図３は、本発明の実施形態による、アプリケーションの移行の例示的なハイレベルフローチャートである。ここでの説明は、図２も参照する。最初のイベントとして、ドッキング可能なデバイス２００は、最初のドッキング時に、ドッキング可能なデバイス２００がドッキングデバイス２５０とシームレスにドッキング／ドッキング解除するのを可能にするアプリケーション移行構成で構成される。Ｏ／Ｓ２２５はｄＧＰＵ２６５を認識し、着脱可能なグラフィックスプロファイルは、以下に説明するように、ドッキングイベントの検出時にドッキング可能なデバイス２００からドッキングステーション２５０へのアプリケーションの移行が完了し、ドッキング解除イベントの検出時にドッキングステーション２５０からドッキング可能なデバイス２００へのアプリケーションの移行が完了するように設定される。着脱可能なグラフィックスプロファイルは、最初にベンダーによってデフォルトのＧＰＵに設定され、ユーザは、例えば、アプリケーションの移行を実行するためにかかる設定を無効にすることができることに留意されたい。

アプリケーション２３５の起動後（３００）、ＫＭＤ２１０は、ドッキング可能なデバイス２００がドッキングステーション２５０にドッキングされているどうかを判別する（３０５）。ドッキング可能なデバイスがドッキングステーションにドッキングされている場合（３０７）、アプリケーション２３５はｄＧＰＵ２５０上で実行する（３０９）。ＫＭＤ２１０はドッキング状態を継続的に確認し、アプリケーション２３５は、ＫＭＤ２１０がドッキング可能なデバイス２００をドッキングステーション２５０からドッキング解除しようとする試みを検出するまで（３１３）、ｄＧＰＵ２５０上での実行を継続する（３１１）。ＫＭＤ２１０は、ドッキング可能なデバイス２００のドッキング解除要求を検出すると、ドッキング解除イベントについてＵＭＤ２０５に伝達又は通知し（３１５）、移行が完了するまでドッキング解除要求をロックする。ＵＭＤ２０５は、反応し、ＧＰＵ間の移行をトリガする。具体的には、ＵＭＤ２０５は、（本明細書で後述するように）アプリケーション２３５と、全ての他の必要な情報及びデータと、をドッキングステーション２５０内のｄＧＰＵ２６５からドッキング可能なデバイス２００内のｉＧＰＵ２１５に移行する。この移行を行う際、アプリケーション２３５の実行が中断されず、結果として移行がシームレスに行われる。ＫＭＤ２１０は、全ての移行が完了したことを検出すると、ドッキング可能なデバイス２００を物理的にドッキング解除できるように、ドッキング解除要求をアンロックする。次に、アプリケーションは、ｉＧＰＵ２１５上で実行しており（３１６）、ＵＭＤ２０５及びＫＭＤ２１０は、互いに通信して、ドッキング解除状態でｄＧＰＵ２６５に送信されるものが何もないが、ｉＧＰＵ２１５上で実行されるのを確実にする。また、ＵＭＤ２０５及びＫＭＤ２１０は、いくつかの動作を記録することができ、これらの動作は、ドッキング可能なデバイス２００がドッキングステーション２５０にドッキングされたときに、ドッキング可能なデバイス２００に伝搬され得る。

アプリケーションの移行が完了した後、ドッキング可能なデバイス２００がドッキングされていない場合（３０８）、ＫＭＤ２１０は、ドッキング状態を継続的に確認し、アプリケーション２３５は、ドッキング可能なデバイス２００がドッキングステーション２５０にドッキングされたことをＫＭＤ２１０が判別するまで（３１９）、ｉＧＰＵ２１５上での実行を継続する（３１７）。ドッキング可能なデバイス２００がドッキングされた場合、ＫＭＤ２１０は、ドッキングイベントについてＵＭＤ２０５に伝達又は通知する（３２１）。ＵＭＤ２０５は、反応し、ＧＰＵ間の移行をトリガする。具体的には、ＵＭＤ２０５は、アプリケーション２３５と、全ての他の必要な情報及びデータと、をドッキング可能なデバイス２００内のｉＧＰＵ２１５からドッキングステーション２５０内のｄＧＰＵ２６５に移行又はプッシュする。概して、アプリケーションの移行には、少なくとも、グラフィックスアダプタを開くことと、ＤＸデバイスをｄＧＰＵ２６５に生成することと、適切な状態及びデータ情報をｄＧＰＵパイプラインに提供することと、コンテキスト及び環境をｄＧＰＵ２６５にコピーすることと、が必要であり、これにより、アプリケーション２３５は、あらゆることが一様にわかる。つまり、アプリケーションの移行は、アプリケーション２３５に対して透過的である。上述したように、アプリケーション２３５の実行が中断されず、結果として移行がシームレスに行われる。

本明細書では、移行アプリケーションを実装するための例示的な実施形態を説明する。本明細書で述べるように、着脱可能なグラフィックスプロファイルが、アプリケーションが着脱可能なグラフィックス構成でｄＧＰＵ上で動作すべきであることを示す場合には、ＵＭＤは、いくつかの変更を必要とする。例えば、ドッキング又はドッキング解除イベントが要求されたという通知をＫＭＤから待つ追加のスレッドが生成される。つまり、アプリケーションの移行が有効になっている場合、ＵＭＤは、ドッキング又はドッキング解除イベントについてのＫＭＤの通知を確認するために、余分なスレッドを生成する。余分なスレッドによって通知が検出されると、余分なスレッドは、残りのＵＭＤ（アプリケーションの移行が有効であるか否かにかかわらず存在する部分）に対して移行を行うように通知する。全てのリソース、シェーダ、ビュー等は、ドッキング又はドッキング解除されたかどうかにかかわらずｉＧＰＵ（又はＡＰＵ）において生成され、ドッキングされた場合にはｄＧＰＵにおいて生成される。ドッキング時にｄＧＰＵが利用可能である場合、ｄＧＰＵ上のリソース、シェーダ、ビュー等を生成するのに必要な全ての情報は、例えばメモリ２１２に格納され、記憶される。この情報は、全てのリソース、シェーダ、ビュー等のリストとして保持することができる。アプリケーションからの全てのデータロードは、ｉＧＰＵ（又はＡＰＵ）と、ｄＧＰＵ（現在ドッキングされている場合）と、に送信される。これは、ドッキング解除時に転送する必要のあるデータの量を最小限に抑えるために行われる。上記の情報は、メモリ２１２を使用してＵＭＤに記憶することができる。

時間及びイベントシーケンスのために図２及び図３を参照すると、ドッキング解除が要求されたこと（例えば、図３の（３１３）を参照）を追加のスレッドが検出すると、ＫＭＤ（例えば、ＫＭＤ２１０）は、ドッキング解除イベントについての通知をＵＭＤ（例えば、ＵＭＤ２０５）に発行する。具体的には、ＫＭＤは、ｉＧＰＵ（又はＡＰＵ）（例えば、ｉＧＰＵ２１５）に移行するようにＵＭＤに通知するコマンドを発行する。ＵＭＤは、ドッキング解除イベントを検出すると、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）ランタイムプログラムからＵＭＤへのより多くのデバイスドライバインタフェース（device driver interface：ＤＤＩ）コールを防止するためにクリティカルセクションをロックし、ｉＧＰＵに移行し、次いで、クリティカルセクションを解除する。

ｄＧＰＵ（例えば、ｄＧＰＵ２６５）からｉＧＰＵ（又はＡＰＵ）に移行するために、リソース、シェーダ、ビュー等のリストがそれに従ってレビューされ、識別される（例えば、図３の（３１５）を参照）。ＵＭＤは、アプリケーションがｄＧＰＵ上で実行しているときに、何れのＧＰＵにリソースの最新のコンテンツがあるのかを追跡する。ｉＧＰＵへの移行時に（例えば、図３の（３１５～３１６）を参照）、最新のコンテンツがｄＧＰＵ上にのみ存在するリソースの場合、ＵＭＤは、それらのコンテンツをｄＧＰＵからｉＧＰＵ（又はＡＰＵ）に転送する。リソース、シェーダ、ビュー等のｄＧＰＵコピーは、ｄＧＰＵのスケジューリングコンテキストとともに破棄される。ＫＭＤが、ｄＧＰＵ上にリソース又はスケジューリングコンテキストが存在しないことを確認すると、ドッキング解除を許可する。ｉＧＰＵ（又はＡＰＵ）への移行が完了すると、ＵＭＤ状態は、アプリケーションがドッキング解除状態で開始された場合と同じ状態になる。本明細書で説明するように、ＫＭＤは、ＵＭＤがｄＧＰＵからアダプタ情報等をクエリすることができるように、ドッキング解除された場合であっても仮想又は疑似のｄＧＰＵを維持する。

ドッキングが要求されたことを追加のスレッドが検出すると（例えば、図３の（３１９）を参照）、ＫＭＤは、ｄＧＰＵへの移行をＵＭＤに通知するコマンドを発行する。ｄＧＰＵに移行するために、スケジューリングコンテキストがｄＧＰＵ上に生成される。リソース、シェーダ、ビュー等のレビューと、識別とが行われる。ｄＧＰＵにおいて、リソースが生成され、シェーダがコンパイルされ、ビュー等が生成される。リソースのコンテンツは、ｄＧＰＵに移行しているときには転送されない。ＵＭＤは、リソースを、次に使用するときに必要に応じてｄＧＰＵに転送する。

本明細書には、構成決定のための方法が記載されている（例えば、図３を参照）。概して、アプリケーションの起動及びアダプタのオープン要求時に、ＵＭＤは、システム又はプラットフォームが着脱可能なグラフィックス構成をサポートしているかどうか（ＫＭＤがシステム構成情報を認識しているかどうか）についてＫＭＤにクエリを送信する。着脱可能なグラフィックス構成がサポートされている場合、アプリケーションの移行が有効になる。一実施形態では、アプリケーションの移行がサポートされている場合、キャパビリティフラグ（capability flag）を設定することができる。

別の実施形態では、アプリケーションが、アプリケーションの移行を必要とするか否かに応じて、要件フラグが設定される。要件フラグがアプリケーションの移行を要求するように設定され、キャパビリティフラグがサポート無しを示すように設定されている場合には、ＵＭＤは、キャパビリティフラグを考慮して要件フラグを上書きし、アプリケーションは、ｉＧＰＵ（又はＡＰＵ）上で実行する。

本明細書で述べるように、ＫＭＤは、初期状態がドッキング又はドッキング解除であるかどうかを判別するためにＵＭＤによってクエリされ、ＧＰＵを適切に通過するように設定する。潜在的な競合状態は、初期状態についてのクエリが送信されてからｄＧＰＵにＧＰＵデバイスを生成するまでの間にシステムがドッキング解除し得ることから、ドッキング解除を防止するために存在する。デバイス初期化コードは、ｄＧＰＵ上でＧＰＵデバイスを生成し、ｉＧＰＵ（又はＡＰＵ）上で実行するように切り替えるときの障害をハンドリングする。

本明細書では、ドライバ性能を決定するための実装を説明する。アプリケーションの移行がサポートされると、ＵＭＤは、ｉＧＰＵ（又はＡＰＵ）とｄＧＰＵとの共通の機能を報告する。グラフィックスＡＰＩの場合、アプリケーションが起動したときに発生する最初のイベントの１つは、ＤＸランタイムプログラム又は同等のものが、ＧＰＵの機能（この場合、アプリケーションが両方のＧＰＵで実行可能でなくてはならないので、ｉＧＰＵ（又はＡＰＵ）及びｄＧＰＵの機能）についてＵＭＤにクエリすることである。したがって、共通の機能が報告又は決定される。この機能のクエリは、ソフトウェア及びハードウェアの機能に関する情報を要求する。

本明細書では、クリティカルセクションを保護する方法が記載されている。この方法では、アプリケーションがフリースレッドを必要とするか否かにかかわらず、ＤｉｒｅｃｔＸ１１（ＤＸ１１）フリースレッドエントリポイント（free threading entry point）が使用される。これが必要なのは、移行通知を待っているスレッドとの安全な対話を可能にするために、エントリポイントをクリティカルセクションを用いて保護する必要があるためである。つまり、アプリケーションの移行が進行中である場合又は実行される予定の場合には、クリティカルセクションの保護が実施される（例えば、図３の（３１３及び３１９）を参照）。

概して、ＤＸ１１は、様々なスレッドを介してＵＭＤをコールすることができる。上記のように、ＵＭＤは、ＫＭＤからのドッキング及びドッキング解除信号を監視するための追加のスレッドを生成する。ＵＭＤは、その信号に応じて特定の動作を実行し、結果として、ＵＭＤ内部状態を変更する可能性がある。したがって、監視スレッドが、アプリケーション用に実行されているスレッドとの競合に起因して、監視スレッドが改ざんされたり破損したりしないようにする必要がある。一実施形態では、同期オブジェクトを使用することができる。クリティカルセクションオブジェクトは、単一のプロセスのスレッドのみが使用可能な同期を提供する。クリティカルセクションオブジェクトは、一度に１つのスレッドのみが所有することができ、このことは、共有リソースに対する同時アクセスから保護するのに便利である。

本明細書では、アプリケーションの移行をトリガするためのエントリポイントについて記載されている（例えば、図３の（３１３及び３１９）を参照）。移行をトリガするための新たなエントリポイントは、移行をハンドリングするためにＵＭＤに追加され、当業者に知られているＤＤＩハンドリングの標準フローに従う。新たなエントリポイントは、ＫＭＤからの移行通知を待機しているスレッドのみによってコールされる。つまり、ＫＭＤがＵＭＤを検出して通知すると、新たなエントリポイントがコールされる。ＵＭＤがＧＰＵ間で移行するための通知を検出すると、ＵＭＤは、１）他のＤＤＩコールが保留になるようにクリティカルセクションをロックし、２）移行を実行し、３）クリティカルセクションを解除する。具体的には、ＵＭＤ状態がアプリケーションの移行処理中に変化するため、ＵＭＤへの全てのコールは、当該処理が完了するまで待機する必要がある。ＵＭＤは、コンテキスト及びリソースを転送して、以前のＧＰＵのコンテキストを破棄する。以前のＧＰＵのコンテキストが破棄されたことをＫＭＤが認識すると（例えば、ＵＭＤからの通知を介して）、ＫＭＤは、以前のＧＰＵを切り離すことを許可する。

ＤＤＩコールをハンドリングする性能を最適化するためにＵＭＤがスレッド技術（例えば、プロデューサ－コンシューマモデル）を使用する場合、移行コールは、他のＤＤＩコールのロック時間を短縮するために、コンシューマスレッドにバッチすることができる。かかる場合には、バッチされた移行動作は、移行処理を開始する際の遅延を最小限に抑えるために、移行エントリポイント機能から戻る前にコンシューマスレッドにフラッシュされる必要がある。

ここでは、アプリケーションの移行に関してフリースレッドを処理する方法について説明する。ＤＸ１１では、フリースレッドは、他のスレッドが実行するのを待つ必要がない。フリースレッドは、動作する前に別のスレッドの既存の作業を停止する必要がない。つまり、複数のスレッドが同時に同じ機能をコールすることができる。このことは、アプリケーションの移行に関して問題がある。

ＤＸ１１フリースレッドは、アプリケーションのメインレンダリングスレッド以外のスレッドによって生成されたＤＤＩコールを可能にする。生成されたＤＤＩコールがメインレンダリングスレッド（エントリポイントマルチスレッドのスレッド）とは完全に独立して動作する場合、現在のドッキング状態又はドッキング解除状態を認識せず、ｄＧＰＵ上でリソースを生成するかどうかもわからない。

本明細書では、上記に対処するための２つの例示的な方法を説明する。例示的な方法では、ＵＭＤは、ＤＤＩコールの生成中に、ｉＧＰＵ（又はＡＰＵ）上にのみオブジェクトを生成する。次いで、ＵＭＤは、オブジェクトがメインスレッドによってｄＧＰＵ上に必要とされるときに、要求に応じて、ｄＧＰＵ上にオブジェクトを生成する。この方法では、ＤＤＩコールの生成を同期無しに実行することができるが、ｉＧＰＵ（又はＡＰＵ）からｄＧＰＵへの移行中にｄＧＰＵ上でオブジェクトを再生成する実装に依存している。

別の方法では、同期が使用される。ＤＤＩコールの生成は、ＤＤＩクリティカルセクションを所有する。これにより、移行コマンドを含む他のＤＤＩコールが、生成中に発生しないようになる。また、エントリポイントマルチスレッドを使用可能にすると、ＤＤＩコールの生成は、バッチされた最後の移行コマンドが完了するまで待機する必要がある。このメカニズムによって、ＤＤＩコールが他のスレッドによって同時に行われるのを抑制することができる。しかしながら、移行中（稀なイベント）を除いて、コンシューマスレッドは、ＤＤＩコールの生成中に中断することなく処理を継続することができる。

ここでは、アプリケーション移行検出スレッドについて説明する。これは、ＫＭＤ信号を監視するために生成された上記のスレッドであり、ＵＭＤは、アプリケーションの移行を検出するためのスレッドを生成する。このスレッドは、ドッキング状態の初期クエリを実行し、必要に応じて初期状態に基づいて移行し、ドッキング又はドッキング解除イベントを待機するループに入り、イベントが発生したときに移行する。例示的なフローチャートは、図３に関して上述されている。

アプリケーション移行検出スレッドの例示的な論理が表１に記載されている。ｉＧＰＵ及びｄＧＰＵの関係の初期状態が得られる。状態によってＧＰＵがドッキングされていることが示された場合、ｉＧＰＵからｄＧＰＵへの移行が実施される。次に、システムは、ドッキング解除イベント又は終了イベントを待機する。メインスレッドは、「終了」イベントを使用して、アプリケーション移行スレッドに対して終了を通知する。コンテキスト及びデバイスの破棄の開始時に、終了イベントが通知され、次にアプリケーション移行検出スレッドが解放される。状態によってＧＰＵがドッキング解除されていることが示された場合、ｄＧＰＵからｉＧＰＵへの移行が実施され、次に、システムは、ドッキングイベント又は終了イベントを待機する。

ここでは、ドッキング可能なデバイスがドッキング又はドッキング解除されているのかどうかに応じて、リソース、シェーダ、ビュー等をｉＧＰＵ（又はＡＰＵ）上に生成する方法の例示的な実施形態を説明する。ｄＧＰＵからｉＧＰＵ（又はＡＰＵ）に移行する際の移行時間を最小限に抑えるために、全てのリソース、シェーダ、ビュー等が、ドッキング又はドッキング解除されたかどうかにかかわらず、ｉＧＰＵ（又はＡＰＵ）に生成される。

ここでは、静的データをどのようにハンドリングするかについて説明する。例示的な実施形態では、ドッキング可能なデバイスがドッキングされると、移行時間を最小限に抑えるために、ブロードキャストメカニズムを用いて静的データをアップロードする。具体的には、ｄＧＰＵからｉＧＰＵ（又はＡＰＵ）に移行する際の移行時間を最小限に抑えるために、レンダリングＧＰＵ（すなわち、アクティブなＧＰＵ）に加えて、静的データのアップロードが常にｉＧＰＵ（又はＡＰＵ）に送信される。

ここでは、リソース、シェーダ、ビュー等のリストをどのように維持するかについての例示的な実施形態を説明する。ＵＭＤは、オブジェクト、リソース及び他の関連情報を追跡する。すなわち、ＵＭＤは、Ｃｒｅａｔｅｓ ａｎｄ Ｄｅｓｔｒｏｙを追跡する。リソースは独自のリストに残り、他の全てのオブジェクトタイプを保持する別のリストが生成される。ＵＭＤは、この追跡を行い、これにより、本明細書で説明した競合状態を防ぐためにフリースレッドを正しくハンドリングできるようにする。

ここでは、ｄＧＰＵからｉＧＰＵ（又はＡＰＵ）への移行の例示的な実施形態を説明する。ＵＭＤがｉＧＰＵ（又はＡＰＵ）への移行を実行するようにトリガされ、パススルーＧＰＵが現在ＧＰＵ０（すなわち、ｉＧＰＵ）ではない場合、以下の方法が実行される。ＤＤＩ状態がウォークスルーされ、ｄＧＰＵ上の全てのリソース及びパイプライン状態オブジェクトがアンバインドされる。ｉＧＰＵ（又はＡＰＵ）に最新のコンテンツが無い場合、各リソースのリストがウォークスルーされ、各リソースのデータがｉＧＰＵ（又はＡＰＵ）に転送される。全てのリソースは、ｉＧＰＵ（又はＡＰＵ）でのみ有効とマークされ、ｄＧＰＵでのコピーが破棄される。

パイプライン状態オブジェクトのリストはウォークスルーされ、ｄＧＰＵ上のコピーは、破棄され、ｉＧＰＵ（又はＡＰＵ）上でのみ生成されたものとしてマークされる。ＵＭＤのレンダリングＧＰＵは、ｉＧＰＵ（又はＡＰＵ）に変更されるため、その後の動作は、ｉＧＰＵ（又はＡＰＵ）のみに送信される。ＧＰＵ１（ここではｄＧＰＵ）上のＵＭＤデバイスと、当該ＵＭＤデバイスに関連するコンテキスト及びオブジェクト（例えば、グラフィックススケジューラコンテキスト、内部メモリ割当て、同期オブジェクト等）とは破棄される。これは、アクティブなＧＰＵがｉＧＰＵ／ＡＰＵに変更され、ｄＧＰＵ上のＤＤＩデバイスが破棄されたことを示すために、内部ＵＭＤドライバ状態を更新する必要があるという事実を反映している。

ここでは、ｄＧＰＵ上のオブジェクトを再生成するために、どの情報を記憶する必要があるかについて説明する。ＵＭＤは、保存されているアイテム（すなわち、シェーダコードであるかオブジェクトであるか）を考慮して、どのようなデータを保存する必要があるのか、性質及びタイプを決定する。つまり、ドライバは、アプリケーションの移行のためのシェーダ及び他の構造を再生成するために、どれだけのデータ（例えば、メタデータ及びコード）を記憶する必要があるのかを決定することができる。例えば、シェーダオブジェクトの場合には、シェーダコードのサイズが含まれてもよい。メモリは、シェーダタイプ及びデバイスインタフェースに基づいて、シェーダコード、ＩＯシグネチャ等を含む全ての生成データに割り当てられる。状態オブジェクト（ブレンド状態、ラスタライザ状態、サンプラ状態、深度ステンシル状態及びＩａＬａｙｏｕｔ状態）は、シェーダと同様にハンドリングされる。ＵＭＤがこれらのオブジェクトを生成する場合、ＵＭＤは、オブジェクトに関連する生成データも記憶する。データは、データ構造又は他の記憶構造の形態で記憶され得る。記憶されたデータは、必要なときに取得される。

ここでは、アプリケーションの移行を考慮してクエリ動作を処理する方法を説明する。概して、クエリが、依然としてビルド中又は発行ステージにあり、終了しておらず、アプリケーションの移行が行われている場合には、ＵＭＤは、クエリステータスを追跡し、完全な結果又は部分的な結果がｄＧＰＵに利用可能であるのかどうかを判別する必要がある。例えば、ブーリアン又はフラグを使用して、部分的なクエリ結果が利用可能であるかどうかを示すことができる。部分的な結果が利用可能である場合には、当該部分的な結果が記憶される。場合によっては、部分的な結果が組み合わされる。例示的な実施形態を表２及び表３に示す。後者の表はＤｉｒｅｃｔ３ＤのＡＰＩの実装であるが、他のグラフィックスＡＰＩに合わせて変更することもできる。

ここでは、リソースのオファー及び再要求（reclaim）がどのようにハンドリングされるかについて説明する。概して、アプリケーション／プログラム及び／又はグラフィックスランタイムは、メモリ状態を追跡する。低メモリ状態の場合、ＵＭＤは、いくつかのアイドル状態のＡＰＩオブジェクトのメモリを解放することが要求される。これは、オファーと呼ばれる。次いで、ＵＭＤは、再使用のためにメモリを解放する。ＡＰＩオブジェクトが依然として存在することに留意されたい。以前にオファーされたＡＰＩオブジェクトが再度必要になると、メモリは、ＡＰＩオブジェクトに再度関連付けられる。これは、再要求と呼ばれる。発生する問題は、オファーと再要求との間でアプリケーションの移行が発生した場合に何が起こるかということである。一実施形態では、ＵＭＤは、オファーと、オファーを行うＧＰＵと、を追跡する。したがって、再要求が発生した場合、ＵＭＤは、オファーしたＧＰＵに基づいて再要求を行うことができる。

ここでは、ｉＧＰＵ（又はＡＰＵ）からｄＧＰＵへの移行について説明する。ＧＰＵデバイスはｄＧＰＵ上に生成される。リソース、シェーダ等のリストは、ｄＧＰＵ上で生成するためにウォークスルーされる。インスタンスは、ｉＧＰＵ（又はＡＰＵ）に保持され、ｉＧＰＵ（又はＡＰＵ）への潜在的な移行が可能になる。リソースのコンテンツは移行中に直ちにｄＧＰＵに伝搬されるわけではなく、ｄＧＰＵ上でリソースが必要になった場合に、伝搬がオンデマンドで行われることに留意されたい。レンダリングＧＰＵは、ｉＧＰＵ（又はＡＰＵ）からｄＧＰＵに変更され、パイプライン状態はリバインドされる（現在のパイプライン状態をｄＧＰＵに送信する）。クエリオブジェクトのハンドリングは、上記のｄＧＰＵからｉＧＰＵへの移行と同じである。重大な障害（例えば、メモリ不足等）が発生した場合、移行動作は元に戻され、アプリケーションはＡＰＵ／ｉＧＰＵ上で実行されたままになる。

本明細書で説明する実施形態を限定するものではないが、アプリケーションの移行方法は、少なくとも１つのアプリケーションが実行している間に、ドッキング可能なデバイスのドッキング状態を決定することと、ドッキング可能なデバイスがドッキング状態にあるという条件において、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行を開始することであって、ドッキング可能なデバイスがプロセッサを備え、ドッキングステーションが高性能プロセッサを備える、ことと、を含む。この方法は、ドッキング可能なデバイスがドッキング解除状態に移行しているという条件において、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行を開始することをさらに含み、アプリケーションは、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行中、又は、ドッキングステーションからドッキング可能デバイスへのアプリケーションの移行中に実行を継続する。

一実施形態では、この方法は、転送先プロセッサ上でアプリケーション状態を再生成するために必要な全てのデータを維持することを含み、プロセッサは、ドッキング状態にかかわらず、ドッキング解除するときのデータ転送を最小限に抑えるために、当該データを有する。一実施形態では、この方法は、転送元プロセッサ上の状態情報を破棄することを含む。一実施形態では、この方法は、ドッキング可能なデバイスがドッキング解除状態にあるという条件において、ドッキング可能なデバイス上に仮想高性能プロセッサを維持することを含む。

一実施形態では、ユーザモードドライバ及びカーネルモードドライバは、仮想高性能プロセッサに作業が送信されないことを確実にする。一実施形態では、この方法は、ユーザモードドライバを含み、カーネルモードは、ドッキング可能なデバイスがドッキングステーションにドッキングされた場合に、ドッキング可能なデバイスに伝搬されるいくつかの動作を記憶することを含む。

一実施形態では、この方法は、カーネルモードドライバがドッキングイベントを検出したという条件において、アプリケーションの移行を開始するために、カーネルモードドライバからユーザモードドライバに通知を送信することを含む。一実施形態では、ユーザモードドライバは、アプリケーションの移行中にクリティカルセクションをロックする。

一実施形態では、この方法は、ドッキング解除要求を検出することと、ドッキング解除要求をロックすることと、アプリケーションの移行が完了したという条件において、ドッキング可能なデバイスが物理的にドッキング解除できるようにドッキング解除要求をアンロックすることと、を含む。

一実施形態では、この方法は、ドッキングイベントを検出することと、検出されたドッキングイベントがドッキング可能なデバイスをドッキングすることであるという条件において、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行を開始することと、検出されたドッキングイベントがドッキング可能なデバイスをドッキング解除することであるという条件において、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行を開始することと、を含む。

概して、本明細書で説明する実施形態に限定することなく、ドッキング可能なデバイスは、プロセッサと、少なくとも１つのアプリケーションが動作している間に、ドッキング可能なデバイスのドッキング状態を決定するように構成されたカーネルモードドライバと、を備える。カーネルモードドライバは、ドッキング可能なデバイスがドッキング状態にあるという条件において、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行を開始するように構成されており、ドッキングステーションは、高性能プロセッサを備える。カーネルモードドライバは、ドッキング可能なデバイスがドッキング解除状態に移行しているという条件において、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行を開始するように構成されており、アプリケーションは、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行中、又は、ドッキングステーションからドッキングな可能デバイスへのアプリケーションに移行中に実行を継続する。

一実施形態では、ドッキング可能なデバイスは、ユーザモードドライバを含み、ユーザモードドライバ及びカーネルモードドライバは、転送先プロセッサ上でアプリケーション状態を再生成するために必要な全てのデータを維持するように構成されており、プロセッサは、ドッキング状態にかかわらず、ドッキング解除するときのデータ転送を最小限に抑えるために、当該データを有する。

一実施形態では、ユーザモードドライバは、転送元プロセッサ上の状態情報を破棄するように構成されている。

一実施形態では、ドッキング可能なデバイスは、ユーザモードドライバを含み、ユーザモードドライバ及びカーネルモードドライバは、ドッキング可能なデバイスがドッキング解除状態にあるという条件において、ドッキング可能なデバイス上に仮想高性能プロセッサを維持するように構成されている。一実施形態では、ユーザモードドライバ及びカーネルモードドライバは、仮想高性能プロセッサに作業が送信されないことを確実にするように構成されている。

一実施形態では、ユーザモードドライバ及びカーネルモードドライバは、ドッキング可能なデバイスがドッキングステーションにドッキングされた場合に、ドッキング可能なデバイスに伝搬されるいくつかの動作を記憶するように構成されている。

一実施形態では、カーネルモードドライバは、カーネルモードドライバがドッキングイベントを検出したという条件において、アプリケーションの移行を開始するためにユーザモードドライバに通知を送信するように構成されている。

一実施形態では、ドッキング可能なデバイスは、アプリケーションの移行中にクリティカルセクションをロックするように構成されたユーザモードドライバを含む。

一実施形態では、カーネルモードドライバは、ドッキング解除要求を検出するように構成されており、ドッキング解除要求をロックするように構成されており、アプリケーションの移行が完了したという条件において、ドッキング可能なデバイスが物理的にドッキング解除できるようにドッキング解除要求をロック解除するように構成されている。

概して、本明細書で説明する実施形態を限定することなく、コンピュータ可読記憶媒体は、処理システムにおいて実行されると、アプリケーションを移行する方法を処理システムに実行させる命令を含む。この方法は、少なくとも１つのアプリケーションが動作している間に、ドッキング可能なデバイスのドッキング状態を決定することと、ドッキング可能なデバイスがドッキング状態にあるという条件において、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行を開始することであって、ドッキング可能デバイスがプロセッサを備え、ドッキングステーションが高性能プロセッサを含む、ことと、ドッキング可能なデバイスがドッキング解除状態に移行しているという条件において、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行を開始することと、を含み、アプリケーションは、ドッキング可能なデバイスからドッキングステーションへのアプリケーションの移行中、又は、ドッキングステーションからドッキング可能なデバイスへのアプリケーションの移行中に実行を継続する。

本明細書の開示に基づいて多くの変形が可能であることを理解されたい。特徴及び要素は、特定の組み合せで上記に説明されているが、各特徴又は要素は、他の特徴及び要素無しに単独で、又は、他の特徴及び要素を含む若しくは含まない様々な組み合せで使用されてもよい。

提供される方法は、汎用コンピュータ、プロセッサ又はプロセッサコアで実施されてもよい。適切なプロセッサには、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、任意の他のタイプの集積回路（integrated circuit：ＩＣ）、及び／又は、状態マシン等が挙げられる。かかるプロセッサは、処理されたハードウェア記述言語（hardware description language：ＨＤＬ）命令（かかる命令は、コンピュータ可読媒体に記憶することができる）の結果と、ネットリストを含む他の中間データと、を使用して製造プロセスを構成することによって製造することができる。かかる処理の結果は、実施形態の態様を実装するプロセッサを製造するために半導体製造プロセスで使用されるマスクワークであってもよい。

本明細書で提供される方法又はフローチャートは、非一時的なコンピュータ可読記憶媒体に組み込まれ、汎用コンピュータ又はプロセッサによって実行されるコンピュータプログラム、ソフトウェア又はファームウェアで実装され得る。非一時的なコンピュータ可読記憶媒体の実装例としては、読み取り専用メモリ（read only memory：ＲＯＭ）、ランダムアクセスメモリ（random access memory：ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスク等の磁気媒体、光磁気媒体、並びに、ＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk：ＤＶＤ）等の光学媒体が挙げられる。

Claims (40)

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. 前記少なくとも１つのドライバは、前記ドッキング可能なデバイスがドッキング状態であるかドッキング解除状態であるかにかかわらず、前記少なくとも１つのアプリケーションに関連するアプリケーション状態を再生成するために必要なデータを維持することを指示するように構成されている、
    請求項３０のドッキング可能なデバイス。
35. 前記少なくとも１つのドライバは、前記ドッキング可能なデバイスがドッキング状態であると判別したことに応じて、前記アプリケーションの移行中に前記第２プロセッサに伝達される動作を記録するように構成されている、
    請求項３０のドッキング可能なデバイス。
36. 前記少なくとも１つのドライバは、
    ドッキングイベントを検出することと、
    前記第１プロセッサから前記第２プロセッサへのアプリケーションの移行を開始するための通知を送信することと、
    を行うように構成されている、
    請求項３０のドッキング可能なデバイス。
37. 前記少なくとも１つのドライバは、前記第２プロセッサから前記第１プロセッサへのアプリケーションの移行が完了した後に、前記ドッキング可能なデバイスが物理的にドッキング解除できるように、ドッキング解除要求を検出したことに応じて前記ドッキング可能なデバイスをロック解除するように構成されている、
    請求項３１のドッキング可能なデバイス。
38. 前記少なくとも１つのドライバは、
    ドッキングイベントを検出することと、
    前記ドッキングイベントが前記ドッキング可能なデバイスをドッキングすることであることを検出したことに応じて、前記第１プロセッサから前記第２プロセッサへのアプリケーションの移行を開始することと、
    前記ドッキングイベントが前記ドッキング可能なデバイスをドッキング解除することであることを検出したことに応じて、前記第２プロセッサから前記第１プロセッサへのアプリケーションの移行を開始することと、
    を行うように構成されている、
    請求項３０のドッキング可能なデバイス。
39. ドッキング可能なデバイスであって、
    少なくとも１つのアプリケーションを実行するように構成された第１プロセッサと、
    少なくとも１つのドライバと、を備え、
    前記少なくとも１つのドライバは、
    前記少なくとも１つのアプリケーションが実行されている間に、前記ドッキング可能なデバイスがドッキング状態であるかドッキング解除状態であるかを判別することと、
    前記ドッキング可能なデバイスがドッキング状態であると判別したことに応じて、前記第１プロセッサからドッキングステーションの第２プロセッサへの前記少なくとも１つのアプリケーションのアプリケーションの移行を開始することであって、前記少なくとも１つのアプリケーションは、前記第１プロセッサから前記第２プロセッサへのアプリケーションの移行の間、実行を継続する、ことと、
    前記ドッキング可能なデバイスがドッキング状態であるかドッキング解除状態であるかにかかわらず、前記少なくとも１つのアプリケーションに関連するアプリケーション状態を再生成するために必要なデータを維持することと、
    を行うように構成されている、
    ドッキング可能なデバイス。
40. 前記少なくとも１つのドライバは、前記ドッキング可能なデバイスがドッキング解除状態であると判別したことに応じて、前記第２プロセッサから前記第１プロセッサへの前記少なくとも１つのアプリケーションのアプリケーションの移行を開始することであって、前記少なくとも１つのアプリケーションは、前記第２プロセッサから前記第１プロセッサへのアプリケーションの移行の間、実行を継続する、ことを行うように構成されている、
    請求項３９のドッキング可能なデバイス。

Images