I, like most of the modders here, have hit all sorts of frustrating walls with Warband, where all of a sudden the mod causes crashes for end-users, yet hardly anything has changed- maybe a new suit of armor, a slightly different troop loadout. I've had to deal with lots of complaints about this topic, I've done a lot of experiments and I've done what I could to help people out.
But I've hit some limits here that are mysterious, to say the least, and I would like some answers to help all of us making mods understand why we're having problems and hopefully how to avoid them.
I've done some tests, and have found some crazy, crazy stuff is going on. Amongst other things, I finally caught the "crashes or freezes suddenly when troops load" error, and I'm almost entirely certain what it is- VRAM ran out.
Here's what I think I know, at this point:
1. If you turn off 'load textures on demand', it doesn't load the textures into RAM for use when a scene is built and actors are placed. Instead, it's putting all of the textures into VRAM. This causes a crash upon game load if the end-user doesn't have enough room, throwing a fairly mysterious-sounding error message, instead of gracefully switching off the option and loading normally.
Why can't it simply calculate how much space it needs for the textures, place them into RAM, and then move them to VRAM as needed? Why is the choice between loading from the hard drive to VRAM or loading directly to VRAM?
2. On that note... my mod + Native is less than 1GB in size, in terms of textures. It's around 750MB, and the textures are DDS, so they're supposed to stay compressed on the card. What's using up the rest of the VRAM? The vertex buffers? How does that work, in brief?
3. On the general subject of memory use... if it's loading textures into VRAM, then what is using 1GB of RAM for, while running? All of the data of the text files, combined, is less than 100MB, and most of it isn't being used for logical purposes. The Troops don't need Agent simulations unless we're in a battle, otherwise they're abstracts and should be really small pieces of data. What is using all that memory, if it's not content data?
4. In game_variables.txt, there is the following:
What do these numbers mean? Are they stored on the GPU, or are they stored in RAM? And why does changing them cause end-users to report massive stability problems?
5. Lastly, a more general question: what can we do to ensure that end-users aren't crashing constantly? What are the performance walls here?
After nearly a year of fighting with crashes, at least I finally know what is causing them. What I need to know is a bit more about how it works, so that I know what I need to change. Please give us further information about the way it's allocating memory; in particular:
A. Do we gain any benefits by cutting down item variety, in terms of the sizes of the vertex buffers?
B. Why doesn't the engine soft-fail texture loading, if it's going to exceed the currently-allocated VRAM, so that the geometry can still load and render with a default texture without resulting in a corrupted state? In short, why is it running outside of the limits in the first place? Aren't drivers reporting that number accurately?
C. Are there any tools or console commands that will allow us to get a record of the allocations and track performance?
D. When the engine leaves a combat scene, unloading the GPU also causes crashes or stability problems. What is happening there?
But I've hit some limits here that are mysterious, to say the least, and I would like some answers to help all of us making mods understand why we're having problems and hopefully how to avoid them.
I've done some tests, and have found some crazy, crazy stuff is going on. Amongst other things, I finally caught the "crashes or freezes suddenly when troops load" error, and I'm almost entirely certain what it is- VRAM ran out.
Here's what I think I know, at this point:
1. If you turn off 'load textures on demand', it doesn't load the textures into RAM for use when a scene is built and actors are placed. Instead, it's putting all of the textures into VRAM. This causes a crash upon game load if the end-user doesn't have enough room, throwing a fairly mysterious-sounding error message, instead of gracefully switching off the option and loading normally.
Why can't it simply calculate how much space it needs for the textures, place them into RAM, and then move them to VRAM as needed? Why is the choice between loading from the hard drive to VRAM or loading directly to VRAM?
2. On that note... my mod + Native is less than 1GB in size, in terms of textures. It's around 750MB, and the textures are DDS, so they're supposed to stay compressed on the card. What's using up the rest of the VRAM? The vertex buffers? How does that work, in brief?
3. On the general subject of memory use... if it's loading textures into VRAM, then what is using 1GB of RAM for, while running? All of the data of the text files, combined, is less than 100MB, and most of it isn't being used for logical purposes. The Troops don't need Agent simulations unless we're in a battle, otherwise they're abstracts and should be really small pieces of data. What is using all that memory, if it's not content data?
4. In game_variables.txt, there is the following:
# Initial Buffer_sizes
# Modders may adjust these large enough so that the game will not need to restore
# buffers during the game. However keeping them excessively large will reduce performance in most systems.
#Buffer_sizes (if smaller than 65535, this also represents the maximum vertex count for a corresponding mesh)
new_buffer_size_dx7_regular_ffp_static = 262144
new_buffer_size_dx7_regular_ffp_dynamic = 262144
new_buffer_size_regular_ffp_static = 32768
new_buffer_size_regular_ffp_dynamic = 32768
new_buffer_size_regular_static = 131072
new_buffer_size_regular_dynamic = 65536
new_buffer_size_skinning_static = 131072
new_buffer_size_skinning_dynamic = 65536
new_buffer_size_normal_map_static = 131072
new_buffer_size_normal_map_dynamic = 65536
new_buffer_size_normal_map_skinning_static = 131072
new_buffer_size_normal_map_skinning_dynamic = 65536
# Modders may adjust these large enough so that the game will not need to restore
# buffers during the game. However keeping them excessively large will reduce performance in most systems.
#Buffer_sizes (if smaller than 65535, this also represents the maximum vertex count for a corresponding mesh)
new_buffer_size_dx7_regular_ffp_static = 262144
new_buffer_size_dx7_regular_ffp_dynamic = 262144
new_buffer_size_regular_ffp_static = 32768
new_buffer_size_regular_ffp_dynamic = 32768
new_buffer_size_regular_static = 131072
new_buffer_size_regular_dynamic = 65536
new_buffer_size_skinning_static = 131072
new_buffer_size_skinning_dynamic = 65536
new_buffer_size_normal_map_static = 131072
new_buffer_size_normal_map_dynamic = 65536
new_buffer_size_normal_map_skinning_static = 131072
new_buffer_size_normal_map_skinning_dynamic = 65536
5. Lastly, a more general question: what can we do to ensure that end-users aren't crashing constantly? What are the performance walls here?
After nearly a year of fighting with crashes, at least I finally know what is causing them. What I need to know is a bit more about how it works, so that I know what I need to change. Please give us further information about the way it's allocating memory; in particular:
A. Do we gain any benefits by cutting down item variety, in terms of the sizes of the vertex buffers?
B. Why doesn't the engine soft-fail texture loading, if it's going to exceed the currently-allocated VRAM, so that the geometry can still load and render with a default texture without resulting in a corrupted state? In short, why is it running outside of the limits in the first place? Aren't drivers reporting that number accurately?
C. Are there any tools or console commands that will allow us to get a record of the allocations and track performance?
D. When the engine leaves a combat scene, unloading the GPU also causes crashes or stability problems. What is happening there?