GPU: Track buffer migrations and flush source on incomplete copy

[riperiperi]

Makes sure that the modified range list is always from the latest iteration of the buffer, and flushes earlier iterations of a buffer if the data has not been migrated yet.

Before, flushes on migrated buffers could flush uninitialized data, as it would assume that a sync number for a previous write had been reached, but the copy to migrate the buffer data had not yet been reached. The flush's change to the modified range could also be lost when switching, as the change would be applied to the dead buffer.

Buffers now have a reference count to keep their data alive. When a migration is performed (with modified ranges), then it takes a reference to the source buffer and gets added to a list on _context. When any sync is created, we check the current reached sync number and pending migrations to see if any can be removed. If they can,

Upsides:

• Avoids this cause of buffer data loss. Downsides:
• Buffers with modifications are kept alive after migrations until the next sync number is reached. This could cause increased memory spikes when resizing often.
  • Buffers without modifications don't have any issues. Maybe this could be improved by force flushing buffer data where the sync number has been reached, but I'm not sure about the performance implications (on opengl this isn't as free, when vulkan is choosing buffer memory types we don't want our cleanup to influence that either).
• Can't reuse BufferModifiedRangeList when migrating, as we need to track old states for flush.

This fixes most cases of vertex explosions in Pokemon Scarlet/Violet. On master without vsync, going through Mesagoza to the school, then to the east loading zone caused the main character to explode and never recover very consistently. It took hours of running around with vsync off to get an explosion with these changes, and it was on NPCs, and they recovered when they were reloaded. There may be some other issue with buffer flush that might be causing these.

[github-actions[bot]]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+560b501-linux_x64
• ryujinx-Release-1.1.0+560b501-osx_x64
• ryujinx-Release-1.1.0+560b501-win_x64

Experimental GUI (Avalonia)

• ava-ryujinx-Release-1.1.0+560b501-linux_x64
• ava-ryujinx-Release-1.1.0+560b501-osx_x64
• ava-ryujinx-Release-1.1.0+560b501-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+560b501-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+560b501-osx_x64
• sdl2-ryujinx-headless-Release-1.1.0+560b501-win_x64

Only for Developers

• ava-ryujinx-Debug-1.1.0+560b501-linux_x64
• ava-ryujinx-Debug-1.1.0+560b501-osx_x64
• ava-ryujinx-Debug-1.1.0+560b501-win_x64
• ryujinx-Debug-1.1.0+560b501-linux_x64
• ryujinx-Debug-1.1.0+560b501-osx_x64
• ryujinx-Debug-1.1.0+560b501-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+560b501-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+560b501-osx_x64
• sdl2-ryujinx-headless-Debug-1.1.0+560b501-win_x64

[MetrosexualGarbodor]

After several hours of testing and multiple reports from others, it seems this PR might fix Xenoblade 3 vertex explosions and device loss crashes on Vulkan, but ONLY if the shader cache is purged beforehand. These bugs are random though, so further testing is required; we might just be getting lucky.