Google Summer of Code: Difference between revisions

← Older edit

Google Summer of Code (view source)

Revision as of 10:57, 19 August 2015

450 bytes added , 19 August 2015

m

Text replacement - "Gamecube" to "GameCube"

Kolano

Bureaucrats, Administrators

79,225

edits

@@ Line 1: / Line 1: @@
 = About GSoC =
-http://code.google.com/intl/de/soc/
+[https://developers.google.com/open-source/soc/ Google Summer of Code]
 = Suggested Projects =
+<span style="color:#ff0000">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.</span>
 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 ==
@@ Line 10: / Line 14: @@
 == 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.
@@ Line 35: / Line 38: @@
 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, [http://www.phoronix.com/scan.php?page=article&item=mesa_91llvm_fx8350 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!).
+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, [http://www.phoronix.com/scan.php?page=article&item=mesa_91llvm_fx8350 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:
@@ Line 44: / Line 47: @@
 * Alternatively a new software renderer based on Gallium3D's llvmpipe might be an interesting idea
-Possible mentors: [[User:No_cluez|no_cluez]]
+Possible mentors: [[User:No_cluez|no_cluez]], [[User:Delroth|delroth]] (more for perf optimization than GFX...)
 == More Flexible GPU Debugger ==
@@ Line 57: / Line 60: @@
 == 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).
+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. [[User:Delroth|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.
+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. [[User:Delroth|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.