Allow me to share a story of the worst thing in D3D12: Handling VRAM exhaustion.

[pixelcluster@mastodon.gamedev.place]

@EricLasota Well, as long as the total memory usage is below physical memory size, there is nothing to evict in any case.

On the problem of apps not recovering from persistent evictions, there's just not much that apps can do here. As long as there is memory contention, the kernel may have to evict "random" memory at "random" times. For every form of notification the kernel may provide, there is a case where apps acting on that notification does nothing at best and is harmful at worst.

[pixelcluster@mastodon.gamedev.place]

@EricLasota The best you can probably do is give the kernel as much info as possible about which pieces of memory have the least bad effect when evicted (i.e. memory priorities), because the kernel is in a position to actually make meaningful decisions on what to evict.

Of course that doesn't replace app-side freeing of resources on memory contention, but I'm doubtful a kernel-side notif would be less racy/broken than e.g. detecting memory contention based on sampling total mem usage.

[dotstdy@mastodon.social]

@pixelcluster @EricLasota I think one big issue is that while the kernel is the only one which can decide what to evict sensibly, there's no such thing as "less important memory" from the application point of view. The entire dynamic texture pool is often trivially evictable by the application, but if the OS demotes that memory the application is going to tank performance. Would almost rather some kind of VM_DROPPABLE for that kind of memory, where the app is trivially able to deal with eviction

[dotstdy@mastodon.social]

@pixelcluster @EricLasota it works well in other cases where you oversubscribe, though. E.g. if you have a level editor and you want to preferentially demote (without freeing) all the editor side GPU allocations when you enter "game mode".

[ericlasota@mastodon.gamedev.place]

@pixelcluster What I mean is if the kernel decides on per-process budgets that total less than the physical memory, then it can guarantee that only over-budget processes will get evicted, and that if it has to evict an under-budget one anyway, that it will always update the budgets when it does.

[ericlasota@mastodon.gamedev.place]

@pixelcluster The problem with sampling total memory usage is that the applications don't talk to each other.

If one program is hogging all of the VRAM and another wants more than what's available, then there are really two options: Fail allocations in the new program (allowing the first-comer to monopolize the VRAM), or make the first one lower its memory usage.

So, the point of having budgets is to have some way of coordinating VRAM usage reduction across multiple programs.