I've been tasked with building a real time "full screen" demo to run on a 5x2 array of 60+ inch LED TVs: or, in other words, a 20 megapixel display.
We've got a machine built that can run a single Win7 desktop spread across the displays at full resolution, and some pretty decent video cards.
My question is: aside from the ridiculous amount of work that my pixel shaders are going to be doing, are there any other limitations of DX10.* that would come into play here that wouldn't on a more sanely sized viewport? I won't have access to the hardware until next week but I'd like to have something written by then that I can use to benchmark the system.
While Imanaged to get this working on a single machine with a bunch of AMD EyeFinity (6 output) cards - to keep things working smoothly, the "easiest" way turned out to be to create a DX window per display as having a window span displays caused some performance issues - I also got it working pretty well by distributing the task across a group of machines, each of which drives two displays.
It was surprisingly easy. For my test XNA app, I added a GameComponent that captures some game state (camera position/orientation, etc.) and UDP-spams it across the local subnet per frame.
That component has a
Mode switch (send or receive). If it's in
Receive mode, it catches UDP datagrams and updates the game state with the information from the sender.
Send mode just sends state packets, and, via a service/daemon, causes nodes to start or stop the client app. Any client can act as a "master", and switching a client into
Send mode requests all other nodes to switch into
Receive. It's pretty entertaining to see what happens when people are fighting over control.
Another neat benefit: I created a console app which processes a series of keyframe state definitions - location, time, etc. - interpolates as needed, and sends them using the same code as is used in the game engine. This lets me easily script movement, submit transforms from a web browser, etc.
All in all, it took about 50 lines of code to keep multiple copies of the app running in sync. Some additional complexity came from off-setting the camera position for each machine and correcting some perspective/projection annoyances, but most of that came down to a per-node configuration file.