Google Summer of Code: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
No edit summary
Line 9: Line 9:
TODO: Description
TODO: Description


== Finish Qt GUI ==
== Isolate Core/GUI better and implement a Qt GUI ==
TODO: Description
TODO: Description
== Sound Stretcher ==
TODO: Description
There's http://www.surina.net/soundtouch/, but that's not a perfect solution when the framerate is not known in advance.
Probably not enough for a full GSoC (I should ask the PCSX2 devs how hard it is to implement sound stretching). Could be merged with audio HLE. [[User:Delroth|Delroth]] ([[User talk:Delroth|talk]]) 16:17, 19 December 2012 (CET)


== Proper GPU synchronisation ==
== Proper GPU synchronisation ==

Revision as of 16:17, 30 January 2013

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.

Automated Test Suite

TODO: Description

Isolate Core/GUI better and implement a Qt GUI

TODO: Description

Proper GPU synchronisation

TODO: Description

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 goal of this project is to enhance (not 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

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