Google Summer of Code

= About GSoC = http://code.google.com/intl/de/soc/

= Suggested Projects = This is a list of suggested projects. If any of these is actually feasible for a GSoC project needs to be evaluated, but this list should give some hints at areas that still need work in Dolphin.

Your own Project
Already got an amazing idea of your own? That's great! Coming up with your own project shows that you already took some time thinking about GSoC and showing initiative usually increases the chance of getting your idea accepted as a project. Make sure to thoroughly discussing your idea with us so that you don't end up with a project which is impossible to finish in 3 months of work though!

Automated Test Suite
Dolphin currently has no automated testing infrastructure. Sometimes regressions happen, or bugs are found in new features which could have been caught with some unit testing. Adding an automated test suite and simplifying writing test cases would help with that.

Tasks: implementing a null video backend to be able to run Dolphin in headless mode, add support for logging test results from inside the emulator, write a test suite framework that can run both inside Dolphin and on real hardware (using libogc and writing test results to SD card/network), writing tests for some parts of the emulator (FPU, strange CPU features, GFX, DSP), etc.

Isolate Core/GUI better and implement a Qt GUI
TODO: Description

Proper GPU synchronisation
Proper GPU FIFO processing has been quite a mess in Dolphin for a long time; many games seemed to work fine while others didn't even boot at all or sporadically crashed somewhere ingame. The situation is a lot better nowadays, but there are still some problems which cannot be solved without proper GPU synchronization at all.

The scope of this project includes, but isn't limited to:
 * reverse-engineering the number of console GPU cycles necessary to process each GPU operation
 * documenting the results, if possible via testing homebrew applications
 * properly emulating the hardware timing by pausing the CPU and/or GPU thread whenever either of the hardware chips are running too fast.

Speedup Software Renderer
The current GPU accelerated backends in Dolphin have a huge disadvantage compared to software renderers: API restrictions. Lots of GC/Wii hardware features (zcomploc, destination alpha, zfreeze, compressed Z) can only be emulated with huge work and some dirty tricks or cannot be emulated at all because the functionality is not exposed by PC GPU APIs like Direct3D and OpenGL. With a software renderer on the other hand, you get all of these "hard to emulate" features for free but end up sacrificing performance if not done with speed in mind.

The disadvantage of our existing software renderer is that its performance is anything but optimal. Most games barely run any slower than 1 FPS. That's because the code was written with compatibility in mind, sacrificing performance over accuracy whenever it was necessary. However, benchmarks show that it very much is possible for software renderers to run games at acceptable frame rates (pay attention to the display resolution of these benchmarks - 1920x1080 is huge compared to the Wii's rendering resolution of 640x528!).

So the idea of this project is to enhance (or replace) the currently quite well-functioning software renderer with "fast" code paths. How exactly these "fast" code paths are implemented is free to the student. Some approaches include, but aren't limited to:
 * using SSE wherever possible (the other backends already have an SSE texture decoder)
 * vectorizing the renderer pipeline
 * making use of GPU accelerationg where feasible and possible without sacrificing accuracy, possibly making use of modern GPU features like compute shaders and transform feedback. Keep in mind this stuff should be cross-platform compatible though and we don't want to end up with "sub-backends", i.e. this is tied to using OpenGL.
 * Just-in-Time recompilation of software renderer code paths, using LLVM (if it's suited for the task) or a tailor-made JIT
 * Alternatively a new software renderer based on Gallium3D's llvmpipe might be an interesting idea

Possible mentors: no_cluez

More Accurate DSP HLE Emulation
Dolphin has two ways to emulate the Gamecube/Wii DSP: LLE (emulating a DSP program instruction by instruction as accurately as possible, requiring a lot of CPU power) and HLE (rewriting the DSP program behavior in C++, which isn't as accurate and requires a fair bit of reverse engineering but is a lot faster).

Historically the DSP HLE backend was in a very sad state: lot of bugs and non implemented features, behavior which did not make sense and did not match what the DSP program should be doing, etc. delroth has been working since November 2012 on a new DSP HLE implementation for the Gamecube AX DSP program, which makes things a lot better for games relying on that particular DSP program.

The same work could be done for the two remanining DSP programs in use: Wii AX and Zelda/IPL UCodes. This will require some reverse engineering (both PowerPC and DSP assembly) to understand how these two programs communicate with the main CPU and what they should do exactly to mix data in the same way the real hardware does it. Ideally some documentation should be written explaining how these UCodes work as well.

Possible mentors: delroth