Associate
- Joined
- 1 Oct 2009
- Posts
- 1,033
- Location
- Norwich, UK
Just to follow up what I've read on Wolf 2 is that people are saying that to get "8k textures" you set "is_poolSize" in the config file, this is not texture resolution! It's the memory pool size in MB that the game will use to stream textures. I assumed when people say 8k and 16k textures that they literally mean the resolution of the textures themselves and was expecting a 300Gb texture pack or soemthing like that, but that's not what people are referring to? Not as far as I can see from the guides that are still active/online.
If that's what you changed to get "16k textures" to presumably a value of 16,384 then all you're doing is telling the engine to specifically reserve this much vRAM for texture streaming. It doesn't increase texture quality directly by increasing the resolution of the textures use but rather increases the memory pool size so the game has more space in vRAM to stream in the textures. The game uses texture streaming which means in certain areas the lower quality textures are painted initially onto surfaces and are then replaced by higher quality copies typically as you get near them, and the engine streams in/out of memory what it needs as you move through the level.
This is what I have referred to in the past with regards to change in paradigm for gaming and vRAM use. To basically get past the limitations of vRAM and start making games that have assets on disk which exceed vRAM one of the techniques is streaming assets in and out of the level. If you manually set the pool used to do that then the game will report that much being used. So...there's a couple of implications for this.
1) You're setting a game engine explicitly to use a memory pool of 16Gb and then saying hey the game uses 16Gb, 8Gb is no longer enough, TA-DAH! OK well I'll set it to use 32Gb and then 16Gb isn't enough, or 64 or 128 or get this hot take, any value we like then no amount of memory is enough. So that line of reasoning is just kinda dumb for obvious reasons.
2) We don't actually know what of that pool the game is actually using. MSI Afterburner will tell us the memory allocated to the game and then it will speculate about what the game really uses, but the way memory management is handled by the game engine will likely mean that when it sets up the texture pool it will count as that memory being "used" by the process and so it would appear to even Afterburner that the per process usage is 16Gb, or whatever you've set it too. You'd need game internal engine metrics which gives you greater insight into details of what that memory pool is doing specifically, what textures does it have inside it at any one time, what's the total actual use.
3) Even if the pool is genuinely filling up with the higher resolution textures when you set it to be bigger, it's likely not altering what is being displayed on screen when it's getting to 10Gb+ of usage. Typically with pools of memory like that you have rules for what goes into them (X texture is needed on an object coming into view, stream it in) and what comes out of the pool (we don't have enough room for this new X texture, is there any off screen textures we can safely remove from the pool?) And so by setting oversized pools manually you're just giving it more room to store old unnecessary textures, the whole point of the pool having a limited size in the first place is to keep vRAM requirements down while maintaining the same quality on screen. You don't want that pool being any bigger than it has to be otherwise you're just keeping around old assets you no longer need.
If that's what you changed to get "16k textures" to presumably a value of 16,384 then all you're doing is telling the engine to specifically reserve this much vRAM for texture streaming. It doesn't increase texture quality directly by increasing the resolution of the textures use but rather increases the memory pool size so the game has more space in vRAM to stream in the textures. The game uses texture streaming which means in certain areas the lower quality textures are painted initially onto surfaces and are then replaced by higher quality copies typically as you get near them, and the engine streams in/out of memory what it needs as you move through the level.
This is what I have referred to in the past with regards to change in paradigm for gaming and vRAM use. To basically get past the limitations of vRAM and start making games that have assets on disk which exceed vRAM one of the techniques is streaming assets in and out of the level. If you manually set the pool used to do that then the game will report that much being used. So...there's a couple of implications for this.
1) You're setting a game engine explicitly to use a memory pool of 16Gb and then saying hey the game uses 16Gb, 8Gb is no longer enough, TA-DAH! OK well I'll set it to use 32Gb and then 16Gb isn't enough, or 64 or 128 or get this hot take, any value we like then no amount of memory is enough. So that line of reasoning is just kinda dumb for obvious reasons.
2) We don't actually know what of that pool the game is actually using. MSI Afterburner will tell us the memory allocated to the game and then it will speculate about what the game really uses, but the way memory management is handled by the game engine will likely mean that when it sets up the texture pool it will count as that memory being "used" by the process and so it would appear to even Afterburner that the per process usage is 16Gb, or whatever you've set it too. You'd need game internal engine metrics which gives you greater insight into details of what that memory pool is doing specifically, what textures does it have inside it at any one time, what's the total actual use.
3) Even if the pool is genuinely filling up with the higher resolution textures when you set it to be bigger, it's likely not altering what is being displayed on screen when it's getting to 10Gb+ of usage. Typically with pools of memory like that you have rules for what goes into them (X texture is needed on an object coming into view, stream it in) and what comes out of the pool (we don't have enough room for this new X texture, is there any off screen textures we can safely remove from the pool?) And so by setting oversized pools manually you're just giving it more room to store old unnecessary textures, the whole point of the pool having a limited size in the first place is to keep vRAM requirements down while maintaining the same quality on screen. You don't want that pool being any bigger than it has to be otherwise you're just keeping around old assets you no longer need.
