doitsujin
Initialize heap budget
Currently the heap budget is 0 at startup and it never receives a non-zero value.
Hm, I think the correct fix here is to remove the budget-related code. We really don't want to change memory allocation behaviour without exhaustively testing the change in a large number of games on a very large number of different setups.
IIRC the intention here was to have a hard upper limit for Nvidia HVV allocations since there used to be all sorts of bugs with it, but we definitely don't want to enforce this based on some arbitrary number that can change dynamically, this is just goint to lead to weird performance issues on drivers that can mange overallocation on their own and cause crashes if we get weird data from the driver.
Hm, I think the correct fix here is to remove the budget-related code.
Please don't. Indeed the ultimate intention is to prevent bad-behaving ("over-specifying") code from encroaching on other apps when VRAM is limited. It is specifically because of this bad behavior that this was investigated. If app stability is a problem, can that not be up to the user to decide? My admittedly limited testing has been on AMD only and this has worked flawlessly.
If FPS is the only concern, allowing allocs to end up using sysram should be up to the user. If they can deal with the FPS hit, so be it. It's a success if the overall system doesn't suffer too.
The few apps I've looked at all treat the DXGI limits as guidelines but do cut back their usage even though they do continue to over-specify.
IIRC the intention here was to have a hard upper limit for Nvidia HVV allocations since there used to be all sorts of bugs with it,
I totally get your point here (and am somehow not surprised). Might future NVK be better behaved? As far as I've been able to see thus far, "upper limit" right now is just system max.
don't want to enforce this based on some arbitrary number that can change dynamically
These heap sizes don't appear to be changing dynamically?? As far as device heap goes, when RADV is driving, the budget stays fixed at max available unless altered by override_vram_size. Neither heap type seems to change during runtime.
The single budget check in that cpp file currently returns an empty allocation if budget is exceeded. I've assumed this is equivalent to what would be returned in an actual hard VRAM exhaustion situation (if budget != 0, obviously). But even if it's not, apps gracefully deal with this all the time, no? Regardless of their bad behavior? So is the problem actually in what's being returned?
I totally get your point here (and am somehow not surprised). Might future NVK be better behaved? As far as I've been able to see thus far, "upper limit" right now is just system max.
What I mean is that there used to be a workaround which set the budget for HVV heaps on Nvidia to 32MB or something. We've since removed that code since it got fixed in the driver, but didn't remove the budget checks.
It is specifically because of this bad behavior that this was investigated.
So what exactly is the problem you're trying to solve?
DXVK is already bad in games that over-allocate VRAM since we do not implement any sort of dynamic relocation, and due to design issues it's basically impossible for us to do so. Enforcing a hard limit here isn't going to make things better, it's going to make it worse.
So what exactly is the problem you're trying to solve?
Correcting what looks to be incomplete code, which makes sense given your explanation for an NV workaround that isn't needed anymore.
End goal? Enforce a per-app hard VRAM limit. As written now, this works very very well on my admittedly limited batch of tests with RADV.
If the app requirements necessitate bleeding into system ram, so be it. FPS and app stability is up to the user. If this works for a given app, great. If not, the user has to deal with the consequences of letting DXVK+app run amok.
DXVK taking a bite of the VRAM budget is merely 'taxes' associated with running Windows apps in Linux.
Ah, I see what's happening now. DXVK never rejects alloc requests by the app, correct?
Well, for what it's worth, modern high end systems are still perfectly usable when RAM starts being used. I drop into the 30 FPS range at the worst. That's even the case when forcing absurdly low restrictions (e.g. 4gig for a game that usually wants 10+) which sends a great many allocs to RAM.
The ultimate point here is that DXVK is ignoring the GPU driver.
Mid/low systems are already suffering with games that over-specify. This will at least protect the entire system GUI from lagging because of it.