Cool VL Viewer forum

Hi everyone,
I've been using Cool VL for years ad it's a good viewer. However, I recently began to encounter very frequent (and according to me, unjustified) virtual memory alerts, although all things are being equal on my side. In several cases, just standing in a populated area with a draw distance limited to 64 meters can trigger a virtual memory alert, auto-reset my camera view and lower my DD to minimal. And before that, I often see textures go blurry or remain greyed out.

Yet, my system is far above recommended specs, especially when it comes to RAM:


I have tried different settings on texture memory quantity (6, 4, 3 and 2 Gb), without any real difference in results.

I'm reporting a second bug here, cause it may be related to the first one: I also noticed that, despite Cool VL is a 64-bit app, it wants to install by default in the Program Files (x86) folder which, under Windows, is the folder dedicated to 32-bits apps.
So I was wondering: what if that made Windows treat Cool VL like a 32-bits app and thus allocating a limited quantity of RAM (less than 4 GB) to it? That could also explain the virtual memory issue above.

Both these glitches have begun to occur under 1.26.24 version, but I cannot remember the exact sub-version where they started. Also, I alternatively run Cool VL under a Linux machine with much lower specs but none of these glitches happen there.

If you need more info, I'll be around. Good luck

Sadly, you did not provide a log for a session where the warnings did happen, so I am reduced to guess work...

Did you check "Advanced" -> "Memory management" -> "Memory usage safety checks" ? If so, just uncheck it: this feature is mostly irrelevant to 64 bits viewer binaries (it is meant for 32 bits binaries, where the virtual address space is limited to 4 Gb and can get fragmented enough over time to cause memory allocation failures, or to systems where less than 4Gb or RAM is available).

16Gb of RAM is just about right for today's SLing, with millions-poly-meshes and material textures...

4Gb of VRAM for textures seems to be the right amount to allocate for your system. It means the viewer will use up about 6Gb just for the raw, decoded and GL-bound textures in RAM, and you need to keep some VRAM (here, it will leave 2Gb available) for other usages than textures (VBOs, FBOs, etc).

Not a bug. The installer is simply old (but gorgeous) and does not allow to propose a default folder other than this one under Windows, but wherever you install the viewer (and you are of course free to install it into the 64 bits "Programs Files" folder, or elsewhere), it won't change a thing on how the viewer runs (it is a native 64 bits application).

There has been no change whatsoever in memory management under Windows for many months (a few years, actually), so your issue is likely the result of a change you made to the settings.

You could copy your Linux viewer settings over the Windows ones. There is no reason the viewer would behave differently.

Thanks for your feedback, Henri. I will apply and test your advices.

Meanwhile, here is an attached log of my last session, during which I encountered the famous virtual memory issue. Just after it happened, I disabled the memory checks, as you said. No more alerts then, but some moments later, my session brutally ended into a crash to desktop.
Hope you can find some useful material in the file.

This is very strange, indeed. At crash time the log shows:
meaning that at the moment the crash happened, your system had 12.26GB of physical memory available to the viewer and that the latter only consumed 1.20Gb or physical memory and 2.12Gb of virtual memory (in a virtual address range of several hexa-bytes for 64 bits OSes, meaning the fragmentation does not matter the least, here, unless the session lasts for millions of hours).

Sadly, you did not attach the crash-dump file, so I cannot know where the viewer crashed (I could add a check for memory allocation failure there, even though there are other places such a failure could happen).

I have no explanation for such a behaviour, and I doubt very much the viewer is the culprit (with 2Gb consumed after a 3H30 session, there was obviously no memory leak, and plenty memory was available on the system). I would blame Windoze's malloc() for wrongly returning a NULL address (i.e. a memory allocation failure) while there was still plenty memory available. This could hint for another program interaction (anti-virus, virus ?) or a bug in Windows itself.

I started an hours long testing on a Windows machine, to see if I could at all reproduce this issue.

On your side, please get today's v1.28.0.0 release, disable memory safety checks once and for all, and report any new crash (with the log and the crash dump) here.

Also, how LL's viewer would react on your system: does it crash too after a few hours ?

Aye, Sir. Unfortunately my crash dump file is gone since then. I'll post a fresh one if it ever happens again.
No idea how LL viewer works cause I've ditched it a while ago. My other viewer is Firestorm and all I can say is that it's rock stable in almost any conditions

At the time of last crash, I remember having Firefox and CPUID HWMonitor running, if it can help.

Well, I started a session on a Windows 7 machine 5 hours ago, with rendering maxed out (512m draw distance, in particular), and an avatar sitting in an Info Hub, and it is still chugging along just fine... Granted, that's on a 32Gb PC, but still...

I'll try on another PC, closer to yours (16Gb 8Gb RAM and will use Windows 10) over night and see tomorrow...

EDIT: I just closed the session on the Win7 machine (2500K @ 4.5GHz, 32Gb RAM, GTX 970) after over 10 hours of flawless operations (including a few zooming/focusing sessions on every avatar in DD, and TPs from one Info Hub to another, the last one with over 30 avatars in the sim and impostors set to max/65 in my viewer). At closing time the viewer was consuming 4Gb of memory. Over 27000 mesh headers were cached in memory (with over 114000 mesh fetches during the session). Now starting the overnight test on an old PC (Q6600 @ 3.4GHz, 8Gb RAM, GTX 460) under Win10...

