Games are often CPU limited these days: updating game state from one frame to the next is one of the hard problems of modern game development. I don't think spl

Games are often CPU limited these days: updating game state from one frame to the next is one of the hard problems of modern game development. I don't think splitting the work between two consoles connected by such a slow link would work very well. The other hard problem is building the instruction chain (the term is escaping me at the moment) which gets sent to the GPU. This would have to be duplicated on each system. The most workable solution would be to have one system do nothing but update game state and send it to the other system, which just does rendering. Limit yourself as much as possible to one way communication. Hopefully the game state system would do a lot of GPU compute for physics etc, otherwise its GPU would be idle. Furthermore, there are a lot of single threaded bottlenecks in both game state and render, so you'd lose out in parallelism. (Many modern systems fix this problem by rendering frame N (which is read only on state N) while simultaneously computing game state for frame N+1. (which is also read only on state N) Since both operations are read only, their single thread bottlenecks are different single thread bottlenecks, which helps parallelism dramatically.) Overall you'd be getting a very minor boost in performance from doubling the hardware commitment; certainly no better than 50%, but I'd ballpark probably closer to 25%. It's an interesting idea, but one which is ultimately destroyed by the unrelenting iron fist of Amdahl's Law.