Join GitHub today
Eagerly clean removed image out of the texture cache. #2941
This is the first step towards improving the use of dirty rects with async blobs.
This PR adds the concept of manual and automatic eviction strategies. Automatically evicted texture cache entries correspond to what we currently do where the texture cache evicts items that haven't been request for a number of frames, while manually evicted items never get evicted until the resource cache explicitly marks them as unused with
The manual eviction policy will be needed for blob images so that we get the guarantees that what's in the cache doesn't get evicted while rasterization is happening asynchronously, which we need for dirty rects to stay valid.
Non-blob items will remain automatically evicted. This PR also makes us evict removed image keys faster for all types of texture cache entries which is good since an existing texture cache entry for a removed image key will never be used again (might as well free space up in the cache as soon we know we won't use it again).
I haven't read through this PR, but I'm a little unsure about it from the description.
One of the principles of the texture cache is that it's truly a cache, and thus it's expected that we can evict the whole thing at any time and things will "just work" correctly the next frame.
For example, if we experience memory pressure, or a device reset, we can just recreate the texture cache and everything will correctly be re-uploaded on the next frame transparently.
It sounds like these proposed changes may break that assumption? And if so, would that complicate things such as device reset etc?
Not necessarily: for memory pressures or device loss we can detect it and throw away the rendered blobs that only have a sub-rect available (that would fall back to synchronous rasterization on the next frame but look correct). That way we could still throw away manually evicted items if we want to.
If we don't have a way to maintain blobs in the cache, we can't rasterize sub-rects asynchronously, since doing so relies on the fact that the rest of the blob is in the cache and will still be there by the time we are done rasterizing.