Open GL - out of memory error.

[StuartC]

I have separate drives for everything. OS on one drive, all my doccuments etc on another, games on yet another and a final drive as a download store.
I have not had an infection since I built this PC ( must be almost 5 years old ). I dont have room to site a " personal use only " PC unfortunately.

[Hooray]

different drives are obviously a good way to separate things, too. And to ensure that you don't touch any of the other drives (OS/data etc).

Alternatively, you could also use an external hard disk or a USB stick and install a different OS there, and simply boot from the external drive during startup.
A small external HDD is less than $50 US/30 €/20 £ these days. USB memory sticks with 32 gb of space are about $ 20 US only.

Note that your PC should have the resources to run VMs, so that you could run your 32 bit OS as a guest on a 64 bit OS - so that you could use the 32 bit system without having to restart.

Anyhow, upgrading to at least 6-8gb (or more) of RAM would seem like a pretty good idea if you can afford it.
Given that you are running a business and using your PC for work, all of these purchases would be tax deductible obviously

I have not had an infection since I built this PC ( must be almost 5 years old ).

These days, the problem is that there's some really nasty malware that doesn't behave like a typical virus, but instead remains silent in order to gather data (online banking, credit card numbers, other personal data) or to create so called botnets.

There's underground malware being traded as we speak which is charged more than $10k US per "seat", just because it cannot be detected by any current antivirus/malware tools, and because it can easily circumvent all existing security technologies like firewalls and system-level debuggers - for example, see: Zeus Trojan Horse. This is scary stuff and it's next to impossible for average end users to detect such malware, which may go unnoticed for months or even years.

[Hooray]

Subject: OpenGL "Out of Memory"?

Just a couple of days ago, Stuart and myself talked exactly about that here: http://flightgear.org/forums/viewtopic. ... 36#p164833

As you can see, the idea is to get realtime stats from the OS on the free amount of RAM and the amount of swap space used by the fgfs process (easy for Linux) - and write that to the property tree at 1-5 sec intervals, so that Nasal scripts or property rules could use this info to show warnings/errors or even just to scale down some systems (random buildings, local weather, tile cache etc) dynamically.

Once this info is in the property tree, it could also be shown in the rendering dialog - i.e. "Amount of free RAM" vs. "Swap space already used".
In addition, Stuart worked out a way to compute an estimate of memory consumption for the random buildings - so that this could also be linked to a slider, i.e. not just in the form of a "density" setting (0..1), but rather in the form of a "MB/density" such as in 256MB steps for example.
So that people can directly see how much RAM is going to be used by the system.

We also talked about introducing a simple form of "hard quotas" to disable the system and prevent it from allocating new objects once a certain limit is reached.

This is no problem with a 64bit fgfs, but a lot of people still use a 32bit version.

Yes, what is really needed is a good way to track memory consumption per subsystem, like the performance monitor works - such that we get to see exactly where memory is allocated, how many allocations per frame/second/minute etc - so that we can figure out where the real culprit is.

Fast forward 2 years later, there are now several options available to query the OS/GPU driver and obtain GPU specific information, such as amount of dedicated VRAM and overall GPU/VRAM utilization - here's what I've found for nvidia, and I am willing to provide a corresponding patch to expose these stats to the property tree and update them, i.e. once or twice per second:

http://www.geeks3d.com/20100531/program ... in-opengl/

NVIDIA has recently published the specs of a new extension called GL_NVX_gpu_memory_info.

Thanks to GL_NVX_gpu_memory_info you can retrieve the size of the total available GPU memory and the size of the current available GPU memory.

Here is a code snippet that shows how to use it. GL_NVX_gpu_memory_info returns sizes in KB.

Code: Select all

#define GL_GPU_MEM_INFO_TOTAL_AVAILABLE_MEM_NVX 0x9048
#define GL_GPU_MEM_INFO_CURRENT_AVAILABLE_MEM_NVX 0x9049

GLint total_mem_kb = 0:
glGetIntegerv(GL_GPU_MEM_INFO_TOTAL_AVAILABLE_MEM_NVX,
              &total_mem_kb);

GLint cur_avail_mem_kb = 0:
glGetIntegerv(GL_GPU_MEM_INFO_CURRENT_AVAILABLE_MEM_NVX,
              &cur_avail_mem_kb);



(There's also code doing the same thing for ATI/AMD cards via the GL_ATI_meminfo extension- we'd need to check if Intel GPUs support a similar API)

For nvidia, we could use the Nvidia management library: https://developer.nvidia.com/nvidia-man ... brary-nvml

Query-able states includes:

• ECC error counts: Both correctable single bit and detectable double bit errors are reported. Error counts are provided for both the current boot cycle and for the lifetime of the GPU.
• GPU utilization: Current utilization rates are reported for both the compute resources of the GPU and the memory interface.
• Active compute process: The list of active processes running on the GPU is reported, along with the corresponding process name/id and allocated GPU memory.
• Clocks and PState: Max and current clock rates are reported for several important clock domains, as well as the current GPU performance state.
• Temperature and fan speed: The current core GPU temperature is reported, along with fan speeds for non-passive products.
• Power management: For supported products, the current board power draw and power limits are reported.
• Identification: Various dynamic and static information is reported, including board serial numbers, PCI device ids, VBIOS/Inforom version numbers and product names.