1631949 - Investigate merging shader cache files

Status: ASSIGNED

(Core :: Graphics, enhancement, P3)

Description

[Emma Malysz]

During startup, we read a few different files within the shader-cache directory. These reads happen at various points throughout startup, so we should consider storing them in one file.

Comment 1

[Emma Malysz]

Loading the attached zip into https://procmon-analyze.github.io, we read shader-cache files 8 times and are not reading too much data (~0.03 mb), so they seem to be a good candidate for merging into one file.

Comment 2

[Emma Malysz]

Attachment: ff_startup.zip

Comment 3

[Alex Thayer [:alexical] (she/her)]

To expand on this: in the profile, we spend about 350ms reading only 350kb off disk. The files are rather spread out physically across the disk in the profile, so I suspect this could be made much faster.

Comment 4

[Kris Taeleman (:ktaeleman)]

Hey Emma,

On what platforms are we seeing this and what platforms do we think will benefit?
I'm assuming this is with Webrender, but can you confirm this?

Thanks!

Comment 5

[Emma Malysz]

Hey Kris! This is related to startup IO on reference hardware for Windows. We're trying to see if we can improve startup performance by reading this sequentially off the disk.

Comment 6

[Alex Thayer [:alexical] (she/her)]

Also, we're seeing it on Windows, but I suspect it's not different on any other OS. More important is that it's on a machine with an HDD - I don't think this would present itself on SSDs.

Further, to provide a concrete plan here, I think we could safely include all of the shader binaries for every entry in the shader startup list here. Into the startup_shaders file we'd write the list of the digests as we currently do, followed by the length of their binary. We then just concat the binaries + hashes for all of them and write that out. try_load_shader_from_disk would just become something like try_load_shader_from_bytes, and deserialize_program_binary would just take a byte buffer.

We'd likely want to try to ensure we only write the file if its contents have changed, which shouldn't be too hard. I don't imagine the contents would change frequently? Unless a particular shader is on the edge of being included in the startup list due to timings, which would be a problem we should fix independently.

Comment 7

[Jamie Nicol [:jnicol]]

On desktop the list of startup shaders probably won't change frequently, as it will likely just be the browser chrome. On android however, it will change quite a lot. Basically just depends on the first page that the user opens.

I'd be open to potentially changing the heuristic on android, because I'm not sure using "shaders from the first 10 frames of the last app run" necessarily makes as much sense as it does on desktop. Maybe a hardcoded list would be better.

Comment 8

[Alex Thayer [:alexical] (she/her)]

This optimization also likely wouldn't matter as much on android, as it wouldn't be reading from a spinny disk. However not having significantly different code paths would be preferable.

Comment 9

[Bernard Igiri]

Marking as P2 since this is a startup performance bug.