Use Binary Archives as a pipeline cache on the metal backend

[expenses]

See #3716. This PR builds on-top of https://github.com/gfx-rs/metal-rs/pull/207 to add an implementation of get_pipeline_cache_data for the metal backend. This PR is not ready for reviews.

Todo:

• [x] Get rid of the Mutex around the pipeline cache and replace is_empty with an AtomicBool, as unsafe impl Sync is probably fine for the binary archive.
• [x] Check the availability of binary archives on the target with device.supports_binary_archive().
• [x] Potentially use a second cache to store SPIR-V -> MSL transformations.
• [x] Come up with a test suite to test pipeline caches. Something with hundreds/thousands of pipelines (maybe using shaders from shadertoy?) would be nice.

PR checklist:

• [x] make succeeds (on *nix)
• [x] make reftests succeeds
• [x] tested examples with the following backends: metal

[expenses]

I've added most of the features that I want for this now; what's left is a bit of a clean up, optimization as far as serialization is concerned and to merge https://github.com/gfx-rs/naga/pull/686 and https://github.com/grovesNL/spirv_cross/compare/master...expenses:serialize-feature?expand=1.

[expenses]

Paused for a little bit because I'd really like the SPV->MSL cache to be done for naga, but testing this requires naga compilation of the shadertoy shaders to work a little better. https://github.com/gfx-rs/naga/pull/693 fixes most of the issues.

[kvark]

This is also going to help gfx-portability. In particular, as we are finishing up the Naga fixes needed to get Dota2 running, we'll be benchmarking again, and having the working shader cache will boost it significantly.

[expenses]

I think this is about ready for review now. https://github.com/gfx-rs/naga/pull/716 needs to be merged and a gfx-22 tag of naga needs to be made before merging.

[expenses]

We're still parsing and validating the SPIR-V code with naga unnecessarily, as we should be able to skip over that if the SPIR-V is in the cache. Parsing and validating only seems to take about 40ms for 8000 modules though, so I don't think this is a huge problem.

[expenses]

Parsing and validating only seems to take about 40ms for 8000 modules though, so I don't think this is a huge problem.

Writing out the MSL shaders with a fresh pipeline cache also only takes 50ms for 8000 modules, so it appears that naga is fast enough that there's not too much benefit to having a SPV->MSL cache in the first place.

[expenses]

Writing out the MSL shaders with a fresh pipeline cache also only takes 50ms for 8000 modules, so it appears that naga is fast enough that there's not too much benefit to having a SPV->MSL cache in the first place.

Here are some timings for 8286 pipelines (less than the number in https://github.com/gfx-rs/gfx/issues/3716#issuecomment-816575736 because some fail to verify):

cleared spv->msl cache: 8.50 5.87 5.44 5.46 6.42
hot spv->msl cache: 5.48 4.89 4.78 4.78 4.64

[expenses]

I timed it again and having a binary archive pipeline cache definitely makes a difference when the system cache has been cleaned.

wiped system cache, with binary archive: 293.24 288.50
wiped system cache, no binary archive: 892.77 889.07

[kvark]

@expenses Naga's "gfx-22" is up, please update the PR to use it (and make sure every commit is testable).

[kvark]

@expenses can we make it so every commit is testable? If not sure, let's squash everything.

[expenses]

Okay, I'll do a squash then I think.

[expenses]

I'm trying to find a good way to do with while having the same commit message that doing a squash merge on github does. Maybe just doing it through the site would be better?