Sun, Nov 3, 5:56 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 03 10:43 am)



Subject: Question for the Tech heads out there


shedofjoy ( ) posted Wed, 06 July 2005 at 8:26 AM · edited Sun, 03 November 2024 at 1:31 AM

I know that poser will not work any better with Dual core 64bit Processors and windows 64bit, unless they make an update, But will poser be able to use the Systems newly aquired 16gb's of ram, or will it only use the 32bit operating systems 2gb's leaving 14gb's twiddling it's thumbs?????? (that is without an update,ie in P6's current state)

Getting old and still making "art" without soiling myself, now that's success.


kawecki ( ) posted Wed, 06 July 2005 at 9:51 AM

No, Poser software have to be rewritten and compiled with another compiler.

Stupidity also evolves!


pakled ( ) posted Wed, 06 July 2005 at 10:02 AM

It should use whatever the Operating System tells it to. You have a machine with 16 GIG of ram? (are you planning to model fluid dynamics, or resequence genes? sheesh..;)I know the processor can address that much, but you're tied to what the OS can see. What you need, m'fren, is a 64-bit OS..they're in the works, just not ready for prime time..;)

I wish I'd said that.. The Staircase Wit

anahl nathrak uth vas betude doth yel dyenvey..;)


kawecki ( ) posted Wed, 06 July 2005 at 10:17 AM

Another big problem is compatibility between AMD and Intel. AMD was the first who did 64 bit processors, so has created different registers and new instructions, the question is Intel will follow the standart created by AMD or create his own set as did with the extension to MMX, turning them useless for practical purposes. If the Cpu makers don't follow the same standart the 64 bit is dead, because it would need a Windows64 for AMD and a Windows64 for Intel, a Poser7 for AMD and other Poser7 for Intel, and so on.

Stupidity also evolves!


Khai ( ) posted Wed, 06 July 2005 at 10:28 AM

well Lads, you should keep up ;) Windows XP Pro 64 is Out. been out for a coupla months now, retail. written on AMD64 btw.. so no probs there.. Intel may have probs when they finally get a desktop chip out.. (sorry Intel you dropped the ball there) Driver support is a little light atm, but it is working..


Mason ( ) posted Wed, 06 July 2005 at 11:33 AM

Yeah I have a 3000 AMD 64 bit processor. Trouble is I think Poser has a hard memory limit of 1.4 gigs irregradless of swap ram available. You can have all the swap file size you want ie 40 gigs for example, but rendering systems usually want actual ram and not swap memory for speed. If you have a windows system that can only address 2 gigs of ram space then 1.4 gigs will probably be the limit poser can use (the other 600 megs going to OS and other items). I really really really seriously doubt poser will use swap memory space for actual renders. That's why you can load a mammoth scene but only have it yell at you for low memory when you render. The scene info more than likely goes into swap memory until you render. Then all textures and meshes are "unpacked" into raw ram and rendered from there. Only thing that would help Poser is for the OS to report back it has more than 2 gigs of addressable RAM (not swap file ram).


kuroyume0161 ( ) posted Wed, 06 July 2005 at 11:56 AM

You are tied to what the application is compiled to address. A 32-bit application can only address 32-bits of memory (even if it's running on a 128-bit machine with 128-bit OS). And limitations in Windows 32bit only allow half of this (or slightly more with the 3GB switch).

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


pakled ( ) posted Wed, 06 July 2005 at 4:19 PM

sorry..a condition of working for a very large corporation (they don't turn on a dime, at least OS-wise..heck, we're still transitioning from NT 4 to XP pro..;). I knew one was in the works, just hadn't heard of the release yet..;)

I wish I'd said that.. The Staircase Wit

anahl nathrak uth vas betude doth yel dyenvey..;)


shedofjoy ( ) posted Wed, 06 July 2005 at 5:06 PM

hmm so i see no one has tried this... to make things clearer... I wasn't asking if XP64bit was out or weather AMD and Intel were compatible, just will poser (32bit) working in a WinXP64 enviroment still only use 2gb's of the 16gb's that are possible on such a machine? I ask this because in a year i will upgrade, and there is no point in 32bit OS or systems if i want it to last another 3 years, so dual core 64bit is the way ahead, but considering Poser7 wont be out for atleast another several years will i be able to use my new systems 4gb's of ram (if thats what i will have installed)or will it still be limited to the 32bit os 2gb limit (or 1.4gb)????? oooh and i have read Lightwave 8 64bit is out soon

