(12-15-2015, 01:35 AM)KHg8m3r Wrote: If you can find a way to code it so that math is faster, be our guest. If you can effectively push it to the GPU without it slowing down the GPU work already being done and getting a CPU boost out of it, even better.
I wish I was that good
I'm going to fork the code,we'll see what happens. 
KHg8m3r Wrote:Spreading the CPU load over a network is probably not a good idea. If you take our current dual core Dolphin setup, and try to split those threads over multiple LAN/WiFi computers/CPUs, you would get so much lag from waiting for the different threads to all sync up together.Not only that,it's even harder in that way.
But I had a different trick in mind.
The idea is to have both(or "n") machine(s) working on half(or 1/n ) the native resolution and to sync the results in one single frame to display.
It's some sort of "shared frame buffer" and the theory behind it is that (bare with me,it's an example,numbers are hypothetical) if we have two machines that can render 1M pixels at 10fps and 500K pixels at 20fps, if we sum our "job" together we effectively get 1M pixels at -+20/19fps(with the minimum lag possible,which is in the order of a few milliseconds on a LAN environment over miles;it's almost unnoticeable if the machines are within a meter).
It is not efficient space-wise because you need "n" copies of everything on the machines,unlike a general implementation of a parallel hypervisor,where the load is shared intelligently by passing messages through the switches; but with this trick in mind,if done right,you effectively multiply the fps by the number of machines(again,at the expense of space since a copy of all the software is needed on each machine).
