>>861236>why doesn't it first go into dedicated video memory>assuming there is spaceYou've hit upon the problem. There won't be space. Games use literally assloads of data nowadays, far more than is reasonable to keep unallocated "just in case". If the GPU says "sod off I'm full", the game just puts the texture in main memory and swaps it into the GPU.
Say your 8GB computer mainly does two things: play a game that has 4GB of assets, and sit on the desktop where Aero allocates 0.25GB of surfaces for the windows it's compositing. This means if you have to choose a static allocation, it will always be wrong for one of them:
>you choose 0.25GBOn the desktop, you have 7.75GB for your programs [x] Good!
Playing the game, you have 0.25GB of assets "in the GPU" and 3.75GB of assets inside the game, and the game is constantly thrashing assets around [!] Bad!
>you choose 4GBPlaying the game, you have 4GB of assets "in the GPU" and no thrashing [x] Good!
On the desktop you have 4GB for your programs and 3.75GB sitting there doing nothing [!] Bad!
>you have a modern onboard with dynamic allocationPlaying the game, you have 4GB of assets "in the GPU" and no thrashing [x] Good!
On the desktop, you have 7.75GB for your programs [x] Good!
Bonus scenario: you have a game that sometimes needs a load of assets, and sometimes needs a load of CPU memory, perhaps a turn-based strategy game that's sometimes panning around the map and sometimes calculating the AI's moves:
>you choose 0.25GBThrashing during the player's turn
>you choose 4GBThrashing during the AI's turn
>you have a modern onboard with dynamic allocationNo thrashing because GPU memory grows and shrinks as needed. The game does need to be aware of the OS telling it it wants more memory, but this has been around for years because most are