Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipeline caches on DX12 #2877

kvark opened this issue Jun 27, 2019 · 0 comments


Copy link

commented Jun 27, 2019

We have the API for pipeline caches, but the backends don't yet fully implement it. See create_graphics_pipeline signature and other use of PipelineCache.

D3D12 could store the pipeline blobs in the cache:

We'd need to be able to save/load that cache from disk, as well as properly select one (of those saved in the PipelineCache implementation) when a new pipeline is created:

This structure is intended to be filled with the data retrieved from ID3D12PipelineState::GetCachedBlob. This cached PSO contains data specific to the hardware, driver, and machine that it was retrieved from. Compilation using this data should be faster than compilation without. The rest of the data in the PSO needs to still be valid, and needs to match the cached PSO, otherwise E_INVALIDARG might be returned.

The logic of the backend, when creating a pipeline with the cache provided, would need to be the following:

  1. Lookup the given pipeline state in a HashMap<PipelineState, D3D12_CACHED_PIPELINE_STATE> owned by the pipeline cache.
  2. If there is a cached state, try to create a pipeline with it.
  3. If succeeded, that's good! No need to do anything else.
  4. If failed with D3D12_ERROR_DRIVER_VERSION_MISMATCH or D3D12_ERROR_ADAPTER_NOT_FOUND, issue a warn! message accordingly and proceed again but without using the D3D12_CACHED_PIPELINE_STATE.
  5. Obtain the new blob and store it in the pipeline cache. It may be overwriting the old value if it failed to work (due to driver/gpu/os incompatibility), which is fine.

Note: pipeline caches are internally synchronized, so any mutation of them should be done behind a sync structure, such as RwLock or Mutex. Alternatively, if you feel courageous, may try Kudzu like explained in #2860

Marking as high priority because it is requested by the Szeged team in order to speed up WebRender startup when running on DX12. cc @zakorgy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.