A question about your program. Will multi-processors immediately pick up the individual threads or do you have to tweak it a little to make sure that the each thread goes a separate processor.
Show some code too [smile]
Discussion about console multi-processor programming
Quote:Original post by hplus0603
The scary thing is that the memory busses don't keep up with the CPU speed increase. And now, there's two (or three, or four) CPUs, each of which is ravenously consuming memory bandwidth. And the frame buffer and textures share a unified memory controller with these CPUs.
The good thing is that modern CPUs have larger caches, so it's possible to write cache-local subsystems, so you can actually get some work out of each CPU. But I predict we'll see coarse-scale multi-threading, where each thread is tied (with affinity) to a specific CPU, and each thread has a specific job (physics, audio, rendering, etc).
isn't that why we have Rambus and DDR2 memory? maybe i'm getting my concepts confused, but i thought those were to take care of memory bus speeds.
Quote:Original post by superpig
_the_phantom_, yeah, I think the way to go on the input front is to use a buffering system, much like the one DirectInput provides. If you're not using DirectInput, you presumably run a seperate thread that records all input events (or just polls the hardware) recording things into a buffer. Next time the fixed timestep updater rolls around, it can just take the latest buffer and apply it to the system.
yeah, that would make sense as a way forward. Once I'd got my windowing stuff sorted I was considering looking into building a stand alone input library (something which is often brought up as lacking) and this system is certainly one to consider.
@Alpha_ProgDes
With an OS such as Windows when you start a thread it will automatically handle the details of when to run it and where. I belive generally it uses a load balancing system and tries to keep things spread evenly between the cpus, however you can ask it to keep one thread on one CPU (the affinity that hplus0603 was talking about) which depending on the task being carried out can improve performance.
Quote:Original post by hplus0603
The scary thing is that the memory busses don't keep up with the CPU speed increase. And now, there's two (or three, or four) CPUs, each of which is ravenously consuming memory bandwidth. And the frame buffer and textures share a unified memory controller with these CPUs.
At least for one of the systems the frame buffer won't be sharing that memory bus.
Maybe I'm missing something, but doesn't the interpolation based fixed time step system mean that all input isn't shown to the player until the second time step after the input?
Say you have your two states already calculated, the present and future state. As we interpolate between these two states all of the input being recorded is not being reacted to because the future state is already computed. Once we get to the future state, it becomes the current state, and we calculate a new future state. This future state takes into account all of the buffered input, but isn't displayed right away. We interpolate to this future state, and once we reach it then the input from a timestep ago is finally displayed.
That would mean an average input lag of 1.5 time steps, or for a 10 ms timestep 15 ms. The lag would be between 10 and 20 ms. Is that not much of a worry?
Say you have your two states already calculated, the present and future state. As we interpolate between these two states all of the input being recorded is not being reacted to because the future state is already computed. Once we get to the future state, it becomes the current state, and we calculate a new future state. This future state takes into account all of the buffered input, but isn't displayed right away. We interpolate to this future state, and once we reach it then the input from a timestep ago is finally displayed.
That would mean an average input lag of 1.5 time steps, or for a 10 ms timestep 15 ms. The lag would be between 10 and 20 ms. Is that not much of a worry?
Quote:Original post by intrest86
Maybe I'm missing something, but doesn't the interpolation based fixed time step system mean that all input isn't shown to the player until the second time step after the input?
Say you have your two states already calculated, the present and future state. As we interpolate between these two states all of the input being recorded is not being reacted to because the future state is already computed. Once we get to the future state, it becomes the current state, and we calculate a new future state. This future state takes into account all of the buffered input, but isn't displayed right away. We interpolate to this future state, and once we reach it then the input from a timestep ago is finally displayed.
That would mean an average input lag of 1.5 time steps, or for a 10 ms timestep 15 ms. The lag would be between 10 and 20 ms. Is that not much of a worry?
Yes, which is why I'd probably eventually move to a smaller timestep. The alternative is to recalculate the step if you know that you recieved input since you previously calculated it, but there's a risk of 'jumping.' I guess it worked particularly well in Perimeter because it's an RTS - a split-second delay in selecting a unit or beginning a move order is unlikely to be noticed. An FPS might be more problematic - I've not tried it.
How about implementing a platform on the console similar to .net/java where it's multithreaded behind the scenes; ie java's AWT event thread and .net's equivalent. There'd be plenty of cycles available for an input thread, physics thread, an ai thread etc... and the team wouldn't have to code for them specifically, they'd just be there?
You can't just take multiprocessing and "throw it into the framework." You need to design for it - account for synchronization, effective load balancing and so on - or at least, you do if you want to get decent performance out of it. dotNET's attribute system makes it fairly simple to cook up a [parallelizable] attribute and apply that to a loop or something (so for i = 1 to 100, 1 to 50 go on one processor and 51 to 100 on the other), but it still requires that you actually apply that and that the stuff you're applying it to can operate in parallel.
Sheesh, "they'll just be there," are you lazy or what? [razz] [wink]
Sheesh, "they'll just be there," are you lazy or what? [razz] [wink]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
