|
|
|
Steve, sloppy reading on my side ... of course 256<<20 would be better. But it was just a quick hack in the editor anyway, in fact I would suggest a more dynamic approach because even 256MB may be too little on a 1GB system as operating system and SL (except texture buffer) will realistically probably need a non_text_system_mem of about 400MB. Thanks for looking into it. Steve, I'm attaching a patch here for this problem with dynamic system memory reserve that also adreses systems with 256 MB. This obviously is not to implement as-is but probably a good starting point. Snippet from the patch: if (SYSMEM_EQUAL_OR_HIGHER(1024*megabytes)) // systems with 1GB and more { min_non_tex_system_mem= 512*megabytes; // caps tex-mem to 512MB on 1GB machines } else else // systems with less than 512MB (256MB, 384MB, etc.) { min_non_tex_system_mem= 192*megabytes; // absolute minimum (caps tex-mem to 64MB on 256MB machines) }I have been playing around with the texture buffer and various memory sizes on a build that also has the memory leak fixed and am attaching a new patch which scales the memory size of the texture buffer in a more consistent way and also included a change as of The #define can be avoided and replaced with a normal definition or inline definition. I see your name in the comments of the patch, yet final patches should be made anonymous if possible. Some of the comments can be simplified to terse global or static consts.
I think I am experiencing the symptoms of this issue with Windows XP, running a brand new ATI Radeon X1950 Pro IceQ3, with the latest stock Catalyst drivers from ATI's website. The card has 512mb of onboard graphics memory, and my computer has 1GB of system memory. I did have a tiny problem with this in previous viewers, after many hours of running SL, but was using a Radeon 9500 Pro then, and therefore less graphics memory etc ....
Here are some figures of what is happening to my Second Life viewer when walking into a high texture area. Just look how quickly it dies ..... TIME - 5.53 AM Time - 5.57 AM Time - 6.00 AM This is the client that I am running. The brand new one ....
Second Life 1.17.3 (1) Jul 9 2007 15:23:37 (Second Life Release) You are at 261188.1, 235049.3, 53.2 in Whitlow located at sim4410.agni.lindenlab.com (63.210.158.60:13006) CPU: Intel Pentium 4 (Unknown model) (3060 MHz) Mart,
in the task manager look at the VM Size not RAM Size for the secondlife.exe process. This will be the more relevant value. And on a 1GB machine, set preferences, advanced-graphics, video memory to 128 MB (or 256MB). This patch helps reduce swapping quite a bit, but the implementation seems more complex than necessary, to the point I can't quite wrap my sleep deprived brain around it. Could you simplify it all down to a single linear function or something?
By popular demand here a current version 0733_llviewerimage_1_18.patch of the patch. I have tried to clarify and streamline the comments a bit. Essentially what it does is to tweak the upper and lower limits of the memory texture chache to not create it with a size too small (resulting in blurry textures) or too large (causing disk swap). I should note that I've only been able to test this on systems with 64mb vram and 512mb RAM, my systems with better video cards and more RAM are currently rather allergic to SL, driver problems. ;P
See
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Change Request: Excess texture buffer memory size resulting in disk thrashing/crashes/virt memory swapping
This would effectively prevent us from running on systems with < 512 MB of RAM, however it is certainly a valid argument for systems with >= 512 MB of RAM. I will go ahead and make that change in the next update.