Embattle
FH is my second home
- Joined
- Dec 22, 2003
- Messages
- 13,220
That's true. I was reading something about Unreal Engine 3 a while back (which support multithreading CPUs) and it sounds like a lot of hassle to get things up and running, and even then not every area of a game, say, can utilise multithreading effectively. Still, time will tellEscape said:The lack of applications/games which can use dual cpu/cores, will hold them back from the mainstream.
Kind RegardsTim Sweeneyy said:For multithreading optimizations, we're focusing on physics, animation updates, the renderer's scene traversal loop, sound updates, and content streaming. We are not attempting to multithread systems that are highly sequential and object-oriented, such as the gameplay ...
... it's especially important to focus multithreading efforts on the self-contained and performance-critical subsystems in an engine that offer the most potential performance gain. You definitely don't want to execute your 150,000 lines of object-oriented gameplay logic across multiple threads - the combinatorical complexity of all of the interactions is beyond what a team can economically manage. But if you're looking at handing off physics calculations or animation updates to threads, that becomes a more tractable problem ...
... You can expect games to take advantage of multi-core pretty thoroughly in late 2006 as games and engines also targeting next-generation consoles start making their way onto the PC.
Writing multithreaded software is very hard; it's about as unnatural to support multithreading in C++ as it was to write object-oriented software in assembly language. The whole industry is starting to do it now, but it's pretty clear that a new programming model is needed ...
TdC said:my NwN saves dir was huge at a certain point. this caused the game to judder to a halt when in the loads/saves option menu as the engine read out the data from each save I had done. now if there were two threads in two cores, one could be talking to the disk while the other could be presenting me a nicely smooth scrolling save-games menu
Embattle said:I would of thought that would happen no matter how many processor cores, esp since I would consider that a HD related issue.....basically they are still as slow as hell in relative terms of other parts of computers.
In defence of the present Intel/AMD architecture, however, it is noted that existing software must be rewritten to support the Cell (and other dual/multi-core CPUs) and that most software doesn't make efficient usage of parallel execution anyway, which is where multithreaded systems can excel. It seems hardware abstraction (i.e. being able to forget about what hardware your software will work on) is also dumped by the Cell design, which may create more complication is a similar stance was adopted by Intel/AMD's dual/multi-core products.PC Format April 2005 said:The Cell is designed for vector processing ... handled by something called a Synergistic Processor Element or SPE. [...] a single Cell processor has eight SPEs all running summultaneously ...
Each SPE is a complete, independent processor core with four integer maths units, four floating-point units and 256K of its own internal memory. Controlling all of these is yet another processor ... based on IBM's PowerPC chip. [...] nine complete processors plus local storage all packed onto a single chip
Jonty said:P.S. There's also a funny little statistic quoted that the theoretical power of two PS3's adequately linked together would actually rank as the 500th most powerful computer on the planet
Well, you can already do asynchronous loading from a HDD - basically the program says go to the disk subsystem then gets on with processing the game (or whatever) and get's a notification at some point in the future when the data is available. A lot of the time games will stall because without the data they just can't do anything, there's only so much predicitve loading that can be done.TdC said:that's not entirely true. it happening, that is. HDD's being slow as hell is a given naturally my point was that all IO to devices could be "handed off" (as Tim puts it) to a helper thread for (example) seamless background loads while the main threads keep the game running smoothly. What Tim says is very logical from the game engine's perspective, ie having certain tasks that the engine has to perform in separate threads so that the engine runs as smoothly as possible.
that's all nice and stuff, but I personally would like to see the game run asap. point being that you'd never have to wait for anything again. ever. all IO, physics, animation being done while the "game" thread keeps the eye-candy flooding your monitor.
ah, but that is the thing indeed. the point being that a helper thread could be looking after this continually while a main thread would be showing what it had ready. in my mind there is not only a whole bunch of real and virtual cpus doing their best to keep threads working at optimal performance, but there will be a change in how stuff is done from a programming, or scheduling standpoint. I'm finding it hard to explain as I am not a programmer. In this respect I am a deciple of Sun Microsystems and AMD: "you don't have to do something at blinding gigahertz if you can do it in the proper order, or at optimal efficiency.Danya said:A lot of the time games will stall because without the data they just can't do anything, there's only so much predicitve loading that can be done.
Just on that tiny point, rather than the whole discussion, I recall John Carmack (I think) stating that the Doom 3 engine is such that, with the right amount of RAM on a fairly powerful system, the entire game's content could be preloaded without any significant problems (I guess this holds true for Source et al).TdC said:you don't have to know where a player's pawn will go to be able to preload/cache/whatever. I think it's because that engines get taylored to be able to run on the "lowest common denominator" of cpu/mem/gfx combinations and thusly don't do as much as they possibly could
GPU is much faster, and they're getting quite general purpose these days. Even so, they are specialised for operation that games need - physics, animation etc. they all can run just fine on a modern GPU because most of the work they do is 3d vector maths, which is what GPUs are very good at. AI can be a bit tougher because making decisions is not something a GPU does well.TdC said:troo, troo, the thread would be sleeping a majority of the time but doing something with the data returned would be costly imo. to my mind your comment on a GPU being faster by far than a CPU is because it's a specialized bit of kit that does nothing else but graphics operations. if you had threads preprocessing animation and other stuff apart from the main engine things would go very much more swimmingly, though I don't agree with the "only linear games being able to stream" stance. you don't have to know where a player's pawn will go to be able to preload/cache/whatever. I think it's because that engines get taylored to be able to run on the "lowest common denominator" of cpu/mem/gfx combinations and thusly don't do as much as they possibly could.
No it doesn't. I preloads character textures and such, but the world is streamed.Chilly said:daoc does full pre-loading