Page 1 of 1
Multiple monitors & Celestia
Posted: 18.02.2007, 18:56
by Makhno2007
Multiple monitor bugs?
I run a 8800GTX with two monitors. Celestia runs fine on one monitor, but when put Celestia on another sometimes the planets are corrupted, or sometimes the window doesn't update at all.
It doesn't happen with some other OpenGL apps I have, but it does occur with one DirectX one (Global Mapper 8 3D view). I wonder if anybody has any suggestions?
When it's half on one monitor and half on the other, the one on the second monitor is corrupted but the other is fine!
Posted: 20.02.2007, 19:51
by Boux
Same here on a quad-head setup.
Celestia's engine needs a complete overhaul.
Don't take me wrong, it is a great program.
But... if you have a lot of extra hi-res textures and large models...
Worst issue is memory management.
Celestia is a hog. It will eat all available resources.
The more resources you give it, the more it will exhaust them.
This is true both in Windows and Linux.
I have just upgraded to 4 GB high-end 4.4.4.12.2 PC8500 memory.
It will crash as soon as it has eaten all of it. It will crash just a little later than with 2 GB.
Posted: 20.02.2007, 21:19
by Cham
I exactly have the same experience as Boux, on a Mac (dual G5 with 4 GB ram, etc, etc).
Celestia doesn't seem to be very efficient, on memory management and disk access.
Posted: 20.02.2007, 21:59
by selden
Boux,
What's the aggregate size of the Addons?
How big is the paging file? i.e. how big is the computer's virtual memory?
If you require Celestia to load gigabytes of Addon data you have to provide someplace for the data to be.
(I don't have a dual display, so I can't comment on that.)
Posted: 20.02.2007, 22:49
by chris
An overhaul isn't necessary, but some strategy to better manage texture usage should be implemented. Though models can get very large, textures tend to consume the largest amounts of memory. Virtual textures are the worst culprits, simply because they tend to be huge. Celestia's current texture manager could be modified to track the last usage of a texture and free less recently used textures before loading new ones. Another problem is that for a given viewpoint, Celestia uses the same level of detail for virtual texture tiles. This can waste a lot of memory when the camera is close to the surface of a planet: more distant regions of the planet should be textured with lower resolution tiles.
I will do something about the problem . . . The only reason that I've put it off so long is that I personally don't run Celestia with a lot of extremely large textures, so I observe the bloat that people with more high res add-ons will see.
--Chris
Posted: 23.02.2007, 22:14
by neo albireo
Better texture management would be extremely appreciated! I'm happy to hear that there's hope for improvements in the not so far future.
Posted: 25.02.2007, 19:51
by Boux
selden wrote:Boux,
What's the aggregate size of the Addons?
How big is the paging file? i.e. how big is the computer's virtual memory?
If you require Celestia to load gigabytes of Addon data you have to provide someplace for the data to be.
(I don't have a dual display, so I can't comment on that.)
Hi, Selden,
The aggregate size of the addons is over 6 GB here.
The virtual memory paging space size will not make any difference (pagefile in WinXP or Swap partition in Linux).
Celestia crashes as soon as it has eaten the available physical ram, wether 2 or 4 GB. It crashes a little sooner in XP than in Linux, no surprise here, given the superior memory management scheme in Linux.
Another difference between XP and Linux is that there is no corruption when Celestia runs on two screens at the same time in Linux (more robust drivers, solid interaction between Xinerama, window manager and Xorg server).
Display starts corrupting itself randomly in Linux when expanding from 3 to 4 screens, though. For sure, this is an extreme condition.
Chis, improving texture management is certainly a major overhaul
If you implement this, it will be a major breakthrough.
Posted: 26.02.2007, 07:36
by starfleetengineer
I read somewhere that XP is unable to use more than 3GB of physical memory for applications (even if you have 4GB installed). According to what I read, 1GB is reserved for system processes and is un-available to applications.
I can't remember exactly where I read this but I'll try to track down the source, or perhaps someone else can confirm this?
Posted: 26.02.2007, 12:41
by selden
Celesita has been developed under 32bit operating systems. If you're running binaries provided by someone else (e.g. downloaded from SourceForge) they are sure to have been built under 32bit operating systems: they'll have the 2GB signed / 4GB unsigned limitations built into them.
Even if you build the program from source code under a 64bit OS, I suspect there are quite a few places where the code uses 32 bit pointers and others where it makes assumptions that are not compatible with a 64 bit address space. Someone will have to go through the code carefully to find all of those problems, debugging under a 64 bit OS.
Posted: 26.02.2007, 13:29
by starfleetengineer
I tracked down the information I referred to earlier, which happily I had saved to my harddisk.
IMO, a proper memory management and garbage collection strategy in CELESTIA would mitigate or delay to some extent the onset of these limitations in 32bit windows. For example, textures on objects which may have been visited earlier, but no longer subtend significant angles (eg. LY's away) should be "bumped" from memory when space is required for a foreground object's textures. I'll leave it however to the expertise of those who know the code, to come up with a suitable strategy.
"Operating systems based on Microsoft Windows NT technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software.
The 32-bit versions of the Windows 2000 Advanced Server and Windows NT Server 4.0, Enterprise Edition, operating systems were the first versions of Windows to provide applications with a 3-GB flat virtual address space, with the kernel and executive components using only 1 GB. In response to customer requests, Microsoft has expanded the availability of this support to the 32-bit version of Windows XP Professional and all 32-bit versions of Windows Server 2003.
Windows 2000 Memory Support. With Windows 2000 Professional and Server, the maximum amount of memory that can be supported is 4 GB (identical to Windows NT 4.0, as described later in this section). However, Windows 2000 Advanced Server supports 8 GB of physical RAM and Windows 2000 Datacenter Server supports 32 GB of physical RAM using the PAE feature of the IA-32 processor family, beginning with Intel Pentium Pro and later.
Windows XP Professional and Windows Server 2003 Memory Support. The maximum amount of memory that can be supported on Windows XP Professional and Windows Server 2003 is also 4 GB. However, Windows Server 2003, Enterprise Edition supports 32 GB of physical RAM and Windows Server 2003, Datacenter Edition supports 64 GB of physical RAM using the PAE feature.
The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting.
The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.
The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file. The following example shows how to add the /3GB parameter in the Boot.ini file to enable application memory tuning:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="????" /3GB
Note: "????" in the previous example can be the programmatic name of any of the following operating system versions:
Windows XP Professional
Windows Server 2003
Windows Server 2003, Enterprise Edition
Windows Server 2003, Datacenter Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows NT Server 4.0, Enterprise Edition
Windows NT 4.0 Memory Support. With Microsoft Windows NT 4.0 Workstation and Server operating systems, the maximum amount of physical memory supported is 4 GB. The maximum amount of virtual memory is 2 GB.
With Windows NT 4.0 Server, Enterprise Edition, the /3GB switch was first added to Boot.ini.
Application Memory Tuning. This capability allows memory-intensive applications to utilize up to 50 percent more virtual memory on Intel-based computers. Application memory tuning provides more of the computer's virtual memory to applications by providing less virtual memory to the operating system.
Application Changes. No APIs are required to support application memory tuning. However, it would be ineffective to automatically provide every application with a 3-GB address space.
Executables that can use the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. If you are the developer of the executable, you can specify a linker flag (/LARGEADDRESSAWARE).
To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation.
Some manufacturers preconfigure their applications to use application memory tuning, making it unnecessary for you to make this change. For more information, see your application documentation and contact your application vendor to determine whether they support Large Address Awareness or whether you can enable it in their application.
Physical Address Extension. PAE is an Intel-provided memory address extension that enables support of up to 64 GB of physical memory for applications running on most 32-bit (IA-32) Intel Pentium Pro and later platforms. Support for PAE is provided under Windows 2000 and 32-bit versions of Windows XP and Windows Server 2003. 64-bit versions of Windows do not support PAE.
PAE allows the most recent IA-32 processors to expand the number of bits that can be used to address physical memory from 32 bits to 36 bits through support in the host operating system for applications using the Address Windowing Extensions (AWE) application programming interface (API). For information about the AWE API, see the Base Services section of the Platform SDK.