PCSX2 Documentation/GSdx Debug: Difference between revisions
→GSdump overview: : explain gsdump limitation
(Added to guides section) |
(→GSdump overview: : explain gsdump limitation) |
||
| Line 36: | Line 36: | ||
Last but not least, GSdump avoid all the shortcoming of the core emulator. For example the core remaps segmentation fault handler which isn't supported by all debug tools. Without the core, you can easily run external tools such as Valgrind/GPU debugger/CPU debugger. | Last but not least, GSdump avoid all the shortcoming of the core emulator. For example the core remaps segmentation fault handler which isn't supported by all debug tools. Without the core, you can easily run external tools such as Valgrind/GPU debugger/CPU debugger. | ||
However there are two limitations | |||
* Bug can be present in the initial state of the GS (typically in the GS memory). For example, you can take a GSdump after a wrong upload of texture | |||
* GS replayer isn't a responder. EE can read the GS memory, do some operations and write it back to the GS memory. In normal rendering, the "write back" part will depends on the previous GS rendering. On the replayer it will be always the recorded data. For example, let's imagine you take a GSdump with the HW renderer of such situation. Hypothesis, in normal emulation, HW renderer is buggy but SW is fine. The recorded data of the dump will be bad. If you replay it with the SW renderer, you will see corrupt data. On the contrary, if you take a dump with the SW renderer in the first place, you will get good rendering during the replay even for the HW renderer. | |||
=== How to generate a GSdump === | === How to generate a GSdump === | ||