![]() To that extent, we're adding APIs to enable apps to clear existing caches, as well as disable them to prevent new entries from being added. In addition to the ability for applications to cache their own shaders and intermediates, we've heard feedback that apps want more control over the existing caches, for profiling purposes. The next time they see it, they can look it up from the cache. the key, they would perform the specialization and cache the result. The first time the app sees a specific combination of (shader + constants), i.e. For example, an app might have an input pre-compiled shader, combined with some set of constants, which map to a specialized variation of that shader. This document outlines a new third use for this component: to enable applications to cache DXBC, DXIL, or other intermediate shader code representations, tied to some opaque key. For D3D12 applications which provide DXBC shaders, but drivers want DXIL, D3D12 will perform this conversion and cache the result.As an alternative to IHV-provided custom-built shader caches for driver shader compilations or other transient data.These caches are currently used for two purposes: And until now, transparent to applications.Integrated with disk cleanup and other OS policy.Process-local: the cache is tied to the executable that created it.This component manages caches of key/value pairs which are: In the context of mapping layers built on top of D3D12, the application-provided input must be converted into a form that D3D12 will accept, which can be very expensive.įor several years now, Windows 10 has included a component called D3DSCache, which is a DirectX Shader Cache. ![]() That means that if any patching or runtime optimizations are performed, such as constant folding, the shader must be re-validated and re-signed, which is non-trivial. D3D12 will only accept signed shaders.While we discourage apps from needlessly invoking the shader compiler at runtime, there are cases where apps may need to do some dynamic work that would benefit from caching: The expectation is that the app has compiled its shaders into bytecode during some offline step, so only that last bit is the thing that needs to be cached.Īs it turns out, this is not always the case. This process is known to be expensive, and has to be performed at runtime, because that's the only place that the driver and hardware are known. However, they've all been focused around caching driver compilations of app-provided bytecode. To date, D3D12 has had several iterations of shader caching APIs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |