Jump to content
fred41

using large page memory mapping, for increased performance

Recommended Posts

The UseLargePages is the flag.

So change to 0, restart, change back to 1, restart and it should work again? Change something else in the flag? Change to what? Delete old and make new that's exactly the same? Running the LPManager privilege again and restart? :confused:

Share this post


Link to post
Share on other sites
So change to 0, restart, change back to 1, restart and it should work again? Change something else in the flag? Change to what? Delete old and make new that's exactly the same? Running the LPManager privilege again and restart? :confused:

Change the registry value (= a flag) to 0 and start the game.

Apparently restarting is not needed, the value is read when the game starts.

Share this post


Link to post
Share on other sites

NTheaders OptionalHader DLLcharacteristic DLLcanMove must be disabled

the game engine is built with it enabled by default so it will always crash

Share this post


Link to post
Share on other sites

If someone can explain exactly what to do but the easy way:) Step for step , it would be great for people not having a clue about what Dwarden is talking about. The part Greenfist wrote is easy but not the last post :)

Share this post


Link to post
Share on other sites

I think Dwarden meant editing the game executable, like mentioned in the first post. Or is just for arma3server.exe? We shouldn't be messing with the client executable, right?

Edited by Greenfist

Share this post


Link to post
Share on other sites
If someone can explain exactly what to do but the easy way:) Step for step , it would be great for people not having a clue about what Dwarden is talking about. The part Greenfist wrote is easy but not the last post :)

I guess the registry edit part isn't needed anymore and the engine already does it by itself. So you should edit the registry from 1 back to 0 or delete it. At least I'm getting LPs even when it's 0 and after deleting the DWORD.

For the more experienced users, you can do the required changes manuallly too, by:

1. use regedit to create/set DWORD value 'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3.exe]

(or just merge GMF_on.reg from github repository)

Just reverse that.

Edited by St. Jimmy

Share this post


Link to post
Share on other sites

it's binary flag which needs to be set either by freds41 tool or by e.g. CFF explorer ... w/o such change it always crash

Share this post


Link to post
Share on other sites

What did you guys change in the engine ? I mean it worked before without any problems . Is this just an issue for Dev Branch or will this be implemented to the next Stable Branch release?

Share this post


Link to post
Share on other sites
it's binary flag which needs to be set either by freds41 tool or by e.g. CFF explorer ... w/o such change it always crash

I'm now asking again just in case. This is about client only not server.

So setting 'UseLargePages' = 0 is now right thing to do so there won't be any crashes? Because as 1 it crashes and as 0 (or the whole DWORD deleted) everything works fine. Or is there some other wizardy we should do to get everything out of the tweak in the current dev branch?

Share this post


Link to post
Share on other sites

if you use the

'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3.exe]

or

'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3server.exe]

under Windows 7 or 2008/2008r2 server then

you need change flag e.g using program CFFexplorer http://www.ntcore.com/exsuite.php

NTheaders

- OptionalHader

-- DLLcharacteristic

--- DLLcanMove

must be disabled

as the game engine is built with it enabled by default so it will always crash

this was and is ALWAYS known issue on server (that's why fred41 has the tool to switch the flag and always mentioned it)

note: do NOT use this on 1.38 client nor server , it changes way the engine work with memory and unforeseen consequences

Edited by Dwarden

Share this post


Link to post
Share on other sites

... this are no good news ...

The problem is most likely caused by a changed compiler/linker setting for 'arma3.exe' client build in dev branch.

For BI devs, this is namely the linker setting /DYNAMICBASE (was always /DYNAMICBASE:NO for arma client).

Linker setting /DYNAMICBASE:yes (or /DYNAMICBASE), together with IFEO 'UseLargePages=1' for 'arma3.exe' will crash at start.

Patching the clients (arma3.exe) fileheader later (via CFF Explorer) is most likely not a good option, because of anti-cheat?

Maybe a BI developer, familiar with the client building process, can tell us what settings we have to expect in the next stable build?

Share this post


Link to post
Share on other sites

I admit to understanding little or nothing about what the file header patching is about. I am concerned about what it means; when Fred41 started the thread on using large pages, I tried it and found no difference, Investigation showed that a demanding proprietary program from a client had set that already. I use that program for certain consultancy projects and I don't want to have to keep changing settings.

I only use the stable releases. IMO these should not contain code that affect the basic operation of users' machines and potentially hamper or even break other applications.

If I've completely misunderstood what this is about, not really surprising as I would guess that many players would be equally clueless about such as:

"NTheaders

- OptionalHader

-- DLLcharacteristic

--- DLLcanMove"

Orc

Share this post


Link to post
Share on other sites

well my point is that the tweak never worked w/o the flag being changed (at least for me) ...

i always needed 3rd party app to change it before starting game client or server binary Windows 7/ Windows 2008/2008r2 server

ofc I will check with the programmers and building pipeline guys if we can do something about those flags

Share this post


Link to post
Share on other sites
... this are no good news ...

The problem is most likely caused by a changed compiler/linker setting for 'arma3.exe' client build in dev branch.

For BI devs, this is namely the linker setting /DYNAMICBASE (was always /DYNAMICBASE:NO for arma client).

Not true, we have always used /DYNAMICBASE for Arma 3. The thing that has changed recently is that we have switched to a newer Steam protection mechanism as the one we have used previously is now obsolete and stops working randomly.

---------- Post added at 07:37 ---------- Previous post was at 07:36 ----------

I only use the stable releases. IMO these should not contain code that affect the basic operation of users' machines and potentially hamper or even break other applications.

Are you suggesting that Arma 3 affects your machine operation or breaks other applications?

Share this post


Link to post
Share on other sites

Can I as a casual player continue to use this tweak or am I doomed to lower performance because of the recent change you made?

To be honest the only reason I started to play Arma 3 again was because of this tweak and tbbmalloc allocator

because I was able to enjoy playing again with OK performance. If this is not possible any more then I might consider to stop playing again.

Or a solution might be that I never update my game to 1.38.

Edited by Nikiforos

Share this post


Link to post
Share on other sites
Are you suggesting that Arma 3 affects your machine operation or breaks other applications?

No, I'm asking for a simple explanation of what the phrases I quoted mean in terms of machine function. My machine is set to use large pages by default (otherwise a program I can't discuss will not function correctly or will likely crash with a large data set). If a forthcoming stable release includes code that messes with that setting or requires it to be switched off before running the game then I need to know about it.