EDIT #2: I just closed the session on the Win10 machine after 9 hours of equally flawless operations (same procedure as for the more powerful PC, but without shadows rendering, so to keep the frame rate above 10 fps). At closing time the viewer was consuming 2.6Gb of physical memory (3.3Gb of virtual memory) on a total of 5.7Gb physical memory available (Win 10 is a pig and consumes a shitload of memory for itself !). Over 31000 mesh headers were cached in memory (with over 150000 mesh fetches during the session). CONCLUSION: The problem is NOT with the viewer, but rather with your system...

Actually that was fast. I just updated to 1.28 and it's a disaster. To be accurate, I imported my 1.26 settings.xml files cause I was too lazy to redo all my settings. And here are the log files.

Please, start afresh without the old settings...

Following the crash dump you provided, the crash happened in nvoglv64.dll, which is part of NVIDIA's OpenGL driver...

Since your driver is "old" (December 2019), you might want to try the latest driver which is v451.48. (*)

It is likely the explanation for the crash with v1.28 (which also implements the newest EE renderer).

It might not be the explanation for the memory issue, but who knows ?...

---

(*) It is always a good idea to:

• Keep a "known as good" driver around, in case a new driver would cause issue.
• Update your driver each time a new version is released by your graphics card/GPU vendor (but still keeping the "last known good" driver around for a rollback, just in case).

See edits in this message. My conclusion is that the viewer is not the culprit, even if, as a carefully (and relentlessly) optimized viewer (down to CPU caches usage), the Cool VL Viewer will stress your system more than most other viewers, if not all.

Additional hints to solve your system issue:

• Update Windows 10 and the hardware components drivers (especially the GPU driver) to the latest versions.
• Always update to your motherboard vendor's latest BIOS/UEFI whenever it contains a new microcode (or AGESA, for AMD).
• Graphics driver settings: check that every setting with a "let application decide" (or similar) option is set as such (particularly relevant to anti-aliasing, frame rate syncing, etc).
• Game mode: my Win10 machine was setup with "game mode" off (since it's not even useful, and could even be detrimental). Perhaps is there some difference with your system here..
• Overclocking: I do not know if you overclocked your system, but while I'm an enthusiastic adept of overclocking (Q6600 @ 3.4GHz, 2500K @ 4.5GHz, 9700K @ 5.0GHz, all GTX cards overclocked), if you overclock any component in your system, you must be wary that it requires deep, days to weeks long, and extra-careful/conservative testing to be deemed valid, or it will cause all sorts of random crashes that most over-clockers will likely attribute mistakenly to the software they are running. If you do overclock your PC, make sure it is 100% stable by running:
  
  • Hours-long (>12 hours) compilation loops with gcc (since you mentioned using Linux sometimes): this will test and stress your CPU (integer and cache parts only) and RAM overclock. Any segfault or "internal compiler error" would be the sign of an unstable overclock. For the first batch of the Zen CPUs (at stock clock), the simple installation of a Gentoo Linux distribution (which involves compiling everything from scratch with gcc) revealed subtle hardware bugs in their silicon (worked around later on with the release of a new AGESA by AMD).
  • Hours long Prime95 sessions (in both AVX-only and SSE-only modes for CPUs with AVX support). For modern CPUs (Skylake and later, all Ryzens), you will also want to test with 1 to N cores, with N=the number of (virtual) cores of your CPU, because those CPUs (which are specified with an almost zero margin to their actual max clocking frequency) won't work with a constant Vcore (like old CPUs could do), but need very precise Vcore curves depending on computation load and, sadly, the Vcore adjustments do not (and cannot) follow the computation load variations in real time (the Vcore is under the control of the motherboard micro-controller, and a delay in its reaction is unavoidable).
  • Days-long BOINC sessions (with preferably the most demanding CPU work units, i.e., for today's CPUs, AVX(2) and SSE2 work units): beside obvious crashes, any unexpected calculation error (or failed work unit result validation) would be the sign of an unstable system (but do check the "faulty" work unit status for other computers which ran it, since some work units in some BOINC projects may indeed "normally" error out on any computer). Since BOINC can run both CPU and GPU tasks, it can also be used to stress and validate both (as well as the strength and quality of your PC's power supply unit and PC case cooling, when all CPU cores + all GPU CUDA cores are at work simultaneously).
  • For RAM overclocking/timings tightening (including using the vendor's "XMP" profile(s)): hours long (repeated during several days: best performed while you are sleeping at night) MemTest86 sessions.
  • For GPU overclocking: hours-long GpuTest (especially FurMark, Volplosion, TessMark, Piano) stressing sessions.
  • Check that your overclock resists Summer days... The cooling of the components is not exactly the same between an ambient temperature of 20°C and 35°C...
  Any error/crash during the above tests means your system is unstable and needs to be down-clocked until you find the culprit (CPU, RAM, GPU).
  To just give you a small hint of the efforts involved, it took me no less than 6 full weeks to succeed in running 100% stably my 9700K at 5.0 GHz (only ! :-/) on all cores... In comparison, the 2500K was much easier to overclock (7 years ago, it could even run at 4.6GHz, but because of electromigration/aging, I had to remove 100MHz lately to keep it 100% stable), and the Q6600 was a breeze to push from 2.4 to 3.4GHz (just the multipliers and FSB to adjust: no Vcore fiddling).