私は、リアルタイムの「フルスクリーン」デモを作成して、5インチx 2インチの60インチ以上のLEDテレビ、つまり20メガピクセルのディスプレイで実行するという任務を負っています。
フル解像度でディスプレイ全体に広がる単一のWin7デスクトップを実行できるマシンと、かなりまともなビデオカードがあります。
私の質問は、ピクセルシェーダーが行うことになる途方もない量の作業とは別に、より適切なサイズのビューポートではない、DX10。*のその他の制限事項がありますか？来週までハードウェアにアクセスすることはできませんが、それまでにシステムのベンチマークに使用できる何かを書きたいと思っています。
更新
AMD EyeFinity（6出力）カードを束ねた1台のマシンでこれを機能させることができました-物事をスムーズに機能させるために、「最も簡単な」方法は、ウィンドウスパンディスプレイを持つディスプレイごとにDXウィンドウを作成することでしたいくつかのパフォーマンスの問題を引き起こしました-また、それぞれが2つのディスプレイを駆動するマシンのグループにタスクを分散させることで、かなりうまく機能しました。
驚くほど簡単でした。テストXNAアプリの場合、ゲームの状態（カメラの位置/方向など）をキャプチャするGameComponentを追加し、フレームごとにローカルサブネット全体でUDPスパムします。
そのコンポーネントにはModeスイッチ（送信または受信）があります。Receiveモードにある場合、UDPデータグラムをキャッチし、送信者からの情報でゲームの状態を更新します。Sendモードは状態パケットを送信するだけで、サービス/デーモンを介して、ノードがクライアントアプリを起動または停止します。どのクライアントも「マスター」として動作でき、クライアントをSendモードに切り替えると、他のすべてのノードにに切り替えるように要求しますReceive。人々がコントロールをめぐって戦っているときに何が起こるかを見るのはとても楽しいです。
別のすばらしい利点：必要に応じて一連のキーフレーム状態定義（場所、時間など）を処理し、ゲームエンジンで使用されているのと同じコードを使用して送信するコンソールアプリを作成しました。これにより、移動のスクリプトを簡単に作成したり、Webブラウザから変換を送信したりできます。
全体として、アプリの複数のコピーを同期して実行するには、約50行のコードが必要でした。いくつかの追加の複雑さは、各マシンのカメラ位置をオフセットし、いくつかの遠近感/投影の煩わしさを修正することから生じましたが、そのほとんどはノードごとの構成ファイルに帰着しました。