Jump to content
Sign in to follow this  
Georgie

General OOM Issues

Recommended Posts

Thanks for the answer. So I´ll wait and hope for the best. If I can help with particular data or testing procedures to narrow down the problem, drop me a PM. :)

Btw, any opinions on my Colorful (Bumblebee) GT 240 graphics cards driver compatibility?

NVidia System monitor gives me an unknown SEEPROM device error at startup, so my doubts remain....

Some tools report this card to have 1 Gig of Ram, although it has just 512 MB.

Share this post


Link to post
Share on other sites

Ditto Phil. My job is running a team of coders so I could probably assist with your testing reasonably effectively, and because of this problem I'm not actively playing it atm so I wouldn't mind screwing up my install. i7-950 GTX 470 Win7 Ult 64.

Share this post


Link to post
Share on other sites

Some more Input Phil:

I open a large, detailed map in 3D-Preview (3D settings Better/Better). The first time works ok. I exit the scenario editor. Re-enter the scenario editor. Re-load the scenario: OOM.

Here the info I see in the Task Manager (is pretty consistent in serveral attempts). Number are Working Set/Peak Working Set/Private Memory/Commit Size

1st try 1'504'404/1'585'096/1'485'808/1'705'260

2nd try 634'692/1'585'096/615'736/819'360 (and OOM Error).

System Spec

Processor: Intel® Core i5 CPU M 430 @ 2.27GHz (2260 MHz)

Installed RAM: 4.00 GB

Operating System: Windows 7 Home Premium, 64-bit (Service Pack 1)

DirectX version: 11.0

GPU processor: GeForce GT 320M

Driver version: 188.17

CUDA Cores: 24

Core clock: 500 MHz

Shader clock: 1100 MHz

Memory clock: 790 MHz (1580 MHz data rate)

Memory interface: 128-bit

Total available graphics memory: 2779 MB

Dedicated video memory: 1024 MB

System video memory: 0 MB

Shared system memory: 1755 MB

Video BIOS version: 70.16.25.00.26

IRQ: 16

Bus: PCI Express x16

[Components]

nvCplUIR.dll 2.5.670.03 NVIDIA Control Panel

nvCpl.cpl 2.5.670.03 NVIDIA Control Panel Applet

nvCplUI.exe 2.5.670.03 NVIDIA Control Panel

nvViTvSR.dll 8.16.11.8817 NVIDIA Video and TV Server

nvViTvS.dll 8.16.11.8817 NVIDIA Video and TV Server

nvDispSR.dll 8.16.11.8817 NVIDIA Display Server

NVMCTRAY.DLL 8.16.11.8817 NVIDIA Media Center Library

nvDispS.dll 8.16.11.8817 NVIDIA Display Server

NVCPL.DLL 8.16.11.8817 NVIDIA Compatible Windows7 Display driver, Version 188.17

NVCUDA.DLL 8.16.11.8817 NVIDIA CUDA 2.2 driver

nvGameSR.dll 8.16.11.8817 NVIDIA 3D Settings Server

nvGameS.dll 8.16.11.8817 NVIDIA 3D Settings Server

Share this post


Link to post
Share on other sites
Guest

Yes. Two things:

1) We are in the process of making changes that will effect this problem. They won't come out immediately - they involve significant changes behind the scenes and we will need time to test them and to perform all of the various stuff that has to happen, for them to happen. But it is firmly in the "being worked on" category at all levels. As significant progress is made I'll report back. Please keep your reports coming - winkelreid's above is a perfect example of useful information (although an exact scenario title would be helpful).

2) The common denominator so far is that there IS no common denominator. My own suite of machines react very differently OOM-wise, and (except with machines with very low amounts of RAM) hardware configuration rarely matters. George Mc, the guy who designed Fire Brigade, has a fairly middling PC and yet has no problem loading and playing all of the very large scenarios he makes. If I make any gasp-worthy discoveries here I'll report as well.

Share this post


Link to post
Share on other sites

2) The common denominator so far is that there IS no common denominator. My own suite of machines react very differently OOM-wise, and (except with machines with very low amounts of RAM) hardware configuration rarely matters. George Mc, the guy who designed Fire Brigade, has a fairly middling PC and yet has no problem loading and playing all of the very large scenarios he makes.

That's because people run out of virtual address space and the hardware has nothing to do with it as long as there is enough paging space.

Any chance for a 64 bit version on Windows?

Share this post


Link to post
Share on other sites
That's because people run out of virtual address space and the hardware has nothing to do with it as long as there is enough paging space.

Any chance for a 64 bit version on Windows?

Bump on "Any chance for a 64 bit version on Windows?"

Share this post


Link to post
Share on other sites
Guest
That's because people run out of virtual address space and the hardware has nothing to do with it as long as there is enough paging space.

I'm surprised, actually, that you'd be willing to entirely rule out hardware-related complications. I can't do that, though. I'm trying to *solve* the problem, not just make assumptions about it.

Either way, I've stated very clearly that "the problem is actually X" or "here's the REAL solution" posts don't do anything to help me, Redwolf. You of all people should know that you're not seeing the whole problem, thereby making any blanket statements like the above speculative at best. Speculation causes confusion that I end up having to deal with, rather than spending my time working on the actual problem. So... stop, please.

Share this post


Link to post
Share on other sites
Guest
Bump on "Any chance for a 64 bit version on Windows?"

It's a definite possibility. It would take some serious development and testing time, though.

Share this post


Link to post
Share on other sites
It's a definite possibility. It would take some serious development and testing time, though.

This is promising news. I haven't touched the game for weeks now.

Share this post


Link to post
Share on other sites
It's a definite possibility. It would take some serious development and testing time, though.

