Open Bug 1631949 Opened 2 years ago Updated 2 years ago

Investigate merging shader cache files

Categories

(Core :: Graphics, enhancement, P3)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: emmamalysz, Assigned: dthayer)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [fxperf:p2])

Attachments

(1 file)

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.

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.

Blocks: 1627071
Whiteboard: [fxperf]
Attached file ff_startup.zip
See Also: → 1631927

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.

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!

Blocks: wr-perf
Severity: -- → normal
Flags: needinfo?(emalysz)
Priority: -- → P3

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.

Flags: needinfo?(emalysz)

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.

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.

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.

Marking as P2 since this is a startup performance bug.

Whiteboard: [fxperf] → [fxperf:p2]
Assignee: nobody → dothayer
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.