palladin9479 :
Reepca :
palladin9479 :
jdwii :
de5_Roy :
logainofhades :
But when AMD's latest hardware isn't really any better than Intel's hardware from 6+ years ago, there is a problem. Hell, they aren't even all that competitive with their own previous generation hardware. A 3.4ghz C2Q is within 2-3fps of a 4.2ghz FX 4300 and 3.9ghz FX 6350. AMD isn't making better products, they are making worse to similar performance, to what they were 6yrs ago. Phenom II X4 @ 4.0ghz beating FX 4350 @ 4.2. Even overclocked to 4.7, it isn't significantly faster. The 6350 @ 4.5ghz isn't much better either. This is why AMD has been losing market share, on CPU side of things. They are not advancing, they are running in place. Throwing more cores at it, does little, when most software doesn't use the extra cores. They need a boost in per core performance, and badly so. I miss the old AMD that was competitive, and kept Intel on their toes. The K7 and early K8 days vs PIII/P4 was an awesome time to be a PC enthusiast. Instead, they got cocky, with K8 X2. Intel released Core 2, caught AMD with their pants down, and they have yet to recover. Constantly playing catch up. Intel's business practices probably didn't help, but AMD didn't exactly do itself any favors either.
Probably the same since CPU's don't physically get faster and its not like 12 gains are only noticeable on one vender keep in mind they already did these tests and it doesn't change anything its just the gap got smaller between the 2.
That's only because the tests were done using silly combinations like Pentium G / i3 + Titan / x80 GPU. In realistic situations the GPU will be the performance limiter not the CPU. The short term implications is that "you can game on a dual core!!!!!", which will last all of one year. The long term impact is that developers will start looking at other things to pack onto the CPU and that's where things get interesting. It's very difficult to parallelize the primary logic loop of a game but it's not difficult to parallelize things like AI, physics and environmental effects. Dynamic environments lend themselves particularly well to wide processors. We'll start seeing those additional resources start to be utilized more. Also please understand that the last six years have been console hell for the PC market, nearly every major game developer went out of their way to design everything for consoles because the mantra across the industry was "PC is dieing, all hail consoles!". PC versions of games were hastily thrown together ports with dirty patch code being used to "make it work with minimum manpower" right before release. That seems to be changing now with developers realizing there is a very profitable market segment to sell to, chiefly guys who grow up with Nintendo and early PC games who now have nice paying jobs and can afford high priced powerful toys called "gaming rigs". That market segment absolutely hates trash console ports and will vote with their wallets.
Question: When you talk about parallelizing AI/Physics/Environmental Effects, are you referring to data-parallelism or task-parallelism? For example, I have a hard time imagining one thread drawing and one thread handling physics to be very effective - the position of the objects depends on physics, so drawing must wait on the physics-handling thread, and it ends up serial anyway. If it's data-parallel, on the other hand, it seems straightforward enough to have a different thread handling the interactions between one object and the surroundings for each moving object (or for a group of objects, since there are likely more objects than cores and there isn't anything to be gained from having more threads than physical cores).
You gotta stop approaching things from a human PoV, humans are very serial thinkers to the tune of cause -> effect -> observation -> reaction. Physics is extremely dynamic and parallel, where time is the only serial element. Each interaction would be done simultaneously but only if that interaction happened within the exact same time slice and would use a number of threads equal to the number of simultaneous interactions within the same reference frame. This is how physics simulators work but doing it in real time is computationally expensive requiring massive parallel capabilities. The real issue is creating an API or other model that allowed the input and output of the physics to be useful to the logic of a game. It's extremely hard for humans to wrap their minds around dozens if not hundreds of things happening simultaneously so instead we think of it as a series of events handled in sequence which can work well without our own mind.
A good way to think of it would be how a database serves requests. Each request is a single serial task but the database receives many hundreds of these tasks every second and some of them interact with each other. So while each physics interaction is serial in that moment, there are many interactions happening simultaneously that can be processed separately, for that time slice / moment. Then with the results of those interactions you process the next time slice / moment, then the next and so on / so forth. The issue then becomes balancing it out so that you don't get caught behind since if it takes you longer then 10ms to calculate out the physics that took place in those 10ms your going to start having lag issues. You want to keep the interactions simple enough that you can do them quickly and not get caught, but complex enough to be useful.
I had a long post written up about dependencies between colliding objects between-updates that likely completely misinterpreted your post, so I scrapped it (partially resurrected later).
So if I understand this correctly, physics isn't part of the main game thread, but rather runs separately - constantly updating the state of all objects based on time passed and interactions between objects in a loop. In this way, it is task parallel. However each object is... well... its own object! An individual thread can process the interactions between each object and everything else. In this way it is data-parallel.
But the part that bugs me about this is that for any time-chunk, things happen within that time-chunk. Taking this to an extreme example, suppose that one time chunk lasted 10 seconds. Two people are moving towards each other and, simply checking their paths against each other, one would think they would collide, except that 1 second into this time chunk person A gets hit by a train and flies far away. If we only looked at the interactions between person B and the world, person A and the world, and the train and the world (individually, in parallel) we would end up with persons A and B colliding *and* the train hitting person A. The way I imagine it, nothing is "simultaneous" in a time chunk - something happening within 10 ms of another thing clearly doesn't mean they happen at the same time. Collisions should be detected, sorted by time, processed in order, and every time a collision is processed all objects are moved forward to that point in time (and the corresponding change in position) and any objects that thought they were going to collide with either of those involved in that collision must re-check for the soonest collision... in my head, at least. Due to dependencies between the objects, don't the interactions have to be processed in order?