GSRunner: Batch mode and regression test mode

[TJnotJT]

Description

This PR introduces batch GS running and in-memory comparison to speed up GS regression testing. This is still a WIP — some features are incomplete or not fully tested. The PR is on the larger side — feedback and discussion on design choices are welcome.

Adds the following:

1. Batch mode for GS runner: Runs multiple dumps sequentially within a single PCSX2 instance. Buffers upcoming dumps to reduce I/O overhead.
2. In-memory regression testing: Runs three GS runner instances. Two instances run dumps and upload frames to shared memory, while a third compares frames and saves only those that differ.

Current status:

1. Batch runner: nearly complete and ready for testing.
2. In-memory regression testing: working on Windows; needs porting for non-Windows platforms.
3. Other small todos: cleaning up code, adding help for new args, etc.

Currently, this build only compiles with MSVC.

Rationale

1. The batch runner improves dump run times by avoiding repeated PCSX2 creation and buffering dumps in advance.
2. In-memory regression testing reduces I/O overhead further. This is helpful when testing multiple renderers or settings. For single-renderer runs, using precomputed baselines may still be faster.

Other notes

• Converting .xz dumps to .zst can improve decompression speed by 2–3x, though file size increases by a similar amount.

Testing steps (batch mode alternative)

• Running dumps and comparing results to master would be helpful (with non-DX12 renderers; see issues below).
• Frame outputs and statistics should match master except for the known issues below.
• You should also see a noticeable reduction in total dump run time.

Example usage (executable):

pcsx2-gsrunnerx64.exe \
    batch \
    -input <path to gs dumps> \
    -output <path to output> \
    -logfile <path to output> \
    -renderer vulkan \
    -nthreads 2 \
    -loop 2 \
    -batch-gs-fast-reopen

• In batch mode, -logfile should point to the directory where logs are saved (use the same directory as -dumpdir for behavior consistent with master).

Testing steps (batch mode)

• Running dumps and comparing results to master would be helpful (with non-DX12 renderers; see issues below).
• Frame outputs and statistics should match master except for the known issues below.
• You should also see a noticeable reduction in total dump run time.

Example usage (Python script):

python pcsx2-gsrunner/test_run_dumps_2.py \
    -runner <path to gsrunner> \
    -gsdir <path to dumps> \
    -dumpdir <path to output> \
    -renderer vulkan \
    -upscale 1 \
    -parallel 2 \
    -gsfastreopen &

Use this to compare with the results from running test_run_dumps.py in master.

Example usage (executable):

pcsx2-gsrunnerx64.exe <path to dumps> -batch -nbatches 2 -batch-id 0 \
    -surfaceless -loop 2 -logfile <output path> -dumpdir <output path> \
    -renderer vulkan -noshadercache -batch-gs-fast-reopen &

pcsx2-gsrunnerx64.exe <path to dumps> -batch -nbatches 2 -batch-id 1 \
    -surfaceless -loop 2 -logfile <output path> -dumpdir <output path> \
    -renderer vulkan -noshadercache -batch-gs-fast-reopen &

• Run each instance separately with a unique -batch-id to execute them in parallel.
• In batch mode, -logfile should point to the directory where logs are saved (use the same directory as -dumpdir for behavior consistent with master).

Testing steps (regression testing mode)

• Same goals as running batch mode.
• It will be easiest to just run the same executable against itself, since otherwise it would require rebasing this PR on top of another branch and compiling. This won't be a representative comparison, but it should be ok for testing.

Example usage (Python script):

python pcsx2-gsrunner/test_run_dumps_in_memory.py \
    -tester <path to runner executable> \
    -runner1 <path to runner executable> \
    -runner2 <path to runner executable> \
    -gsdir <path to dumps> \
    -dumpdir <path to output> \
    -renderer dx11 \
    -gsfastreopen \
    -parallel 1

Example usage (executable):

pcsx2-gsrunnerx64.exe tester \
    -path <path to executable 1> <path to executable 2>
    -input <path to dumps> \
    -output <path to output> \
    -renderer dx11 \
    -nthreads 1 \
    -loop 2 \
    -log  \
    -batch-gs-fast-reopen

• Currently, -input and -output correspond to -gsdir and -dumpdir, resepectively, though I will eventually change it for consistency.

Known issues

• In some dumps, newly created textures may contain leftover data from previous dumps and affect final frames. One case was due to an unrelated bug with valid-area computation. A possible fix could be to allow clearing new source textures with a setting.
• DX12: Hangs after a few hundred dumps due to a resource leak (under investigation).
• Stats: The Texture Uploads stat can vary by 1–2 due to nondeterminism (affects both PR and master).

AI assistance

Reviewing code, approaches for threading, referencing system- or API-specific details, and drafting this description.