Difference between revisions of "PCSX2 Documentation/GSdx Debug"

From PCSX2 Wiki
Jump to navigation Jump to search
Line 8: Line 8:
  
 
=== GSdump overview ===
 
=== GSdump overview ===
  what is a gsdump / why it is useful
+
You can represent the emotion engine (CPU) and the graphics synthesiser (GPU) as 2 separates black-boxed blocks linked together with an unique channel. GSdump is a recording of all communications + an initial GS reset state (AKA GS save state).
 +
 
 +
Round 1: recording
 +
------        ------
 +
| EE |  <=> | GS |
 +
------    v  ------
 +
          |
 +
          v
 +
        GSdump record
 +
 
 +
Round 2: replaying
 +
        ------
 +
    >  | GS |
 +
    ^  ------
 +
    |
 +
    ^
 +
GSdump data
 +
 
 +
 
 +
The EE/GS state depends on the user input (from the keyboard/pad). It is quite difficult to replay the same scene, angle of the 3d scene could be different. Some lighting effects could be also different. The GSdump saves a couple of frames to allow constant replay. This way you can compare renderer precisely. For example you can check that pixel (32, 456) of draw call 45 is exactly the same colour. If the value is slightly different it is likely a rounding bug. If the value is completely different, it is a bug.
 +
 
 +
As GSdump only record the communication, you can change all GSdx options during the replay. You can test a new hack, a new renderer, new resolution etc...
 +
 
 +
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.
  
 
=== How to generate a GSdump ===
 
=== How to generate a GSdump ===

Revision as of 15:03, 4 October 2017

Introduction

The goal of this page is to describe the GSdx debug capabilities and to explain how to use them efficiently. After this tutorial, you should be able to

  • generate a small reproducible testcase
  • reproduce the bug
  • understand what happen under the hood

Requirement: understand the standard GPU rendering pipeline

GSdump overview

You can represent the emotion engine (CPU) and the graphics synthesiser (GPU) as 2 separates black-boxed blocks linked together with an unique channel. GSdump is a recording of all communications + an initial GS reset state (AKA GS save state).

Round 1: recording


------

| EE | <=> | GS |


v ------

         |
         v
       GSdump record

Round 2: replaying

       ------
    >  | GS |
   ^   ------
   |
   ^
GSdump data


The EE/GS state depends on the user input (from the keyboard/pad). It is quite difficult to replay the same scene, angle of the 3d scene could be different. Some lighting effects could be also different. The GSdump saves a couple of frames to allow constant replay. This way you can compare renderer precisely. For example you can check that pixel (32, 456) of draw call 45 is exactly the same colour. If the value is slightly different it is likely a rounding bug. If the value is completely different, it is a bug.

As GSdump only record the communication, you can change all GSdx options during the replay. You can test a new hack, a new renderer, new resolution etc...

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.

How to generate a GSdump

How to replay GSdump

Advance debug capabilities

=> gs register state dump => gs texture/buffer dump => OpenGL trace