Asynchronous decompression of compressed formats

[Anuskuss]

Now that PCSX2 is getting more and more accurate with disc timings and compressed formats like CSO and CHD getting increasingly popular, it would be unwise not to (further) improve the decompression performance to avoid any stutters/glitches.

We currently support using the OS's async IO for reading isos, but don't have anything in place for decompressing on a separate thread

[rtissera]

Regarding CHD I am considering implementing in https://github.com/rtissera/libchdr read-ahead decompression in a separate thread which could be enabled or not a compile-time, in order to minimize any stutter / latency.

[avih]

read-ahead decompression

This might work well, or might make things worse, depending on the disc access pattern of the game.

For instance, Shadow of the Colossus (I don't recall if the EU or US version) reads just all over the place, and constantly seem to be seeking to random locations at the DVD (I analyzed many games when I added the gzip support). At such case, readahead is very likely to make things worse.

Also, consider that seeks are very slow with physical DVD, and games know this and access the disk accordingly. I think the async file reader API can already do exactly what the game expects, so as long as you implement the async API actually async, I think you should be good.

[TellowKrinkle]

Also, consider that seeks are very slow with physical DVD, and games know this and access the disk accordingly. I think the async file reader API can already do exactly what the game expects, so as long as you implement the async API actually async, I think you should be good.

It looks like we're having no trouble keeping up with large seeks, but end up negative on smaller seeks (ReadAsync blocks are the time it took the EE thread gave between requesting a read and requesting its completion, the little marks above are points where the decompression thread finished a read (so if it's inside of the block, it finished in time, otherwise it made the EE thread wait), I marked the blocks with the size of the seek they were doing)

(This is with 1MB LZMA blocks)

Edit: Forgot to turn the frame limiter back on. Not going to relabel but here's the same spot with the frame limiter on, we make a lot more of the reads in time now

[avih]

we make a lot more of the reads in time now

For the game which you tested.

As I mentioned, disk access pattern changes a LOT between games, and the only way to assess the change in general is to repeat this test with a LOT of games, and examine the overall results.

[TellowKrinkle]

For the game which you tested.

If we finish the read + readahead it in the amount of time PCSX2 gives for an emulated seek (we don't in the above case but probably would with ~half the block size), I don't see how a game's seek pattern could break it