@dotstdy @EricLasota at the limit you basically end up with the console model where one “game” is allowed to run with guaranteed resources, and then any “apps” only ever get allocated enough to fit alongside a game. But that doesn’t really work on a windows PC where any number of apps might decide to be voracious consumers of RAM and VRAM (and someone will *always* complain loudly if their favorite thing doesn’t work while they’re gaming).
undefined
Matt Pettineo
@mjp@mastodon.gamedev.place
Posts
-
Allow me to share a story of the worst thing in D3D12: Handling VRAM exhaustion. -
Allow me to share a story of the worst thing in D3D12: Handling VRAM exhaustion.@dotstdy @EricLasota I believe the memory VidMM doles out has to be physically contiguous as well, which means fragmentation could also mess with your ability to give accurate budgets.
-
Allow me to share a story of the worst thing in D3D12: Handling VRAM exhaustion.@EricLasota sure, of course an accurate budget would be ideal too. But getting notified would be useful for telemetry, and to understand exactly which allocation is getting demoted.
-
Allow me to share a story of the worst thing in D3D12: Handling VRAM exhaustion.@EricLasota yeah it’s pretty terrible. The original design was that of you didn’t stay under that budget the OS would stop scheduling your command list submissions to run at all, but then it was changed to the auto demotion stuff before release. I’m guessing some wires got crossed somewhere, but it’s wild it’s been like this for 10 years now with no updates. Even a D3D API to notify you when demotion occurs would be a huge improvement.