Cool VL Viewer forum

Just did a test: I stripped myself off completely, keeping only my shape, my skin and my system hair. I placed myself on a single prim with the default texture at more than 2500 m of altitude, absolutely nothing around me. I logged out, then back in at the same position: memory usage, 53%…

There's something very wrong with your system then... I get less than 20% (of 3Gb) in the same conditions... Check that your OS is configured to provide 3Gb (for 32bits OS) or 4Gb (for 64bits OS) to 32bits applications... This is called the "memory split" under Linux... 32bits Windows is known to badly configure this by default, letting only 2Gb to 32bits applications... I don't know about MacOS-X.

All the sources I could find on the Internet say that there's no such setting on OS X…
But I've been digging a bit further and found out something else: if I ask for the full information about the Cool VL Viewer process, it says that the "Real memory size" is about 850 MB, but the "Virtual memory size" is almost 2.5GB… And that's just after opening it, home, without anyone around. And it says it consumes 73% of the available memory, which makes much more sense with the 2.5GB. But I don't understand what that means, or the difference between "real" and "virtual" memory size, or why the virtual memory is so much bigger than the real one…

I can't help you here... MacOS-X uses a non-standard memory management that makes it a real nightmare. The use of jemalloc in recent Darwin builds of the Cool VL Viewer somewhat helped alleviating some of the shortcomings (allowing to free some memory back to the system when no more in use), but I guess it's not enough and/or that changes would be needed in the llcommon/llsys.cpp file for the Darwin-specific parts. Not having any Mac at hand (and not willing to bother with Macs), I can't improve that part of the viewer...

My only advice would be: don't use MacOS-X... Try and install Linux on your Mac, and see what happens (faster, much more reliable viewer, for sure)...

I'm on mac as well with SL (on windows though when I need to use photoshop), and I don't experience the problems you refer to, just out of curiousity, what specs are your system, and have you tried any of the other viewers to see if the problem is the same (e.g. SL's default viewer).

I have noticed the performance is not very good in osx (at least on my system), espcially compared to the windows version of cool vl viewer.

Regards Catten

And it's even faster in its Linux' version...

Hi everyone,

just to toss an idea into the discussion ... it might be related to resolution. Ever since switching to 4k, memory's been getting tight for me again in crowded / "richly" textured places -- possibly a LOD thing?

I have begun using Kokua in its 64-Bit incarnation for situations where I know beforehand that memory is likely to get tight -- hate to use it though and I keep praying to the powers that be that the day a 64-Bit Cool VL Viewer appears may come soon.

Incidentally -- semi-silly question: couldn't you use the libraries the Kokua people build for their 64-bit viewer, Henri? If I remember correctly, it was mainly the added effort of having to build those as well that's holding you back?

Love,
Lia.

I'm on one of the latest iMacs, Intel Core i7 at 3,5 GHz, RAM is 32GB, graphics card is a NVIDIA GeForce GTX 775M with 2048 MB. The screen is 27", resolution 2560 x 1440.

I tried with the official viewer and here is what I see for used memory in the Activity Monitor when I'm logging in on a platform at 2500 m wearing only my shape, my skin, my eyes and my system hair:

• Official viewer: real memory is about 540 MB, virtual memory is a bit more than 1.8 GB
• Cool VL Viewer: real memory is about 475 MB, virtual memory is a bit less than 1.8 GB

So Cool VL Viewer actually does slightly better than the official viewer. I tested both viewers in a maximized window, at 2560 x 1392.

I tried to lower my resolution to 1920 x 1200, but that doesn't change things a lot: after a relog, real memory is more or less the same, virtual memory is a little bit lower, around 1.7GB (in Cool VL Viewer, I didn't try with the official viewer).

If you think Cool VL Viewer is not fast on OS X, then you don't want to ever try any of the other viewers.

Just did another test with another av of mine I'm sometimes using, which has much less things in its inventory (less than 5000 items compared to almost 70000 for my main). Results are more or less the same for it wearing only its shape, eyes, skin and system hair on a platform at 2500 m of altitude: after a relog, real memory size is about 280 MB, virtual memory is 1.6 GB, and Cool VL Viewer says the memory usage is 47%.

The inventory size is not an issue.

The problem is that, under MacOS-X, it's pretty much impossible to know what actual amount of virtual address space is consumed (i.e. currently allocated and used) by a process. All what the OS exposes is the maximum virtual address space address (i.e. it includes all the "holes" that contain de-allocated memory chunks).

Note that Linux and Windows don't do better with default system calls, but they at least do provide a way to estimate the actual used (allocated) virtual address space... See the llcommon/llsys.cpp file for the approximations I had to use in order to estimate the allocated space (and thus, whether it's possible or not to allocate more memory).

jemalloc improves the situation by at least providing a way to shrink down that "maximum virtual address space address" (which would otherwise keep growing over the session regardless of the actually allocated space, because of memory fragmentation and non-releasing of freed pages back to the system). However, it's insufficient, and some approximating calculations similar to what I implemented for Linux and Windows would be required... Like I pointed out in my last message, it's not going to happen (or at least, not from my doing), alas, since I don't have a Mac and won't bother with one anyway...