ECE4893A/CS4803MPG – Homework #5

ECE4893A/CS4803MPG – Homework #5

ECE4893A/CS4803MPG: Multicore and GPU Programming for Video Games

Fall 2010

Homework #5: Aperture Science Xbox Multicorification Center

Due: Friday, Dec. 17, at 5:00 PM (via T-square)


Late policy: This homework will be
graded out of 100 points. We will
accept slightly
late submissions; one turned in past 5:00 PM on Friday, but turned in by
midnight, will be given
a 20 point penalty. We will not accept late submissions after that,
since we need to get them graded so we can compute letter grades. And really,
I’m sure there’s other stuff you’ll want to be doing on Friday night, yes?
So make an effort to get it done early.


Hello and again
welcome to the Aperture Science Xbox Multicorification Center.
Your application for employment has been reviewed, and
on the basis of your participation in the Georgia Tech
class “Multicore and GPU Programming for Video Games,” we have elected to
detain you for further testing to determine your suitibility for
employment as a Multicorifier.


Multicorifiers at the Aperture Science Xbox Multicorification Center
are responsible for transforming legacy single-threaded game
code into multi-threaded game code in preparation for the incorporation
of enhanced features that would overwhelm a single-threaded
implementation.


You may participate in the testing in either “solo” or “co-op”
mode. (In the
previous homework, these were referred to as “one-person” and “two-person”
teams.) If you operated as part of a “two-person” team on HW #4, and wish
to participate in “co-op” mode in this assignment, you must pick a
different person
as your teammate. If you are going to participate
in co-op mode, you must let Dr. Lanterman know who you are working with by
5:00 on Thursday, Dec. 2. If Dr. Lanterman does not hear from you by
then, we will assume that you are participating in “solo” mode.


To demonstrate your 1337 multithreading skills, please find an
interesting single-threaded XNA game that you would like
to work on. Be sure to select a game with a design that
emphasizes the real-time nature of the medium, such as an arcade
game, a first-person or third-person shooter, a martial arts game, a
real-time strategy game, sports game, flight simulator, etc., and
not something like a Bejeweled or chess.
We recommend finding a program that works in XNA 3.1 and the Xbox 360
“out of the box.” If you want to try to use game that was created using
an older version of XNA, and/or one
that is only claimed
to work under Windows, realize that you may need to make
some tweaks to get it to work in XNA 3.1 and on the Xbox 360, and these tweaks
may be easy or difficult.

Or, if you are already working on your own original XNA game
(either for another class, to enter in a competition, to try to sell on
Xbox Live Indie Games, or just for fun),
and it’s currently single-threaded, you may consider using it, but please
check with Prof. Lanterman first.
You
are welcome to use the various Starter Kits such as Spacewar, or one off the
Creator’s Club
website, but avoid games that are already extensively
multithreaded (such as
Rocket Commander and Racing Game).


You must let Dr. Lanterman know what game you have decided to work with
by midnight on Friday, Dec. 3, so that you may be sure to start working on
it that weekend.


We strongly recommend that, if possible, you choose a teammate (if you
are going to do so) and a game earlier than the required dates mentioned
above. It is also vital that you try deploying your chosen game to
the Xboxes, both to make sure that you are comfortable with the
(somewhat error-prone and tedious)
XNA deployment procedure for Xboxes in general and to
make sure that your chosen game runs on the Xbox in particular.


Ideally, each applicant (either “single players” or “co-op mode” teams)
would be working on a diferent game, although we realize that the same
game may be independenly chosen by multiple applicants.


Here are some links of places to start looking. Google may turn up more.


(Aperture Science in no way warrants the usefulness of the code available
at any of the above
links. Any particular piece of code may be full of bugs, poorly written,
may not run on the PC, may not run on the Xbox 360, or may not compile
at all.)


Spend some time looking at a different
games and poking at a lot of source code before you commit to one, since
you will be spending a lot of time with the source code of whatever game
you pick. You do not need to pick something
super-complicated; simpler games
will be easier to multicorify. (Please pick something at least slightly
more complicated than Pong; we become bored quickly when playing endless
versions of Pong.)


You will probably wish to do most of your development and debugging on the PC,
and then use appropriate compiler directives to set thread processor
affinities
for your Xbox 360 version. (Forgetting to set the processor affinities is
a common error; also, remember that the affinity must be set from the code
for the treat itself after it has started.)
Your should successfully run on the Xbox 360. (If you run out of time,
document what you have done and what problems you were having, and we will
assign appropriate partial credit.)