Share this post


Link to post
Share on other sites
No, I'm asking for a simple explanation of what the phrases I quoted mean in terms of machine function. My machine is set to use large pages by default (otherwise a program I can't discuss will not function correctly or will likely crash with a large data set). If a forthcoming stable release includes code that messes with that setting or requires it to be switched off before running the game then I need to know about it.

The LP setting only applies to arma3.exe, right? It's not global to your machine.

Share this post


Link to post
Share on other sites
Not true, we have always used /DYNAMICBASE for Arma 3. The thing that has changed recently is that we have switched to a newer Steam protection mechanism as the one we have used previously is now obsolete and stops working randomly.

@dashbog, look: a application linked with /DYNAMICBASE, would always be mapped at a random place in processes virtual address space (ASLR).

This is not the case with current stable 1.36 (and was most likely not, since alpha in stable and dev branch for arma client).

Simple proofs:

1. if you start arma3.exe 1.36 stable (without any patching or tweaking) and you check its mapping address (via VMMap, sysinternals), you will find it ALWAYS be mapped at the same address (0x400000) (-> /DYNAMICBASE:NO).

2. if you open arma3.exe with CFF explorer (explorer suite), you will find in 'NT Headers'->'Optional Header'->'DllCharacteristics' a value of 0x8100, what implies a fixed mapping address is prefered instead of ASLR.

3. GMF tweak would not work for current stable arma 3 client without fileheader patching, but it still does ...

Share this post


Link to post
Share on other sites

I'm extremely late to the party here, and after some reading I wasn't 100% certain where this tweak stood with the current stable version, but I decided to give it a try along with the updated allocator.

After using the Altis Benchmark (v0.60) I'm happy to report a jump from 58 to 67fps. I didn't really notice the frame increase on the top end, but where I did notice it was at the points of the benchmark that would stutter or tank my frame rate for a split second, which really makes a big difference. Thanks for this!

Edit: I set up a small test battle on Altis including 4 tanks and about 20 AI, everything is running great but my Task Manager reports a RAM usage of only ~255MB for Arma which I though was very strange. Before the tweaks Arma typically used 1.6-1.8GB.

I confirmed that everything is working in the malloc_xxxx.log so now I'm wondering, is there a version of the allocator somewhere that does not create logs?

Edited by DGeorge85

Share this post


Link to post
Share on other sites

Well be happy now because this is going to change with the next stable update!

Share this post


Link to post
Share on other sites
Well be happy now because this is going to change with the next stable update!

Why is that? Are they removing the ability to map Arma to large pages?

Share this post


Link to post
Share on other sites

Please read the last two pages so you can get the full picture. Personally I'm getting tired of all these changes for the "better".

One step forward and two steps back:(

Edited by Nikiforos

Share this post


Link to post
Share on other sites
Please read the last two pages so you can get the full picture. Personally I'm getting tired of all these changes for the "better".

One step forward and two steps back:(

Well, I'm not sure I get what you are worried about thus far.

The most notable piece I saw in the recent pages was this:

I'm getting LPs even when it's 0 and after deleting the DWORD.

In other words, Arma is automatically using large pages on his machine. I'm not sure there is any explanation for that other than BI is implementing this into future builds, but again, I'm not sure what you are worried about.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×