For some reason, this idea came into my mind: that the existence of this kind of contests proves either the marketing departments have really trouble figuring out how to promote many-core processors, or there is no real demand for these monsters except a few niches.
Couldn't most of games use it for higher complexity graphics? It looks like people are still not developing for multicore... maybe it's still "too hard" for an average game developer?
Games face bottlenecks from heavy statefulness. Animations, physics, and AI have design-required interdependencies where a change in one will trigger a change in the other - e.g., the player character throws a box, it collides with an enemy, and the box breaks, while the enemy shows a visible hitreact or knockback, and possibly changes their future tactics. Sometimes you can queue and defer all of these changes for a frame and lose some responsiveness, but other times it's really critical to have them all sync up.
The render stage of graphics benefits from massive parallelization, but most subsystems can't see the same improvement. A common fallacy of new game programmers is to think that "one thread per actor" is a clean architecture - only to discover that each actor's thread blocks the others and causes massive slowdown.
Comments
For some reason, this idea came into my mind: that the existence of this kind of contests proves either the marketing departments have really trouble figuring out how to promote many-core processors, or there is no real demand for these monsters except a few niches.
Couldn't most of games use it for higher complexity graphics? It looks like people are still not developing for multicore... maybe it's still "too hard" for an average game developer?
Games face bottlenecks from heavy statefulness. Animations, physics, and AI have design-required interdependencies where a change in one will trigger a change in the other - e.g., the player character throws a box, it collides with an enemy, and the box breaks, while the enemy shows a visible hitreact or knockback, and possibly changes their future tactics. Sometimes you can queue and defer all of these changes for a frame and lose some responsiveness, but other times it's really critical to have them all sync up.
The render stage of graphics benefits from massive parallelization, but most subsystems can't see the same improvement. A common fallacy of new game programmers is to think that "one thread per actor" is a clean architecture - only to discover that each actor's thread blocks the others and causes massive slowdown.