GDCE 2004 - Latest CPU Development Issues- archive

Real World Multithreading in PC Games - Intel

This talk was delivered by Leigh Davies & Maxim Perminov from Intel. The session, via example games, presented the issues and benefits of using multithreading on the new multiprocessor systems and systems with hyper threading technology.

Future processors for the PC and for consoles are all aiming to have multi threading capabilities.

• Logical processors can be visible to the OS even though there may be less actual physical processors e.g. 2 processors look like three. This is what hyper threading does. This is made possible because processors tend to be under-utilised.
• There are not many people using multithreading, previously due to lack of support but now even entry level machines have HT ( it was introduced in 2002).
• Threading involves significant high level design changes but most code does contain some parallelism.
• Divide data among worker threads e.g. Particle systems, physics, AI. This is good for CPU bound games. So have two update world threads.
• Could have update world and Render world threads. Update is n+1. An RTS game was used as an example: 10 or 20 logical frames a second. Renderer goes as fast as possible interpolating between t and t+1. World update calculates t and t+1.
• So put the logic and AI into thread 1 and rendering and GUI into thread 2.
• Data exchange between the threads is important. Logic to rendering is via shared buffer. Logic to GUI is passed as a structure. GUI player actions are batched and then passed to logic.
• Game uses 2 threads only when there are 2 or more CPUs, otherwise it uses single thread sequential mode.
• Good diagram on slide here of update world.
• Multithreading makes the game smoother - I was not convinced by this because as they were saying this they were giving a demonstration of a game running single threaded and multi threaded and the FPS was all over the place under multithreading (could have been just a demo issue of course).

My notes for this talk were not brilliant, a better description can be found online. I am going to try to get the slides for this talk as well because there were some good diagrams showing potential areas for threading and detailing how to break up the various components of a game.

AMD, Crytek and MS deliver a Far Cry from the 32-bit World

The title of this talk was a bit of a mouth full but I was interested to hear the Crytek developers talk about the development of the amazing Far Cry. This session described the benefits of 64 bit processing and the issues faced by Crytek when developing the 64 bit version of Far Cry.

AMD were obviously keen to promote 64 bit processors however I was not totally convinced of the benefits. The larger address space may become useful and the additional registers certainly will but when Crytek described all the issues faced (for only a small speed increase) I wondered if it was really worth it.

• 64 is still backwardly compatible with 32 there is no emulation it is all native code.
• 32 bit apps get access to larger memory under 64.
• Can just load all data into memory and due to the large address space you can then treat is like a disk. Os will page in and out.
• Scales better with addition  of memory.
• Dual core has 2 CPU and Level 1 and level 2 cache.
• Multi threading is easier now with the arrival of the OpenMP API (it is available in the new visual studio - Whidbey).
• Don't just use function level threading as will not fully utilise both cores. Instead use data parallel threading.
• Bigger number of registers. 32 bit has 8 registers, 64 has 16.
• In 64 bit a pointer is 64 bits but a long is still 32 bit. So there are new types available e.g. LONG_PTR is 32 bit under existing 32 bit coding but is 64 bit under later 64 bit processors.
• AMD has a free tool called codeanalyst available from the developer section of their web site.

Probably the best bit was where he showed how easy it was to make a loop run in parallel. If you have a loop where the order of execution is not relevant you can simply add one command before it and it will be calculated in more than one thread (it uses a pragma).

The Crytek people then described the issues faced porting Far Cry to 64 bit. When they simply recompiled and ran it under 64 bit there was a slight speed loss. They then went through the code optimising it for 64 bit.They faced many issues like structures no longer being aligned properly etc. I found the catalogue of problems they faced to be a bit off putting given the relatively small speed gains they achieved.