Article: Parallelism at HotPar 2010
By: Jukka Larja (roskakori2006.delete@this.gmail.com), February 6, 2011 5:01 am
Room: Moderated Discussions
Moritz (moritzgedig.spam@arcor.de) on 2/3/11 wrote:
---------------------------
> The stuff doesn't happen continuous, but in
> time-steps. Is the player going to notice, if the
> world-setup uses the physics data of the last
> iteration instead of the current, if the NPC
> reacts with one iteration/frame latency?
Short answer to that is yes, player is going to notice.
A bit longer answer is of course that it depends. If you are simulating some eye candy, non-gameplay related effects, then sure, latency doesn't matter much. Or if game type is real time, or better yet, turn based strategy, a little more lag won't be noticed (though you better use hardware mouse pointer. Lagging mouse pointer is pretty much easiest thing to notice). But if it is something that affects NPC's movement in a fast paced game, then every frame counts.
> Likely this is being done today, in games, but
> that was just an example. I just think that
> there is much talk about how difficult it is
> when there are simple ways for many problems.
> Sure there are some problems that are hard or
> not to be parallelized, and some here are
> working on such, but are they really that
> common?
The problem is that double-buffering graphics already adds anything from 17 ms (60 Hz) to 50 ms (20 Hz) by default. Many monitors add (or used to, I'm not really up to date on this issue) an extra refresh time (at 60 Hz). Then there's USB polling that is done at 125 Hz, IIRC. There really is quite a lot of lag already. Adding another 33 ms (for 30 FPS, as is usual on consoles or low to middle end PCs, maybe even highesh end depending on gamer's preferencies) may well be, and is for many gamers, a significant annoyance.
Once you start to divide things based on latency requirements, it is far from simple to come up with working system. Taking the most time consuming task and threading that suddenly feels a much better idea.
That said, some things really are easy to do in parallel. For example, once frame is ready to be drawn, everything else for the next frame can be done at the same time renderer is running (and, as often is also the case, while waiting for vsync). That, however, is only just two threads. In my opinion, that is pretty much where easy ends and hard begins.
-JLarja
---------------------------
> The stuff doesn't happen continuous, but in
> time-steps. Is the player going to notice, if the
> world-setup uses the physics data of the last
> iteration instead of the current, if the NPC
> reacts with one iteration/frame latency?
Short answer to that is yes, player is going to notice.
A bit longer answer is of course that it depends. If you are simulating some eye candy, non-gameplay related effects, then sure, latency doesn't matter much. Or if game type is real time, or better yet, turn based strategy, a little more lag won't be noticed (though you better use hardware mouse pointer. Lagging mouse pointer is pretty much easiest thing to notice). But if it is something that affects NPC's movement in a fast paced game, then every frame counts.
> Likely this is being done today, in games, but
> that was just an example. I just think that
> there is much talk about how difficult it is
> when there are simple ways for many problems.
> Sure there are some problems that are hard or
> not to be parallelized, and some here are
> working on such, but are they really that
> common?
The problem is that double-buffering graphics already adds anything from 17 ms (60 Hz) to 50 ms (20 Hz) by default. Many monitors add (or used to, I'm not really up to date on this issue) an extra refresh time (at 60 Hz). Then there's USB polling that is done at 125 Hz, IIRC. There really is quite a lot of lag already. Adding another 33 ms (for 30 FPS, as is usual on consoles or low to middle end PCs, maybe even highesh end depending on gamer's preferencies) may well be, and is for many gamers, a significant annoyance.
Once you start to divide things based on latency requirements, it is far from simple to come up with working system. Taking the most time consuming task and threading that suddenly feels a much better idea.
That said, some things really are easy to do in parallel. For example, once frame is ready to be drawn, everything else for the next frame can be done at the same time renderer is running (and, as often is also the case, while waiting for vsync). That, however, is only just two threads. In my opinion, that is pretty much where easy ends and hard begins.
-JLarja