The four Xbox 360s in Klaus 1446 are available for your use. Note that up to
39
other subjects are being tested for suitability
as Multicorifiers. Please be courteous
about sharing the limited resources available. In particular, do not
expect to monopolize one of the 360s the day the project is due; we
recommend trying to finish ahead of the due date. (If necessary, we
may develop
some sort of “signup” system where you may reserve a block of time on
a 360, although this hasn’t seemed to be necessary in the previous offerings
of the course). If
you have your own Xbox 360, we encourage you to use it to alleviate
contention on the ones in Klaus 1446.


Both “single players” and “co-op teams” must modify
your single-threaded example program to use multiple threads
running on at least two cores by splitting the update logic and the
rendering logic into separate threads running on separate cores. Modify
the game state structures as needed to create a “double buffer” scheme
so that the rendering thread and go about its rendering business on one
buffer while the updating thread is writing to another buffer.
Designing code that is
intended to be multithreaded from the beginning is tricky; taking
code that was never intended to be multithreaded and making it
multithreaded, as we are doing here,
can be even trickier.
We will not be worried if your multithreaded implementation
does not run any faster, since making it work at all without
unpredicable bugs will likely prove sufficiently challenging. However,
it should not run significantly slower. Please put a few comments
in your code to make it easy for us to find the main places that you needed
to modify and we can follow what you did; in particular, we want to be
able to figure out your double-buffering strategy.


Co-op teams must additionally have an additional thread
(or threads) performing
some kind of useful
work on the third core. We are not going to be too specific about
the exact nature of the work done on the third core, as appropriate choices
will depend on the particular game you pick and how it is stuctured.
The third core must involve work that
is done on most of the frame during gameplay
(i.e. multithreading the initial content
load is insufficient).
One possibility might be to split the game state
update procedures between two cores in some way (maybe having one thread
update the positions of half of the enemies, and the third thread update
the other half), or perhaps have sound effects
all activated from the third core (in an “real” scenario of working at
a company, this might be done to set the stage for incorporating more
sophisticated audio effects, such as reverberation or Doppler effects).


You should feel free to make whatever other tweaks to the art assets or
gameplay that you would like, although such tweaks are not required for
this test.


<!–
Warning: As discussed in lecture,
most peripheral I/O, such as loading and saving games or reading
from the controller, seems to want to take place on the main thread.
Peripherals such as those
seem to be less accessible from spawned threads. –>


Remember, the Xbox 360s contain no user servicable parts. Do not
submerge the Xbox 360s in liquid, even partially.


Deliverables: “Solo” players should
package everything needed to compile and run your game
(3D data file, textures, code, etc.), along with a README file briefly
describing
what techniques you implemented and any particular problems or issues you
might have run into,
upload them to T-square as a zip file or gzipped tar file.
Include “HW5” and as much
as possible of your full name in the
filename, e.g., HW5_Aaron_Lanterman.zip. (The upload
procedure should be reasonably self explanatory once
you log in to T-square.)
Include a README file
of some sort that describes what changes you made to the code, why
you made the choices you did, and what difficulties you
encountered.


For “co-op teams,” one student should be the
“official uploader,” and should upload the materials described above. In
the comment box and in a README file included in code itself, give
the name of the student you worked with.
The “non-uploading” student should still “turn in” a homework, but their
homework will consist of
simply typing “Worked as a team with…” as appropriate
in the comment box,
and not upload the same file.
This will avoid us having to download large
duplicate files.
(The “non-uploading student” should
be sure to remind the “official” uploader to do the uploading; cries from
Student X along the lines of
“oh, Student Y said they’d upload it but they didn’t!” will not fall on
sympathetic ears.)


Be sure to finish sufficiently in
advance of the deadline that you will
be able to work around any troubles
T-square gives you to successfully
submit before the deadline. If you have
trouble getting T-square to work,
please try e-mailomg your compressed
file to lanterma@ece.gatech.edu,
with “MPG HW #5”
and your full
name in the header line;
please only
use this e-mail submission as a last resort if T-square isn’t working.
If e-mail doesn’t work, put it on your webspace and e-mail Prof.
Lanterman a link.




<!–Discussion board: We will set up a “HW #7” discussion board where
students can discuss the homework and in particular ask questions that
the professors and other students can help answer. –>


Ground rules:
The ground rules on this assignment differ from the others, and
are generally more relaxed, even concerning discussions between
different teams.
Since most “teams” (“solo players” or “co-op” teams)
will be working on different games, you should feel
free to look at one another’s code in detail,
ask others for help with
debugging your code, brainstorm strategies for your paricular game with
your friends, etc.
The only exception to this rule is if you find that
another team happened to pick the same game as you; in this case, you
should not be looking at each other’s code, but you can discuss high-level
issues. In your README file, be sure to give proper credit to people
who helped you, i.e. “Thanks to such-and-such for helping me find the
infinite recursion in blahblah.cs.”


Also, if you use adapt code from other sources, be
sure to credit the source both in your README and
in the code itself.