Ich wurde beauftragt, eine Echtzeit-Vollbild-Demo zu erstellen, die auf einem 5x2-Array von 60+ Zoll-LED-Fernsehern oder mit anderen Worten auf einem 20-Megapixel-Display ausgeführt werden kann.
Wir haben eine Maschine gebaut, die einen einzelnen Win7-Desktop mit voller Auflösung über die Displays verteilen kann, und einige ziemlich anständige Grafikkarten.
Meine Frage ist: Abgesehen von der lächerlichen Menge an Arbeit, die meine Pixel-Shader leisten werden, gibt es noch andere Einschränkungen von DX10. Ich werde bis nächste Woche keinen Zugriff auf die Hardware haben, möchte aber bis dahin etwas schreiben, mit dem ich das System vergleichen kann.
Aktualisieren
Während es sich herausstellte, dies auf einem einzelnen Computer mit einer Reihe von AMD EyeFinity-Karten (mit 6 Ausgängen) zum Laufen zu bringen, stellte sich heraus, dass die "einfachste" Möglichkeit darin bestand, ein DX-Fenster pro Anzeige mit einer Fensterbreite von Anzeigen zu erstellen Es hat einige Leistungsprobleme verursacht - ich habe es auch ziemlich gut zum Laufen gebracht, indem ich die Aufgabe auf eine Gruppe von Computern verteilt habe, von denen jeder zwei Bildschirme steuert.
Es war überraschend einfach. Für meine Test-XNA-App habe ich eine GameComponent hinzugefügt, die den Spielstatus (Kameraposition / -ausrichtung usw.) erfasst und über das lokale Subnetz pro Frame per UDP-Spam versendet.
Diese Komponente verfügt über einen Mode
Schalter (Senden oder Empfangen). Im Receive
Modus werden UDP-Datagramme abgerufen und der Spielstatus mit den Informationen des Absenders aktualisiert. Send
Der Modus sendet nur Statuspakete und bewirkt über einen Dienst / Daemon, dass Knoten die Client-App starten oder stoppen. Jeder Client kann als "Master" fungieren und das Umschalten eines Clients in den Send
Modus fordert alle anderen Knoten zum Umschalten auf Receive
. Es ist ziemlich unterhaltsam zu sehen, was passiert, wenn Menschen um die Kontrolle kämpfen.
Ein weiterer netter Vorteil: Ich habe eine Konsolen-App erstellt, die eine Reihe von Keyframe-Statusdefinitionen - Ort, Zeit usw. - nach Bedarf interpoliert und sie mit demselben Code sendet, der in der Game-Engine verwendet wird. Auf diese Weise kann ich einfach Skripte erstellen, Transformationen von einem Webbrowser aus übermitteln usw.
Insgesamt wurden etwa 50 Codezeilen benötigt, um mehrere Kopien der App synchron laufen zu lassen. Eine gewisse zusätzliche Komplexität ergab sich aus dem Versetzen der Kameraposition für jede Maschine und dem Korrigieren einiger Belästigungen durch Perspektive / Projektion. Der größte Teil davon stammte jedoch aus einer knotenbezogenen Konfigurationsdatei.