Sugestion/bugfix (streaming related, console command)
aruametello
Join Date: 2012-11-08 Member: 168371Members
Join Date: 2012-11-08 Member: 168371Members
<div class="IPBDescription">requesting tweakable command for the size of the texture memory pool</div>This is more like a "bug report" than a suggestion, but the fix is more like a suggestion than a bugfix, then sorry if this is posted in the wrong place, i am just trying to reach the devs. (and hopefully my english is "good enough" for the explanation)
* i have moderate experience with programming realtime rendering engines, but mostly opengl, therefore i say more in a "developer suggestion" than "user suggestion". (not that this should mean much too)
the current code of the texture streaming apparently is "overshooting" the size picked for the memory pool used by the streaming textures, that is causing noticeable hitches during gameplay on my computer. (note: only when the vram usage is over 1gb)
The suggestion/bugfix: a console variable where we can tweak the size of the memory pool where the streaming memory management will work with.
Why?
Three reasons:
* first tweaking games is a very important part of "what makes proper pc games, well... pc games"
* The driver may report a wrong/undesired value. (yeah weird, but then i saw this before)
* For some people (likely very few people actually) that tweaking may help.
Longer version of the "why this may help some people"
in many cases (including vram virtualization included since windows vista) the video driver may not report the actual (usefull and decent) correct usage of vram, in my opengl experience (not with texture streaming, but with some heavy streaming of vertex buffer objects) i always had to leave some free vram to prevent hitches, because even when you ask first "please free this memory" and after "now load that thing" the driver may do that in a different order (load the new thing first and unload the old after, causing a "unasked spike" in vram usage)
if you "undershoot" the available vram for the streaming by like, 10%, even the "spikes" in usage and other stuff (mostly caused by vram visualization) may not be a problem anymore. (tried to remove the aero desktop compositing, didnt helped much)
all of this above may be wrong for Nvidia or other driver versions because ATI/AMD OpenGL support kinda suck, and thats my "current experience" in realtime graphics programming.
Computer specs where the problem happened:
VGA: 2x Radeon 6870 1GB (Crossfire Enabled)
CPU: Core i7 2600k@ 4.7ghz
RAM: 8gb ram ddr3 1600mhz cas9
Video Driver: Catalyst 12.8
Motherboard: p8p67 deluxe
PSU: SL8600EPS (decent 650W)
Sysop: Windows 7 Home premium
Storage: 3x 500gb Raid 0. (yeah, i wish those where ssd´s)
the actual overshoot is apparently very very small (about 10mb of vram or less is being "paged" from what i could pick in the basic monitoring tools), but when it happens it always cause a "rendering hitch" of about 1/4 of a second. (i cant show that on fraps because it would not be accurate, i dont have any other mechanism to film the computer screen also)
but the game runs great (makes a good use of crossfire here, although it looks cpu bound overall, 1080p max details) overall and i am very thankful as a customer, the game worthed every penny.
and humans are tasty =3
* i have moderate experience with programming realtime rendering engines, but mostly opengl, therefore i say more in a "developer suggestion" than "user suggestion". (not that this should mean much too)
the current code of the texture streaming apparently is "overshooting" the size picked for the memory pool used by the streaming textures, that is causing noticeable hitches during gameplay on my computer. (note: only when the vram usage is over 1gb)
The suggestion/bugfix: a console variable where we can tweak the size of the memory pool where the streaming memory management will work with.
Why?
Three reasons:
* first tweaking games is a very important part of "what makes proper pc games, well... pc games"
* The driver may report a wrong/undesired value. (yeah weird, but then i saw this before)
* For some people (likely very few people actually) that tweaking may help.
Longer version of the "why this may help some people"
in many cases (including vram virtualization included since windows vista) the video driver may not report the actual (usefull and decent) correct usage of vram, in my opengl experience (not with texture streaming, but with some heavy streaming of vertex buffer objects) i always had to leave some free vram to prevent hitches, because even when you ask first "please free this memory" and after "now load that thing" the driver may do that in a different order (load the new thing first and unload the old after, causing a "unasked spike" in vram usage)
if you "undershoot" the available vram for the streaming by like, 10%, even the "spikes" in usage and other stuff (mostly caused by vram visualization) may not be a problem anymore. (tried to remove the aero desktop compositing, didnt helped much)
all of this above may be wrong for Nvidia or other driver versions because ATI/AMD OpenGL support kinda suck, and thats my "current experience" in realtime graphics programming.
Computer specs where the problem happened:
VGA: 2x Radeon 6870 1GB (Crossfire Enabled)
CPU: Core i7 2600k@ 4.7ghz
RAM: 8gb ram ddr3 1600mhz cas9
Video Driver: Catalyst 12.8
Motherboard: p8p67 deluxe
PSU: SL8600EPS (decent 650W)
Sysop: Windows 7 Home premium
Storage: 3x 500gb Raid 0. (yeah, i wish those where ssd´s)
the actual overshoot is apparently very very small (about 10mb of vram or less is being "paged" from what i could pick in the basic monitoring tools), but when it happens it always cause a "rendering hitch" of about 1/4 of a second. (i cant show that on fraps because it would not be accurate, i dont have any other mechanism to film the computer screen also)
but the game runs great (makes a good use of crossfire here, although it looks cpu bound overall, 1080p max details) overall and i am very thankful as a customer, the game worthed every penny.
and humans are tasty =3