Challenges of a Public Release

Without a doubt, creating a public release of Pcsx2 is an exhausting affair. We just got finished posting the latest and greatest in 0.9.6 (available in our Downloads Section!), and while it's nice having everything done and over with for now, it sure feels like there should have been a better way.

This time around we tried to make use of our GoogleCode Svn in "smart" fashion, and created a branch for the Release Candidate. The jury's still out on if this proved to be successful or not. Several ground-breaking fixes were submitted shortly after the RC branch was made, so we had to merge all of that stuff in. Furthermore, I got carried away and experimented with partial merges, without fully understanding the advantages of reverse merges, so I had to undo several of my own merging errors. And just to add salt to the wound, TortoiseSvn had a bug that would frequently "forget" line breaks; merging all code changes into one super-long line. -_-

So in the end, the merges required a lot of brain power, a lot of time, and may have led to some small mistakes. These were all things we were hoping the RC branch would help reduce, so it was a bit of a fail on that account.

The other stress tester when doing an official release is the updating of the compatibility list, which is both a lot of work for our dedicated testers and has the nasty side-effect of making us devs completely and totally aware of just how many games actually emulate worse now, instead of better. So each day was a mad dash to do regression testing on each new set of titles that came in as no longer being playable. This was made even more challenging by the fact that most of the regressions ended up being pretty old, dating back to the pre-Playground days (meaning they were attributed to 0.9.5 Svn revisions). We only managed to get a few of the riddles solved.

So yeah, it's true -- the overall "playable" number of games is lower in 0.9.6 compared to 0.9.4, due to many semi-obscure titles which are unable make it past the intro in 0.9.6. But on the other hand, games that are playable tend be much more accurately emulated now, and are certainly much faster. And 0.9.6 also runs a couple dozen games that 0.9.4 could not (most of which are big titles many folks have looked forward to for some time). In the meantime, though, you might want to keep that old 0.9.4 copy around for some of those titles that need it.

The amusement continues....

The new version of PCSX2 is out, development continues, ideas flow through the team and new ideas for fun spring to mind, just to forget about the work at hand for five minutes! This time, in the form of a video containing "misheard lyrics". We all listen to songs and sometimes completely miss the correct lyrics in a song, but i decided to go one step further with this following number and see what i could make in english out of a song which is sung in sweedish (afaik). The idea came around after Falcon4ever was thinking of ideas for a 404 page on a subdomain of ours to wind up one of the other team members, with the use of an annoying song.

Well, needless to say, it worked, but the song was so crap i figured I'd make it a bit more fun, sat down with Cool Edit open for a while and jotted down what i "thought" i heard!

So in its full glory here is the song with the misheard lyrics written below. You will need Flash Player installed, big thanks to Falcon4ever for mocking this up! I detest flash...

Original Song: Caramell - Caramelldansen (Speedycake Remix)

* update *
A small preloader bug prevented the video from working in IE7, it should be fixed now.
- Falcon4ever

Next destination: PCSX2.net

Ever wondered from which country and city we get the most visits?

Country top 5:

1. United States - - (706,921)
2. Japan - - (524,869)
3. Brazil - - (504,787)
4. Germany - - (392,980)
5. France - - (331,084)

City top 5:

1. Madrid, Spain - - (104,796)
2. Sao Paulo, Brazil - - (79,615)
3. Tokyo, Japan - - (78,990)
4. Santiago, Chile - - (75,821)
5. Moscow, Russia - - (75,006)

Bositman! Wooooooooo

In our spare time, some of us do little things to amuse ourselves and others, generally involving the betatesters, the devs, or generally people who come in the IRC channel.

You may have previously seen CKemu's "Betatester Magazine" issues or his comic strips involving testers and developers. Well my "party piece" is making little songs, with the help of some of our IRC chatters of course!

Bositman is well known throughout the community, so we (being myself and GB_Away) decided a while ago to make a little song in his honor, it was catchy and fun to make but i wasn't totally happy with the sound. Recently i decided to remaster the song and redo the guitar, so for your listening pleasure i have placed it online for all to be amused!

The lyrics are simple but they say enough!

"Bositman, Bositman, ooooooooooooo, Bositman, Bositman, Bositman, Bositman, BOSITMAN!, Bositman, oooooooooooooooo, Bositman, Bositman, Bositman, Bositman"

