|
|
Possible 2GB limit workaround?
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
Possible 2GB limit workaround? // Feature suggestions
Post by Alien // Aug 10, 2006, 10:45am
|
Alien
Total Posts: 1231
|
I've been giving some thought to the whole 2GB memory limit thing. I know with some types of software/code, if you want to use it on a different platform/OS all you have to do is recompile it, but I suspect porting tS to 64bit wouldn't be so easy. In which case, I have an idea for a workaround. I'm not sure of its feasibility, but thought I'd post it anyway incase it gives the Devs any ideas.
When running in 32bit mode in XP64, each process is limited to 2GB, right? So what if the render engine was launched as a seperate process [by tS - would still look & function same way as it does now, from the user's perspective], that way the renderer would get the whole 2GB to itself [assuming system has sufficient RAM installed], instead of only getting 2GB minus whatever the rest of tS is using.
Like I said, I don't know how feasible this - there's probably a whole bunch of reasons why it wouldn't work, but I thought I'd mention it just in case. :) |
Post by tomasb // Aug 10, 2006, 1:05pm
|
tomasb
Total Posts: 261
|
I've been giving some thought to the whole 2GB memory limit thing. I know with some types of software/code, if you want to use it on a different platform/OS all you have to do is recompile it, but I suspect porting tS to 64bit wouldn't be so easy. In which case, I have an idea for a workaround. I'm not sure of its feasibility, but thought I'd post it anyway incase it gives the Devs any ideas.
When running in 32bit mode in XP64, each process is limited to 2GB, right? So what if the render engine was launched as a seperate process [by tS - would still look & function same way as it does now, from the user's perspective], that way the renderer would get the whole 2GB to itself [assuming system has sufficient RAM installed], instead of only getting 2GB minus whatever the rest of tS is using.
Like I said, I don't know how feasible this - there's probably a whole bunch of reasons why it wouldn't work, but I thought I'd mention it just in case. :)
New code is 64bit ready; but unfortunately you cannot mix 32bit and 64bit. so once old modeler is away, no problems with 2gb barrier. |
Post by frootee // Aug 10, 2006, 4:13pm
|
frootee
Total Posts: 2667
|
question tomas:
is the Player code in ts 7 64 bit? The reason I am asking is,
if the modeler and player are separate programs/processes,
and the player is 64 bit, but the modeler is 32 bit,
would we be free of the 2 GB limit if the bridge is turned off?
So does this imply that the ts 7 player code is 32 bit? I am just curious (I am a software programmer/developer/systems/etc.)
Thanks,
Frootee |
Post by Shike // Aug 10, 2006, 10:57pm
|
Shike
Total Posts: 511
|
New code is 64bit ready; but unfortunately you cannot mix 32bit and 64bit. so once old modeler is away, no problems with 2gb barrier.
YES! Finally a reason to start saving for a 64bit system :D |
Post by tomasb // Aug 10, 2006, 11:31pm
|
tomasb
Total Posts: 261
|
question tomas:
is the Player code in ts 7 64 bit? The reason I am asking is,
if the modeler and player are separate programs/processes,
and the player is 64 bit, but the modeler is 32 bit,
would we be free of the 2 GB limit if the bridge is turned off?
So does this imply that the ts 7 player code is 32 bit? I am just curious (I am a software programmer/developer/systems/etc.)
Thanks,
Frootee
modeler&player are not separate programs; they run as one app within separate threads, with common address space.
problem here is similar as it was with 16bit/32bit apps. You could ran 16bit/32bit apps on one system; but you was not able to mix 16/32bit threads within one app due to address space. (the same way you was not able to use 16bit dlls from 32bit app and vv). |
Post by frootee // Aug 11, 2006, 2:22am
|
frootee
Total Posts: 2667
|
ah now I see. separate threads, shared memory space; not separate applications/processes. Cool!
Thank You Tomas. Now I understand.
Frootee |
Post by Alien // Aug 11, 2006, 3:05am
|
Alien
Total Posts: 1231
|
modeler&player are not separate programs; they run as one app within separate threads, with common address space.
problem here is similar as it was with 16bit/32bit apps. You could ran 16bit/32bit apps on one system; but you was not able to mix 16/32bit threads within one app due to address space. (the same way you was not able to use 16bit dlls from 32bit app and vv).
Thanks for the info. I was just about to ask if it would be possible to save the scene, then shutdown tS, & restart it in 64bit mode without the 32bit stuff, but I realised that would mean we wouldn't be able to use any of the pre-tS7 shaders. |
|
