Cool VL Viewer forum

On the OSX version of the viewer I'm only allowed to use half my graphics memory, because RenderTextureMemoryMultiple is set default to 0.5. I manually set it to 1.0 so I can avoid textures constantly reloading and can use the 512mb option.

I can see other viewer has it default at 1.0 for OSX but I'm not sure what problems that can cause and what the reasoning behind the 0.5 default is. Do any of you OSX people know, and do you manually change it or just go with the 256MB memory?

Btw, on the same laptop, the windows version allows 512mb.

I've been discovering this setting a long time ago, and since then, I've always had its value set to 1.0 to be able to set the graphics memory to 512MB. Never had a single issue with that.

This is a historical setting LL did back in 2009 because they saw better performance on OS X with that setting. We were on OS X 10.5 or 10.6 at the time with systems typically not having more than 64 or 128 Mb graphics memory. Both the grapichs components of OS X and hardware have evolved considerably since.

I don't think there is any harm setting it to 1 although LL sets it at the historical setting in their viewer.

Ty for the feedback, I wasn't aware of that LL decision process. What do you say Henri? Should we enable the feature per default, and then let people manually lower it on old systems?

Be careful that this "texture memory" setting is not only affecting the amount of video RAM used to store textures into the graphics card, but also the CPU RAM used to store the raw textures and the compressed textures. In actuality, the viewer can use up to 1.25 times the amount of "texture memory" in CPU RAM (1.5 times in other TPVs and in LL's viewers).

When the viewer gets close to the 1.25 times limit, it automatically raises the "discard bias" factor, which in turn increases the discard level of textures (making them into lower resolution textures so that, in total, they still can fit the memory). This algorithm is however rather coarse and cannot guarantee that the viewer will not exhaust the available virtual address space.

This is why, in the Cool VL Viewer, I added a second algorithm (memory safety checks) to also controls the "discard bias" based on the actual available memory (when the available memory gets low, the discard bias is increased, regardless of the amount of CPU RAM used by textures; if this is not enough, the draw distance is reduced, and in critical cases (memory about to be totally exhausted), the camera is reset to its default position).
Alas, MacOS-X (unlike Linux and Windows) doesn't provide any reliable way to measure the actual CPU RAM usage (it lacks a malloc_trim() function to force-release the "freed" memory to the system, which then allows to measure what RAM stays allocated after the trim action to the viewer), meaning there's no "memory safety checks" under MacOS-X, and that's why I let this setting "as is" (even if LL used it for other purposes, namely poor video cards in older Macs, it still fills the purpose of providing a safer free memory margin under MacOS-X, thus making it more unlikely to exhaust the virtual address space).

So, while you certainly can raise this setting to 1.0 on Macs, be prepared to encounter more out of memory errors (which are most often trapped in the Cool VL Viewer, unlike in LL's viewers or other TPVs, but which still may cause crashes depending whether the allocation failure is irrecoverable or not).

That's why I'd rather not touch the default value for now, at least until someone compiles a jemalloc library under MacOS-X and then compiles the viewer with jemalloc as the memory allocator (jemalloc would add an equivalent to the missing malloc_trim() function, and would allow MacOS-X builds to get the same memory safety checks algorithm as Linux' and Windows')...

I completely forgot jemalloc, I remember you mentioned it to me. I'll try compile it and then let you know, so we can test the client with it.

One big huh to Henri on OS memory management.

It does not work as Windows and Linux because it has a completely different kernel and most modern applications are written in Objective C using the full frameworks available and ARC http://en.wikipedia.org/wiki/Automatic_ ... e_Counting.

While Cool VL Viewer is both reliable and fast on even the latest version of OS X, from a OS X development standpoint it is hopelessly outdated based on a 32-bit deprecated framework from which you will get no help any more. You may have to call Objective C methods to measure and manage memory at runtime.

https://developer.apple.com/library/mac ... TP40011226
https://developer.apple.com/library/mac ... /10000011i
https://developer.apple.com/library/mac ... emory.html
https://developer.apple.com/library/mac ... 0-BEHJDFCA

What's a "huh" ?...

Excepted that the viewer is a C++ program, not an Objective C program, and thus, you can't account for the C++ allocated structures using Objective C methods. The viewer also doesn't deal with the kernel memory (it's a user space application, not a device driver !). The actual level at which memory is managed in a C++ application is the C library level (malloc() & Co): MacOS-X got a POSIX compliant malloc implementation, but it lacks useful extensions such as malloc_trim() (Linux) or _heapmin() (Windows) to force the memory allocator to actually release the freed (via free() calls) memory to the system, so that the latter can recover all but the actually allocated/live memory blocks, and so that we retrieve the actual memory usage info (see indra/llcommon/llmemory.cpp).

MacOS-X lacks a way to force-release freed memory back to the system and therefore, your application's memory usage seems to keep growing (or staying stable) over time, never to decrease. In actuality, the "freed" blocks are kept in the application heap and will be reused by the next malloc()s (fragmentation permitting), but it prevents you, at the application program level, to anticipate memory exhaustion and take appropriate measures (such as the algorithms I implemented in the Cool VL Viewer) since you can't measure memory usage growth and decrease over time.

I have replied countless times to "why no/when 64 bits builds ?" on this forum (do a search, and simply reread the existing threads)...

All these links refer to method to measure the memory used by Objective C structures or by the kernel: they don't provide any way to measure the actual memory used by a C (or C++) application.

See if task_info gives you what you are looking for

http://www.opensource.apple.com/source/ ... ask_info.h

There is some info here too with a code snippet http://stackoverflow.com/questions/5839 ... mory-usage

and the heap man page https://developer.apple.com/library/mac ... man/1/heap

vmmap man page https://developer.apple.com/library/mac ... an/1/vmmap

You don't seem to understand what the *actual* problem is: using any of the methods you may find to measure the memory usage of a C++ (or C) application, you will invariably measure the peak memory usage for that application (i.e. the largest amount of malloc()ed memory during the session), because all free()d memory is never released back to the system, unless an explicit malloc_trim()-alike call is done, call which is ABSENT from MacOS-X.

The only solution to this issue under MacOS-X is to use an alternate memory allocator (such as jemalloc or tcmalloc), which does provide a memory release call.