Coding for a really, really high-resolution display array

Question

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.

Update

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.

Answer 1

I would worry just as much about the hardware configuration as software. You don't have to run each TV at its native resolution, and screen size is different from resolution. I'll assume the 60" TVs are each 1920x1080 though, so native resolution across all of them is either 9600x2160 if you meant 5 rows x 2 columns of TVs, or 3840x5400 if you meant 5 columns x 2 rows.

The newest AMD Radeon card, a 7970 supports a resolution of up to 4096x2160 per display, at a maximum of two displays, if you're using DisplayPort 1.2 to transfer video. So it may get you close to native resolution, however it won't work with up to 5 TVs that way.

The AMD Radeon 6870 Eyefinity 6 supports up to 6 outputs at once, but only over a max resolution of 5760x2160. It also supports a Crossfire configuration which will help your performance quite a bit. Bear in mind the extra GPUs will not yield a greater max resolution.

Short of a completely custom display setup, or something to split your video signal to more monitors/TV, I'm not sure how you will be able to run on 10 displays at once. But if you have that capability, then what you're looking for is the fastest graphics setup that supports a resolution closest to what your native resolution is. Once you have that your best bet is just to keep your pixel shaders as cheap as possible, and avoid overdraw, which means calculating single pixels more than once. Frustum and occlusion culling, and depth sorting will help greatly in reducing overdraw. As far as a limit within DX10, I'm not sure of one that limits resolution, I'm sure there is one, but it's probably greater than any DX10 card that exists.

Answer 2

You can easily create a render target of equivalent size to test performance. You'll have to downscale it or zoom in when copying it to the back buffer until you get the real hardware.