This shouldnt be a problem to professional game developers, we dont allocate stuff continuous (i.e. new\delete is banned from games) you use overloaded versions which allocate off your own previous allocated heap. So as long as you dont over allocate on creating this heap you should be fine. [/quote:7fc57ec4ec]
I do understand that most (if not all) commercial game engines implement their own memory management and create their own fixed size heap at startup. Thing is that’s regular system memory and you’re pretty much guaranteed that Windows or whatever console kernel your running on will not ‘seize’ it off you after you’ve allocated it. Your OS kernel might move your memory to a page file if RAM is low or the app has been idle but at least you’ll always be able to access it- without crashing your application.
The point I’m making is that this spec from NVIDIA seems to turn that normal convention on it’s head and you now no longer have any guarantees about the memory you allocate on the GPU. The display driver is free to do what it pleases and release whatever memory it wants- bringing down your application in the process. Also, the ‘allocate a big chunk of memory’ approach would more likely make the problem worse in this case- making it harder to shuffle about blocks of memory and rearrange them to meet the needs of the bigger primary buffer size.
It probably won’t be a problem in most cases, but it’s still something to be wary of. Any potential source of instability in an application is never a welcome thing ! We have enough of them already as it is ! :P
Also its higly unlikely you will be changing resolution mid game??[/quote:7fc57ec4ec]
On consoles, no. It is never going to happen. On Windows, yes- it can always happen even if your application doesn’t give the user the option to switch modes. Task switching can be one way this can happen. Vistas lock / login screen (or whatever it’s called) can also cause a mode switch too. And other misbehaving applications can trigger it also..