Thanks for the reply Phil, great news. 64 bit may be on the horizon.:)

Share this post


Link to post
Share on other sites
Yes. Two things:

1) We are in the process of making changes that will effect this problem. They won't come out immediately - they involve significant changes behind the scenes and we will need time to test them and to perform all of the various stuff that has to happen, for them to happen. But it is firmly in the "being worked on" category at all levels. As significant progress is made I'll report back. Please keep your reports coming - winkelreid's above is a perfect example of useful information (although an exact scenario title would be helpful).

Thanks Phil. Why not set up a test scenario, tell us what to do, what data you need, we give that back to you along with machine specs? I'm sure more than a few people would be willing to help.

Share this post


Link to post
Share on other sites
The latest update (and in fact all updates, as it's the tech support thread for "out of memory" issues) is here:

http://www.battlefront.com/community/showthread.php?t=99521&page=6

The original WEGO out of memory problem - which was actually a bug - was fixed. Scenarios like "Fire Brigade" are causing legitimate out of memory errors (as in, they're using more memory than you have available) which we're working on minimizing.

Phil, I think there is a misunderstanding here. I can load "Fire Brigade" just fine if it is the FIRST PBEM game I load. However if I play another PBEM first, and then play "Fire Brigade", I get an out of memory error. I believe this is a different issue than the the OOM thread.

Reposted here for clarity.

Share this post


Link to post
Share on other sites
Guest

Ahh, I see. Yes, that's a different problem. Related, but different. Thanks.

Share this post


Link to post
Share on other sites

All right.

So it looks like Windows 7 introduced a feature that allows you to make a 32 bit process use the "allow 3 GB virtual memory" flag even if it didn't request it. I don't have Win7 but I am copying the info I found here:

  • Get a command shell with admin right. In Windows 7 32-bit go to Start -> All Programs -> Accessories -> Right Click on Command Prompt and select "Run as administrator"

  • Give this command:

    bcdedit /set increaseuserva 3072

    You should see: "The operation completed successfully."
  • Reboot

  • Then try whatever you have that got OOM before.

Note that this doesn't help if you had an out-of-graphics memory situation before.

It will also do nothing if CMBN already set the flag to have pointers > 31 bits before, but Phil has been unwilling to tell us.

If you have a 64 bit Win7 you can also try to set the number to something below 4096. The above around 3072 is for when you have a 32 bit kernel.

Share this post


Link to post
Share on other sites

RockinHarry - I believe Phil has recommended against the "4-gigabyte tuning" as the article calls it. This can have unintended consequences for the game, which apparently doesn't support this feature (IMAGE_FILE_LARGE_ADDRESS_AWARE - a feature that needs to be compiled into the executable).

Upgrading your system from 2GB to 4GB may help a little, but may not fully resolve the issues you're seeing. It should give you a little more memory (most likely you'll see between 3.0 - 3.25GB of RAM). This will give the operating system and other programs/utilities a little more room to operate and give close to the full 2GB of RAM to CMBN.

Considering the number of possible culprits in the code with this issue, it may take a number of patches before it is close to being fully resolved (or as close as possible). I'm not sure what it will take to address some of these issues, but it is quite possibly a LOT OF WORK that may need to be done.

Share this post


Link to post
Share on other sites
RockinHarry - I believe Phil has recommended against the "4-gigabyte tuning" as the article calls it. This can have unintended consequences for the game, which apparently doesn't support this feature (IMAGE_FILE_LARGE_ADDRESS_AWARE - a feature that needs to be compiled into the executable).

Upgrading your system from 2GB to 4GB may help a little, but may not fully resolve the issues you're seeing. It should give you a little more memory (most likely you'll see between 3.0 - 3.25GB of RAM). This will give the operating system and other programs/utilities a little more room to operate and give close to the full 2GB of RAM to CMBN.

Considering the number of possible culprits in the code with this issue, it may take a number of patches before it is close to being fully resolved (or as close as possible). I'm not sure what it will take to address some of these issues, but it is quite possibly a LOT OF WORK that may need to be done.

Thanks you sir. Appreciate the time and effort going into this and no I am not expecting the magic bullet, would be nice but that isn't generally the way things work on the computer and coding world.

Share this post


Link to post
Share on other sites
RockinHarry - I believe Phil has recommended against the "4-gigabyte tuning" as the article calls it. This can have unintended consequences for the game, which apparently doesn't support this feature (IMAGE_FILE_LARGE_ADDRESS_AWARE - a feature that needs to be compiled into the executable).

How do you know that? Did Phil finally say whether the flag is set in the first place? And why do you think it would look like a trashy first-generation pre-ANSI C piece of junk code? And even if not, what's gonna happen? Oh, the game could crash. Well, it's doing that anyway.

Also, going from 2 to 4 GB (or 3 on 32 bit kernels) sounds like a pretty big improvement to me no matter what goes on under the hood.

Share this post


Link to post
Share on other sites

My fervent hope is that BF is "forming its ranks" to attack this OOM problem and hasn't just "circled its wagons". But we won't know which course of action has been chosen until they throw us a bone or two.:confused:

Share this post


Link to post
Share on other sites
My fervent hope is that BF is "forming its ranks" to attack this OOM problem and hasn't just "circled its wagons". But we won't know which course of action has been chosen until they throw us a bone or two.:confused:

From everything i have seen, there hasn't been any "circling of the wagons". Having difficulty figuring out the base cause of these issues is not the same as saying they aren't trying. I think the low level of feedback communication simply reflects they don't have a lot of data yet they can share. They definitely aren't interested in giving any false impressions or promises which is a very good thing.

No news I think simply reflects the difficulty in isolating and reproducing.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...