45
edits
 |
Progress Continues
We've already had 21639 updates since Dolphin 5.0. Keep up with Dolphin's continuing progress through the Dolphin Blog: February, March, and April 2024 Dolphin Progress Report. |
 |
The Dolphin Emulator Wiki needs your help! Dolphin can play thousands of games, and changes are happening all the time. Help us keep up! Join in and help us make this the best resource for Dolphin. |
Google Summer of Code: Difference between revisions
Jump to navigation
Jump to search
Added GPU debugger as project, wrote description for Core/GUI isolation
mNo edit summary |
(Added GPU debugger as project, wrote description for Core/GUI isolation) |
||
| Line 15: | Line 15: | ||
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. | 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 | == 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 devs would like to replace the existing wxWidgets GUI with one based on Qt. | |||
== Proper GPU | == 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. | 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. | ||
| Line 37: | Line 37: | ||
* Just-in-Time recompilation of software renderer code paths, using LLVM (if it's suited for the task) or a tailor-made JIT | * 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 | * Alternatively a new software renderer based on Gallium3D's llvmpipe might be an interesting idea | ||
Possible mentors: [[User:No_cluez|no_cluez]] | |||
== 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: [[User:No_cluez|no_cluez]] | Possible mentors: [[User:No_cluez|no_cluez]] | ||