J'ai été chargé de créer une démo "plein écran" en temps réel à exécuter sur une gamme 5x2 de téléviseurs LED 60+ pouces: ou, en d'autres termes, un écran de 20 mégapixels.
Nous avons construit une machine qui peut exécuter un seul bureau Win7 réparti sur les écrans en pleine résolution, et quelques cartes vidéo assez décentes.
Ma question est: à part la quantité ridicule de travail que mes pixel shaders vont faire, y a-t-il d'autres limitations de DX10. * Qui entreraient en jeu ici qui ne le seraient pas sur une fenêtre plus saine? Je n'aurai pas accès au matériel avant la semaine prochaine, mais j'aimerais avoir écrit quelque chose d'ici là que je puisse utiliser pour comparer le système.
Mise à jour
Bien qu'Imanaged ait réussi à le faire fonctionner sur une seule machine avec un tas de cartes AMD EyeFinity (6 sorties) - pour que les choses fonctionnent bien, la manière la plus "simple" s'est avérée être de créer une fenêtre DX par écran comme ayant une fenêtre s'étalant causé des problèmes de performances - je l'ai également fait fonctionner assez bien en répartissant la tâche sur un groupe de machines, chacune pilotant deux écrans.
C'était étonnamment facile. Pour mon application XNA de test, j'ai ajouté un GameComponent qui capture certains états de jeu (position / orientation de la caméra, etc.) et les spams UDP sur le sous-réseau local par image.
Ce composant possède un Mode
commutateur (envoyer ou recevoir). S'il est en Receive
mode, il attrape les datagrammes UDP et met à jour l'état du jeu avec les informations de l'expéditeur. Send
le mode envoie simplement des paquets d'état et, via un service / démon, oblige les nœuds à démarrer ou arrêter l'application cliente. Tout client peut agir en tant que «maître» et le basculement d'un client en Send
mode demande à tous les autres nœuds de basculer Receive
. C'est assez amusant de voir ce qui se passe quand les gens se disputent le contrôle.
Un autre avantage intéressant: j'ai créé une application console qui traite une série de définitions d'état des images clés - emplacement, heure, etc. - interpole selon les besoins et les envoie en utilisant le même code que celui utilisé dans le moteur de jeu. Cela me permet de déplacer facilement des scripts, de soumettre des transformations à partir d'un navigateur Web, etc.
Dans l'ensemble, il a fallu environ 50 lignes de code pour que plusieurs copies de l'application soient synchronisées. Une certaine complexité supplémentaire provenait du décalage de la position de la caméra pour chaque machine et de la correction de certains désagréments de perspective / projection, mais la plupart de ces problèmes se résumaient à un fichier de configuration par nœud.