Getting old and still making "art" without soiling myself, now that's success.


Dale B ( ) posted Wed, 06 July 2005 at 6:37 PM

P6 will work on XP-64; the only caveat to be aware of is that 32 bit apps run in WOW (basically an emulator), so there may be some slight degradation. And Poser 6 in its current form is stuck with the 32 bit limit. However, if enough people make enough noise, we may just get a Poser 64. All reports are that the code changes are fairly straightforward, and the recompile is just as easy (they've been having cases of one programmer changing and recompiling major apps in a week or less). The extra memory bandwidth would be a godsend. There may be something in the code that would be the fuzzy lollipop to the idea, but IMHO that would be a wonderful way to keep the natives happy while they hammer away at P7.


kuroyume0161 ( ) posted Wed, 06 July 2005 at 6:56 PM

I think that I answered that quite succinctly. NOOOO. A 32-bit application CANNOT use more than 4GB (on a good day). Under Windows 32-bit (95/98/98SE/NT 4.x/MEXP Home/XP Pro) this means 2GB MAXIMUM!!! And any simulation of 32-bit (running 32-bit Windows apps on Windows x64) has the same caveats. You are stuck with 2GB MAXIMUM for Poser 6- on Windows. Period!!! ;)

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kenyarb ( ) posted Wed, 06 July 2005 at 7:39 PM

Attached Link: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Yep, two gigs it is. In head to head benchmark's I've seen on 64bit CPU's versus 32bit CPU's *in servers*, 64 bit CPU's run slower on most things. The only clear speed increases happen in graphics and database applications; everything else runs slower. It makes sense, since you're pumping twice as much data through a CPU, which in most cases is wasted. I generally tell people to avoid 64bit CPU's for at least a year.


kawecki ( ) posted Wed, 06 July 2005 at 9:58 PM

It will take many years until you can run 64 bits, it is similar to what was the transition that took from 16 bits to 32 bits (about ten years) and there are people still working with 16 bits! Of course Micro$oft will tell that you are running 64 bits with Win64, but you really will be running 32 bits with the 4Gb/2Gb memory limit. The only thing that the OS will be able to do is let each application has its own 2GB. Making code for 64 bits machines is easy as for 32 bits if you start from zero and program in assembler, but nobody do programming in assembler today!

Stupidity also evolves!


shedofjoy ( ) posted Wed, 06 July 2005 at 10:05 PM

thankyou all, that answered it and i agree we should start pestering EF as by the time they do something we will all be on 64bit, or Poser9...lol

Getting old and still making "art" without soiling myself, now that's success.


Khai ( ) posted Wed, 06 July 2005 at 10:11 PM

sorry mate.. but I don't know where you are getting your information from, but you are so very wrong. I suggest you do some research into 64bit apps and OS's before you carry on.. since you are really not A: making sense and B: talking a load of codswallop.


kuroyume0161 ( ) posted Wed, 06 July 2005 at 10:18 PM

I agree, Khai. There are already 64-bit Windows applications (Cinema 4D has a 64-bit version release already). And there are definitely 64-bit MacOS X applications being developed and released (although there are some strangenesses with this GUI issue). And, of course, there are 64-bit versions of *nix systems that have been around for some time. On the other hand, to be fair, there are very few motherboards that have >4GB memory support. They exist, but mainly for multi-processor servers. In due time, this will change. I suspect that within several years, we'll be seeing regular motherboard memory capacities of 16, 32, 128, 256, 512, and even 1024 GB (1 TB - on the leading edge, of course)!

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kawecki ( ) posted Wed, 06 July 2005 at 10:39 PM

Propaganda is very nice, but do you know what really is inside??? First at all do you know which are the advantages/disadvantages of 64 bit over 32 bit?, the real ones and not the propaganda!

Stupidity also evolves!


kuroyume0161 ( ) posted Thu, 07 July 2005 at 1:02 AM

