Resources:

Overview

This section is divided in two. There are some programming consideration you might need to know, and there is a discussion on performances.

First of all consider to read this. In this article you find a quick list of different aspects programming on the xbox, such as resolution issues, safe region, some hints about rendering and so on. It's short, so read it.

If you have problem with sprites in the xbox, read this

Perfomances

This topic is quite hot, and depending on what your project looks like you might experience a lot of problems or not. The classic scenario is that you program something which runs fine on the PC, and when you bring it to the XBOX you see a big performance drop. Now where does this drop come from?!? A first look to the [[http://msdn2.microsoft.com/en-us/library/bb313967.aspx][hardware capabilities] capabilities seems pretty confusing. The GPU of the XBOX is powerful at least as most of the Directx9 cards out there. Moreover the Xbox has 3 Cores each running two threads (2 reserved by xna, 4 at your disposal). And the problem lies actually here. Quoting this article (read it!):

Your first instinct will be to blame some aspect of managed code; the JITer, the Garbage Collector, blah, blah, blah. And in this case, you would be right, but it is the compiler in combination with the Xbox 360 CPU that has betrayed us. See, the Xbox 360 CPU cores have a couple of interesting problems associated with them. First, they have no out-of-order instruction fixup. This means that if the instructions arrive at the CPU in a way that isn’t optimal, the CPU generates stalls to keep things in sync. This is in direct contrast to the Intel and AMD CPUs for Windows, which have a fair amount of logic to reorder instructions as they come in to help the CPU digest them. The Xbox 360 CPUs are also RISC-based processors. A complex instruction set processor like the Intel and AMD processors have many, many complex, essentially single-step instructions to do what will take 2 to 5 instructions to perform on a RISC processor. Since we are compiling this to MSIL and then Just-In-Time compiling it on the Xbox 360, the compiler doesn’t have a lot of opportunity to reorder instructions the way the C++ compiler can. It also doesn’t get much opportunity to make use of the tremendous numbers of registers on the Xbox 360 to prevent load and storing from memory to the actual operations. Since the C++ compiler is an offline compiler, it can crunch on the code and help the Xbox 360 processor by reordering instructions that would cause these stalls and also be “register aware” to prevent loads and stores. The MSIL compiler won’t do this because it is processor agnostic, and the JITer is blissfully unaware of the CPU issues on the Xbox 360. The JITer must brute force everything.

Now there are some things you can do in order to improve your code. In a list:

  1. Check what part of the code has high frequency and deserve to be optimized (do not optimize elsewhere, which is useless and time consuming)
  2. Apply the following knowledge:
    • Do not use Class defined operators such as Vector multiplication. Multiply componentwise instead.
    • Retrieving data from the GraphicsDevice is slow on the Xbox 360. Save what you need in local variable and stop calling graphicsDevice.whatever which is painful.
    • In C# classes go to the heap while structs to the stack. Use structs instead of classes! (Vector2, Vector3....)
    • The Garbage collector of the xbox is a painful process. It is called every 1MB of objects created and it's not generational (it always traverse all the object graph). Therefore try to minimize the number of objects you create! Read this for further details.

You have done all this and still performances suck? Then it's time to go deeper in the understanding and learn how the .Net Compact Framework works, and especially how to exploit multithreading.

As said above the Xbox 360 has 6 hardware threads on 3 cores. Support for multiple hardware threads was also added to System.Threading so XNA developers can access 4 of the 6 hardware threads (2 are reserved) via SetProcessoryAffinity(). You will have to assign your threads manually to take advantage of the hardware threads as the Xbox kernel doesn’t do it automatically for you. Note that this API isn’t available on the desktop. Of course the general concepts behind efficient multithreaded coding and synchronization apply. Keep in mind that hardware threads are different from cores. Each core has two hyper threads that share the same cache. Putting two threads that access totally separate data on the same core can lead to unnecessary thrashing of the cache. XNA GSE doesn’t provide tools to really see what’s going on at the CPU level anyways, so if anything you can time your code and use some trial and error to determine what works best.

To learn how to assign specific code to specific thread with SetProcessoryAffinity() read this.

One other option to handle asyncronous tasks of doing is to use a thread pool - though it seems to be poorly implemented for xbox, at least at the moment. Read this to learn about it.

None of the suggestion given above worked? The last thing you can try before dropping the idea that causes this performance gap, is to investigate whether you can make the computation using the GPU.

Related Articles:


Page URL: https://twiki.graphics.ethz.ch/bin/view/GameClass/XboX360
2024-03-29
© 2024 Eidgenössische Technische Hochschule Zürich