Update budget by OS budget change events.

[bbernhar]

Instead of polling for latest usage, OS event based updates are used by default. #319

[bbernhar]

@bjjones can you PTAL?

[bjjones]

LGTM. Did you plan to add functionality for paging based off of budget changes? Seems like it would make this feature more useful.

[bbernhar]

Did you plan to add functionality for paging based off of budget changes?

Could you elaborate on this more?

If I call Evict on a background thread, wouldn't that be nearly equivelent to checking then calling Evict upon ExecuteCommandLists? In both cases, Evict is called the same number of times. But I do see an opprotunity to unblock the main thread, when Evict is called, but only if nothing else uses the device (or it will block again).

In contrast, QueryVideoMemoryInfo gets called per ExecuteCommandLists, not per paging, so moving it away from the main thread holds more beneifit since it saves CPU cycles when under budget.

However, it does seem like a good idea to have async Evict since real world apps may keep busy enough to hide this latency.

[bjjones]

Could you elaborate on this more?

I was thinking in the case that you had maxed out the budget and a significant budget change occurred (which can happen when changing focus to a different window) your memory residency would not be in the optimal state and wouldn't be fixed until the next ExecuteCommandLists call. Maybe this isn't impactful in reality - since ExecuteCommandLists is usually called at a granularity that would hide dropped frames - but could there be an ML/AI scenario that doesn't call so frequently? Note that it could not just be for page out, but could be for page in too if you were switching your residency-managed app back to the foreground causing a big budget increase.

I know Evict is very fast already so I don't know that there's really much value offloading it.

[bbernhar]

@bjjones We can't page-in heaps outside of ExecuteCommandList (ignoring resource creation), the budget change event could only evict older heaps. Since Evict() makes no guarentee heaps will be paged out sooner rather then later (speeding up the subsequent MakeResident), the benefit isn't obvious but I captured this potential optimization as #478.