Google Summer of Code

About GSoC

Google Summer of Code

Suggested Projects

This page is from 2013 and most of the project proposals are outdated. If you would like to mentor or become a GSoC student, please ask on IRC first.

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.

If you'd like to participate in this year's GSoC and want to propose an idea, please create a new wiki page from the GSoC_Student_Application_Template, first.

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.

Possible mentors: delroth, skidau

Isolate Core Code better from GUI and add a XBMC/Qt Frontend

This is pretty much self-explanatory. There is something like a frontend interface but it's really poorly designed. Ideally it should be possible to compile a standalone libdolphin library which the different frontends can be linked against. This would make integration into other frontends much easier. As a demonstration for the new interface, one would write a new Dolphin GUI from scratch. Some end users have shown interest in running Dolphin inside XBMC, while some developers would like to replace the existing wxWidgets GUI with one based on Qt.

Possible mentors: delroth, skidau

Proper GPU Synchronization

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.

Possible mentors: skidau

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 1FPS. 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, delroth (more for perf optimization than GFX...)

More Flexible GPU Debugger

The existing graphics debugging tools available in Dolphin are a bit limited - there's FifoPlayer and an unstable GPU debugger. It's still quite hard to really get an idea what a game might be doing without manually hacking debugging statements into Dolphin's source code. There's also no simple way to reproduce any specific series of GPU command on the real console without writing a testing homebrew application from scratch.

The main idea behind this project would be to write new, better integrated GPU debugging tools for Dolphin. Some ideas on how to do this include, but aren't limited to:

• rewriting FifoPlayer as a Wii homebrew application. That way arbitrary GPU command streams could be recorded from games and played back arbitrarily often on the console (with additional debugging capabilities).
• adding interfaces to the VideoCommon code so that e.g. the TextureCache state can be examined from a debugging GUI. Some way to manually poke GPU registers would be cool, too.
• improving the existing GPU thread flow control. Currently there are some debugging calls in place which allow pausing the GPU thread when certain events happen (e.g. texture change or pipeline flushes), but they are really unstable and usually crash the emulator unless used carefully.

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