Mason opened this issue on Oct 18, 2004 ยท 38 posts
danamongden posted Thu, 23 June 2005 at 7:04 PM
Sorry to be late to the party, but I only now came across this thread via a search on another topic. Here's what I found on the P5 memory limitations: Poser 5 does indeed have a 2GB limit, and as already pointed out, this is a common limitation on Windows apps since the OS reserves the top half of the address space. No fault there. However, it is possible to get into the third gigabyte if you do two things. First, the program must be linked with the LARGEADDRESSAWARE switch, and second, the target machine must have the 3GB switch set in the BOOT.INI file. This will cause only the top 1 GB to be reserved by the OS, leaving a 3GB address space for an individual process. My real-life job is for a software company (not to be named here) dealing the very large datasets. One of our customers ran into the 2GB limit a few years ago, so we set him up with a special version that used the 3GB linker switch. Now, it's not quite that easy, because it's easy to let some programming tricks prevent you from using that third gigabyte. For example, since you "know" that all your pointers will be less than the 2GB line, you could use that top bit as a flag for whether a 32-bit value were a pointer or some other 32-bit data structure like an ID or a collection of byte-sized opcodes. But then when those 3GB switches get thrown, suddenly you've got pointers with that high bit set. Alternately, some large apps do their own memory management, and they may have inadvertently put in their own 2GB limit. I believe Poser 5 (or the Firefly component) is depending on one of those tricks. Since it's possible to set that 3GB switch after-the-fact, I used a developer tool to tweak a copy of my poser executable to access the third GB. Everything ran fine with my usual mid-sized renders. Then I threw a test at it that I knew would get into the third GB. I watched the memory line carefully as it ran, and shortly after crossing into the third GB, the render crashed. Alas, it was not to be, so I tossed my modified Poser aside and made do with various scene tricks to keep my big renders going. (Note: this test was done on a Windows XP machine with 4GB of physical RAM. While that extra RAM doesn't help Poser any, it does make it feasible to run other programs during a big render.) I have not repeated this test on Poser 6, but I probably should. Now, interestingly enough, with Win64 coming down the pipe, I've heard rumours that there will be a mode where the LARGEADDRESSAWARE 32-bit apps will be able to access all but about the top 200MB of the address space, giving them 3.8GB to play with. Again that will be subject to the coding whims/tricks of the app developers. (Note: I haven't read this in any official Microsoft doc, so it might just be a rumour.) If true, then I would encourage all Poser/Vue/etc. developers reading this thread to review their codebases for anything that would prevent them from moving into the high address space, and start using the LARGEADDRESSAWARE linker switch. (From someone who's paid to know this sort of thing, and sometimes actually does.)