And here in nice 320kbps 48khz MP3 format, is the song, enjoy!

Edit by bositman: Dude,I told you it's not pronounced as an "s" but "z"!!

Refraction Feat GB_Away - Bositman.mp3

Graphics Synthesizer, GPUs, and Dual Cores

It was apparent early on the project that the GS plugin was going to be a big bottleneck during 3D scenes. It isn't that the GS plugin itself does a lot of computation on the CPU, but the fact that it needs to communicate with the graphics card means that unnecessary stalls will occur in the graphics driver as the GPU and CPU are synchronized. During these stalls, the CPU basically goes to lunch until the GPU is ready. Graphics drivers and libraries are aware of this and try as little as possible to communicate with the graphics card. They usually cache render state changes, shader changes, and texture changes up until actual geometry is rendered. They also take advantage of FIFOs (first in first out buffers). The CPU just writes to the FIFO and the GPU just reads from it, this makes all the difference in terms of keeping the GPU active while the CPU isn't and vise versa.

The biggest challenge when designing games and hardcore applications that need to use the GPU to its full potential is to make sure that graphics driver stalls are minimal at all costs. What kills games isn't sending geometry down the graphics pipeline, but it is when render targets are switched, render targets are used as textures in the next draw call, textures are locked, and when render targets are transferred from GPU memory to CPU memory (in the last case, the CPU not only goes to lunch, but has dinner also). GPU optimization talks usually appear in every Game Developers Conference and there are many papers on them on the net, so there is a lot more to the story than written here.

All this means is that single-threaded applications really need to design their GPU algorithms well to see fast frame rates. This unfortunately is not possible with Pcsx2 and the GS plugin. The GS plugin has to draw geometry in the same order as it was received. This kills almost all caching techniques used by modern games because the GS and PC GPUs have very different performance bottlenecks. In modern GPUs, it is advantageous to group as much geometry as possible in one draw call. The GS doesn't suffer from such bottlenecks. The GS also has two different contexts which makes things twice as difficult. ZeroGS can only do a limited amount of work-arounds before compatibility starts dropping, so the only other option is to try to multithread the GS. Note that using graphics libraries from multiple threads is not a trivial task.

Fortunately, the GS plugin is very unique in its nature. 99% of the communication that happens between the GS plugin and the rest of the systems components happens in the direction to the GS. The only times the EE needs to synchronize with the GS is when it reads back the FINISH/SIGNAL registers and part of the 4Mb GS memory. Register readbacks are used frequently, so this suggests that tight synchronization will be needed with the GS. The GS memory readbacks aren't as frequent; however, they require some special considerations with Virtual Memory and DMAs. The rest of the 99% of communication that goes to the GS happens with a GS FIFO.

When first started, Pcsx2 creates a GS thread and reserves special memory for the GS FIFO. The GS plugin then creates the Direct3D device/GL context only for that thread. Then when the game runs, the EE copes all its GS packets to the FIFO and then notifies the GS thread. The GS thread then checks if the FIFO has data, and then sends it to the GS plugin. This sounds easier than it actually is because very tight synchronization needs to happen to make sure no overwriting occurs in the FIFO. The FINISH/SIGNAL register synchronization actually doesn't happen across the EE and GS thread boundaries. Instead the EE thread peeks at all the packets ahead of time and handles it in its own routines.

What makes the "Dual Core" option special is the notifies part of the last explanation. The GS thread can either sleep waiting for a notification from EE, which can be done by WaitForSingleObject and SetEvent functions. Or it can continually check if the GS FIFO is empty without ever stopping. The latter option kills single cores but goes much faster on dual cores. The results of clicking on the MTGS and DC options on dual cores are phenomenal. Usually frame rates go up or even surpass 2x.

Multithreading in games is going to be very big in the future. The times have passed when there is one CPU that does everything and one GPU that just renders. The biggest problem is which game processing to divide into which thread, and how these threads will communicate with each other. Many of these issues are still open and current game companies are struggling with the added complication of concurrent execution.

Moral of the blog - GPUs have become so powerful that people are staring to do tasks like stereo vision and general purpose computation with them. Learn how to use them. I recommend ShaderX3: Advanced Rendering with DirectX and OpenGL by Wolfgang Engel and GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation by Matt Pharr, Randima Fernando, and the 20+ researchers that contributed to it.