google / google/gapid

Massive performance degradation for some MEC + Android ODR replays

Open
#2,340 0 comments 0 reactions 0 assignees View on GitHub
GAPIR P1 performance triaged
Dominant language
Go
Stars
2.2k
Forks
329
PR merge metrics
No merged PRs in 30d

Description

Attempting to replay a relatively simple trace, using MEC and ODR (both defaults), does not finish within 30mins, however the non-MEC and/or host replay will finish within tens of seconds. After a bit of poking around, it seems like we're spilling the GAPIR in-memory resource cache (Android still doesn't have the disk cache enabled), and ends up synchronously requesting resources from GAPIS one after the other.

Given that doesn't appear to happen with a non-MEC trace, I'm assuming the decompression of block compressed textures is massively expanding the amount of data that needs to be pushed to the device, and exceeds the cache size.

There's two things that we could do to help here:
1. Attempting to recompress the uncompressed textures back to their block-compressed forms.
2. Batch fetching resources once the cache has spilled instead of requesting them single file.

(1) Has a number of issues that have already been discussed in our team meetings, which I'm not going to repeat here.
(2) Could potentially be done by adding resource usage interval information into the replay payload. For example, if each resource entry contained the opcode index of first and last use, then GAPIR could be smarter in bulk fetching of resources based on the current opcode being executed, as it will know what resources will needed in the near future, as well as what resources are no longer needed and can be discarded from the cache.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.