Yes, 64-bit addressing. 64-bit is 2^64 (18 Quintillion bytes) as compared to 32-bit as 2^32 (4 Billion bytes). Sorry, Cinema 4D is said to be able to address 64-bit spaces (1 TB by their reckonin'). Look, I've been using computers since like 1987 (when the choices were 286 (16-bit), Apple II (16-bit), and Amiga (one of the first 32-bit PCs) (plug a couple other contenders)). And I've been a programmer (Assember, C, C++, Java, LISP, Pascal, BASIC) since about that time. I think I know what '64-bit addressing' means. There are no real speed advantages to 64-bit over 32-bit. It is all about addressable space. When you have 250GB harddrives and applications that are screaming for 8 or 16GB of memory, 32-bit is a losing proposition. There are ways to get around 32-bit limitations with paging and other segmentation forms (horrid VM), but 64-bits gives you addressing space for the next twenty years - 18,446,744,073,709,551,616 bytes (Damn! That's a f@E(*&R) big number). It's three orders of magnitude bigger than 32-bit (see your Physics book about 'orders of magnitude'). Where's the propaganda? Yes, there are shitty mobos that have 2GB max memory slots and say '64-bit'. You'd be a fool to fall for that crapola. Quality 64-bit mobos support at least 4GB memory (some support 8 and 16 already). Drivers and software will take time to migrate, but this is the future. Get used to it.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


kawecki ( ) posted Thu, 07 July 2005 at 4:05 AM

Mainframes (big computers) were always 64 bits(IBM) or 48 bits(Burroughs) even in those days with a memory of only 100KB. The only advantage of 64bits is how much memory you can access (physical or virtual), there are no advantages in speed. Today 32 bits processors access memory by a 64 bits bus and you don't need in most cases 64 bit registers. In special cases that you may need it you have the 64bits MMX registers. The problem is that software designed to realy run 64 bits processors with a 64 bit memory access will not run on 32 bits machines, so you will need two versions of the software. If some software says that can run on both it means it is running 32 bits with the limit of 4BG or Microsoft's 2GB.

Stupidity also evolves!


danamongden ( ) posted Thu, 07 July 2005 at 10:23 PM

Well, let me muddy the waters a little. In XP (32-bit) an application can access up 3GB if three things are true: 1) the /3GB switch is on in the BOOT.INI file. 2) the app was linked with the /LARGEADDRESSAWARE switch 3) the app doesn't set any internal limits restricting itself to the lower 2GB. (Many apps make coding assumptions about being in the lower 2GB. This is not really considered a bad practice, but it is one that must be dropped as the industry moves towards 64-bit.) If all three of those are true, then the app can get that third gigabyte, while the OS continues to reserve the fourth gigabyte. From various investigations with developer tools, I believe Poser fails on both #2 and #3. Iterestingly, I have been told via a 32-to-64 bit porting class (albeit second hand) that the 64-bit version of XP supports (or will support) a 32-bit compatability mode where apps using the /LARGEADDRESSAWARE flag will be able to access approximately 3.8GB of address space, providing they don't make any internal assumptions to the contrary. (Again, Poser as is will not exceed 2GB, regardless of the OS.) But for now, we have to live with 2GB, but at the same time, 4GB lets you run the other apps and OS w/o swapping so hard. I have 4GB right now, and it makes the system usable during renders. Your mileage may vary.


kuroyume0161 ( ) posted Thu, 07 July 2005 at 11:50 PM

Yes, there will need to be two versions of software (32-bit and 64-bit). This is always the case whether it's address space or processor support or some other architecture shift. There are two versions of Cinema 4D (the usual 32-bit for Windows and MacOSX and the 64-bit-only for Windows x64 (no MacOS version until Apple resolves the GUI issue)). 32-bit processors do a register combining to achieve 64-bit registers (double longs and such). But the registers are still 32-bit. Plus, you need BIOS, driver, HAL, compiler, and OS support to gain 64-bit addressing simulation on a 32-bit processor. Actually there are speed advantages, but not via raw processor ops or bus speeds. The advantages will come by removing slower addressing to segmented memory spaces and virtual memory on harddisks. When you can load a 13GB video totally into memory (instead of the current paging systems used by Premiere or Final Cut), you will consequently have speed increases. In other words, faster execution will be achieved by ancillary processes gaining new freedom.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.