Falk
Schon immer hier...
We had the opportunity to talk with Jan Paul van Waveren, programmer at id Software, about AMDs triple core approach.
PCGH: Is there enough space between Dual and Quadcore CPUs to optimize for? I.E. is it feasible to optimize for two cores, three cores etc. or rather optimize for many cores, regardless of the exact number?
Jan Paul van Waveren: So far most game engines have exploited task parallelism to take advantage of multiple cores. Separate tasks are identified and executed on different cores. Typically the game engine is considered a pipeline and this pipeline is broken up into multiple steps/tasks, where each step runs on a different core. For example QUAKE 4 breaks the pipeline into two steps:
1. game code + renderer front end
2. renderer back end
Going to three cores you can split the pipeline further:
1. game code
2. renderer front end
3. renderer back end
Going to even more cores the pipeline can be broken up further, or other parts of the code can be split off and run in parallel:
1. AI code
2. effect physics
3. game code
4. texture streaming & de-re-compression
5. sound engine
6. renderer
The above is close to what the Enemy Territory: QUAKE Wars game engine does. Having 6 separate tasks, or steps in your pipeline, does not necessarily mean the engine scales all the way up to a system with 6 cores. Some tasks may take more time to complete than others, and multiple tasks and their associated threads may run on a single core. Exploiting task parallelism can be very effective. However, it is not always easy to identify different tasks that take up similar amounts of time such that all cores are tasked equally. Furthermore, it typically requires a lot of programmer time to cleanly separate the task such that they can run in parallel.
PCGH: What kind of differentiation can you imagine for gaming workloads to be distributed between three cores?
Jan Paul van Waveren: To scale well on systems with an arbitrary number of cores it is more effective to exploit data parallelism. In this case each core performs the same task but on different pieces of distributed data. For instance, instead of running the AI in a separate thread, each AI character can run in a separate thread. Each thread performs the same task, in that it advances the state of one AI, but each thread works on a different AI character. Another example would be texture decompression, where multiple threads could be used to decompress subsections of an image, as opposed to having one thread decompress a whole image.
PCGH: Is a console-game, especially a Xbox360 port, a natural to profit from three but not necessarily four cores?
Jan Paul van Waveren: Current high profile game engines are designed for multiple platforms, including the PC, Mac, XBox 360 and PS3. As such the engine is not specifically designed for a fixed number of cores. Instead the engine is setup to have enough separate tasks, or exploit enough data parallelism such that it scales well on all platforms. From a programming perspective the ideal number of cores is one single super fast core. However, with a definite trend to a growing number of cores on today's CPUs there is no easy way around it, and more programming time will have to be spent to take advantage of all the cores.
PCGH: Thanks for the interview!
---------------------
Other gaming related interviews on PCGH Extreme:
Technical Q&A S.T.A.L.K.E.R. Clear Sky
Interview: Tim Sweeney (Epic) talks Triple-Core
PCGH: Is there enough space between Dual and Quadcore CPUs to optimize for? I.E. is it feasible to optimize for two cores, three cores etc. or rather optimize for many cores, regardless of the exact number?
Jan Paul van Waveren: So far most game engines have exploited task parallelism to take advantage of multiple cores. Separate tasks are identified and executed on different cores. Typically the game engine is considered a pipeline and this pipeline is broken up into multiple steps/tasks, where each step runs on a different core. For example QUAKE 4 breaks the pipeline into two steps:
1. game code + renderer front end
2. renderer back end
Going to three cores you can split the pipeline further:
1. game code
2. renderer front end
3. renderer back end
Going to even more cores the pipeline can be broken up further, or other parts of the code can be split off and run in parallel:
1. AI code
2. effect physics
3. game code
4. texture streaming & de-re-compression
5. sound engine
6. renderer
The above is close to what the Enemy Territory: QUAKE Wars game engine does. Having 6 separate tasks, or steps in your pipeline, does not necessarily mean the engine scales all the way up to a system with 6 cores. Some tasks may take more time to complete than others, and multiple tasks and their associated threads may run on a single core. Exploiting task parallelism can be very effective. However, it is not always easy to identify different tasks that take up similar amounts of time such that all cores are tasked equally. Furthermore, it typically requires a lot of programmer time to cleanly separate the task such that they can run in parallel.
PCGH: What kind of differentiation can you imagine for gaming workloads to be distributed between three cores?
Jan Paul van Waveren: To scale well on systems with an arbitrary number of cores it is more effective to exploit data parallelism. In this case each core performs the same task but on different pieces of distributed data. For instance, instead of running the AI in a separate thread, each AI character can run in a separate thread. Each thread performs the same task, in that it advances the state of one AI, but each thread works on a different AI character. Another example would be texture decompression, where multiple threads could be used to decompress subsections of an image, as opposed to having one thread decompress a whole image.
PCGH: Is a console-game, especially a Xbox360 port, a natural to profit from three but not necessarily four cores?
Jan Paul van Waveren: Current high profile game engines are designed for multiple platforms, including the PC, Mac, XBox 360 and PS3. As such the engine is not specifically designed for a fixed number of cores. Instead the engine is setup to have enough separate tasks, or exploit enough data parallelism such that it scales well on all platforms. From a programming perspective the ideal number of cores is one single super fast core. However, with a definite trend to a growing number of cores on today's CPUs there is no easy way around it, and more programming time will have to be spent to take advantage of all the cores.
PCGH: Thanks for the interview!
---------------------
Other gaming related interviews on PCGH Extreme:
Technical Q&A S.T.A.L.K.E.R. Clear Sky
Interview: Tim Sweeney (Epic) talks Triple-Core
Zuletzt bearbeitet von einem Moderator:
) und genau da liegt das Problem bzw der Aufwand!
