Recently I started to experience troubles in loading large tracks (Fuji, Nord_NDS, Nurburgring GP), GPB was simply crashing while loading the track. In some cases, lowering the replay buffer (I usually have it at 512) did help. That was a big hint that the issue was in RAM memory allocation.
Today I gave a try to the Large Address Aware stuff (LAA (https://www.techpowerup.com/forums/threads/large-address-aware.112556/)) and all the issues went away.
I can load any track, with any graphics setting. I can also load a track, go back to main menu and pick another track, go to track, back to menu, and pick another track ... no crash.
In some cases I've seen a total RAM usage above 4GB (total, not GPB only, for GPB only I think I've seen a max of 1.something GB).
What is a bit surprising (but it may be normal) is that after doing the LAA change, I can still join an online server.
P.S.
The issue I had was clearly not tied to GPU RAM: somebody speculated that that may be the case (I have a GTX 970, with its well know 3.5/4GB problem) but I'm positive it isn't.
I can run tracks requesting more than 3.5GB of GPU RAM fine: I've already seen a peak usage of 3.8GB without any issue (had to use DSR @ 4K resolution with maxed out settings for that ... still managed some 50fps :) ).
Great info Max. Imola has proved the problem track for me and had to run my buffer at 300
Thanks m8
DD
Hmmm and where can you adjust? 8)
No real merit for me, I think that Hawk/h106frp mentioned the tool, I just gave it a try :)
Quote from: finpower on April 10, 2017, 07:38:50 PM
Hmmm and where can you adjust? 8)
Adjust what ?
Just run the tool linked, point it to gpb exe (core.exe): it will modify the .exe file (careful if you have it in a "protected" folder, you may need admin rights) to make it "Large Address Aware".
In case of troubles, you can rever the operation (or reinstall GPB on top, or everwrite the .exe with a previously saved copy of it).
Of course, it will only work if you have more than 4GB memory and win x64. Some explanations: https://helloacm.com/large-address-aware/ (https://helloacm.com/large-address-aware/)
Thank you for the clarification.
It is too complicated for me.
Fin
Quote from: finpower on April 10, 2017, 08:10:57 PM
Thank you for the clarification.
It is too complicated for me.
Fin
It's a few clicks, I could instruct my 9yrs old son to do it :)
- Launch Large Address Aware
- Click the three dots on the right hand side of the window
- locate core.exe in you GPBikes folder
- Make sure the check box on step 2 is Ticked!
- Click Save
- Done!
I've been using this a while now and It works great for me. Previous tracks that would run slow now are playable for me :)
I concur... Been using this LAA tool for a while now and works great! Not had an problems with it at all. ;)
Hawk.
Wonder if it will help with cores for online racing???????????
DD
Can't hurt can it?
Using this hack makes us able to load larger tracks and faster, so where is the original limiting factor?
Makes you wonder if this is built on 32bit architecture? (limited to 4gb, this enables more than 4 to be used)
Needs to be tested asap
DD
Quote from: matty0l215 on April 10, 2017, 09:22:33 PM
Makes you wonder if this is built on 32bit architecture? (limited to 4gb, this enables more than 4 to be used)
GPB is 32bits so it won't use more than 4GB by itself no matter what.
But without LAA, it may even be limited to 2GB, including on Win x64 (check the link I posted above, there are the details).
Quote from: HornetMaX on April 10, 2017, 09:38:43 PM
GPB is 32bits so it won't use more than 4GB by itself no matter what.
But without LAA, it may even be limited to 2GB, including on Win x64 (check the link I posted above, there are the details).
I'll be honest, I'm not quite sure what im quite looking at. Bit beyond my knowledge :P
All I know is that with the LAA "hack" in testing we have been able to have a more stable experience with the game.
So couldn't the core.exe be altered to be 64 bit or would this require being re-built completely. Surely this would enable to game to better use resources available (Wasn't one of the issues with a Core.exe crash to do with memory limitations, maybe why we are seeing Memory usage optimization in the daily dev log?)
It's all explained in the link I posted above (https://helloacm.com/large-address-aware/ (https://helloacm.com/large-address-aware/)).
So at least for me, it seems that some crashes (ones before even reaching the track) were due to memory limitations coming from the fact GPB is 32bit: even when running on a x64 Wn, it is limited to 2GB max. Using LAA lifts that to 4GB max.
Ahh. That makes more sense (4gb instead of 2 i mean)
Still, native 64 bit would be better surley?
Quote from: matty0l215 on April 11, 2017, 12:45:52 PM
Ahh. That makes more sense (4gb instead of 2 i mean)
Still, native 64 bit would be better surley?
Yes, native x64 would be better: the limit would be 16.8 million terabytes (aka 16 Exabytes). Or the amount of RAM you have, if you have less than that :)
In practice there are other limitations that seem to put the limit to 8 terabytes, even for x64. I guess we can be happy with much less :)
well, i was excited to read this thread, and promptly went and tried it out.
very mixed results for me so far, i'm afraid - while it definitely seems to cure the core crash side of things - i can switch bikes/tracks back and forth, and so far no crash as before - HOWEVER - i was testing on Mugello track, WSBK 2017 ZX-10R. suddenly, with LAA enabled, the game is virtually unplayable, due to the framerate jumping all over the place - it starts in pitlane and doesn't stop - micro-freeze-up about twice in each corner - totally unplayable.
been tweaking vsync and other settings to see, so far nothing has made any difference.
remove LAA, and the frames are back to the steady 60fps i'm used to, throughout.
as you guys will know, any kind of lag/stutter, no matter how small, in a sim like this, is a deal-breaker, and so far, i'm seeing HUGE stutters.
need to test other tracks still, but that's what i have seen right off the bat, hence the mixed feelings.
i'd rather deal with an in-menu core crash every now and then, than a totally unplayable sim.
maybe it's a system thing - not sure
i5 CPU, 8GB RAM, GTX480 card w 1.5GB, latest .NET and other needed stuff all installed.
@CapeDoc: win version ?
Been running LAA for months - online/offline - complex prototype tracks - no issues at all.
Quote from: HornetMaX on May 08, 2017, 09:14:36 AM
@CapeDoc: win version ?
Win 7 Pro, 64-bit
i wonder if there is maybe an issue with the 2017 WSBK bikes, memory-wise? - i get a core crash whenever loading them on Mugello, for instance.
they load on Victoria, but not Mugello. Mugello gives core crash (on core crash notes, i usually used to actually get a little crash error window previously, i'm sure? in this version, i have yet to see such message. all i get is the game hangs on loading screen usually, and pressing Esc takes me back to desktop.)
with LAA enabled, the 2017 WSBK bikes load fine on all tracks so far, but i just have this totally disabling stutter to go with it.
hang on, let me try and run some other clean-ups, do a reboot and so on, just to make sure. the rig's been on its feet for awhile now, so let me go through the checklist before getting back with more info.
Quote from: CapeDoctor on May 08, 2017, 10:10:25 AM
i wonder if there is maybe an issue with the 2017 WSBK bikes, memory-wise?
Just tried: in the main menu I can switch to the WSBK 2017 class and it loads the aprilia fine (I can also go to track with it), but if in the main menu I switch to any other bike in the same bikeset, I crash instantly (in the main menu).
Quote from: CapeDoctor on May 08, 2017, 10:10:25 AM
Win 7 Pro, 64-bit
i wonder if there is maybe an issue with the 2017 WSBK bikes, memory-wise? - i get a core crash whenever loading them on Mugello, for instance.
Its quite impossible take a core.exe with this set (we have something as 500 laps without 1 single core.exe) so my hint its not use this LAA, its useless because if a track need more 2GB ram in GP Bikes... means that its a bad conversion.
Do you get the same issue with any other bikes on this track?
matty, yes, the first time i encountered this issue (prior to any LAA) was with the 4 WSBK bikes at Mugello track.
change back from them to any other bike, and then it loads fine.
change to Victoria track, then the WSBK bikes load fine.
it does have the feel of some sort of memory issue.
that said, i've also been selecting each and every bike in the menu to change the suits from Legend to Modern for each, cause i keep having to go back to change my armless, backwards facing rider, lol.
so, just to eliminate any other factors -
give me some time to run through the issues thoroughly, so i can report back with better info.
Quote from: Blackheart on May 08, 2017, 10:46:21 AM
Quote from: CapeDoctor on May 08, 2017, 10:10:25 AM
Win 7 Pro, 64-bit
i wonder if there is maybe an issue with the 2017 WSBK bikes, memory-wise? - i get a core crash whenever loading them on Mugello, for instance.
Its quite impossible take a core.exe with this set (we have something as 500 laps without 1 single core.exe) so my hint its not use this LAA, its useless because if a track need more 2GB ram in GP Bikes... means that its a bad conversion.
2GB is the total application allowance for bikes, replay and track. Its not that generous for the track if the plan is to have 24 bikes with very big texture maps and a generous replay file and the track surface is probably one of the most important areas if you want decent physics.
okay, after some basic system tests, a reboot for good measure, and when i tested it this time, WSBK 2017 bike ...Aprilia... Mugello.
and i am happy to report a rock-steady 60fps.
so the issue i had was probably system-related, and not an issue with this LAA tool. :)
Quote from: Blackheart on May 08, 2017, 10:46:21 AM
Quote from: CapeDoctor on May 08, 2017, 10:10:25 AM
Win 7 Pro, 64-bit
i wonder if there is maybe an issue with the 2017 WSBK bikes, memory-wise? - i get a core crash whenever loading them on Mugello, for instance.
Its quite impossible take a core.exe with this set (we have something as 500 laps without 1 single core.exe) so my hint its not use this LAA, its useless because if a track need more 2GB ram in GP Bikes... means that its a bad conversion.
LAA is not a problem (and crash happened before loading any track, so track not an issue either).
After a few tests I'm under the impression that the WSBK 2017 archives on the BikeMOD FTP (not tested the Mega version) are corrupted.
If I install the 4 bikes from IMT Mega db all is fine.
If I install the same 4 bikes from the BikeMOD FTP I get crashes when switching from one bike to the other.
More interesting: if I leave only one of the 4 bikes installed, on some bikes (Duc, MV) I get weird texture problems (e.g. tyre texture on the front disc brake). All this in the main menu.
Could someone else using the FTP Confirm this. If it is true i will re-upload the bikes.
God...
I need know if the bikemod db is the same...
I'm just redownloading the 4 bikes from the FPT to see ... maybe it was syncback not picking up a difference.
(just another argument for having bike mods being passed arounf a single .pkz file)
OK, there're diffs between the BikeMOD ftp and the IMT files:
- Panigale: panigale_fwheel.edf, panigale_rsusp.edf, panigale_rwheel.edf, panigale_steer.edf, panigale_steer_c.edf
- ZX-10R: Kawasaki_ZX-10R_fwheel.edf, Kawasaki_ZX-10R_rwheel.edf
- MV: MV_fwheel.edf, MV_Rwheel.edf
Note: all fine on BikeMOD Mega (no diffs).
I really don't know how this has happened
Unless it was an issue on upload to the FTP. I delete whatever is local to me and download the latest version of a bike from source. That then gets packed for the BikeMOD file or uploaded to the FTP. I don't overwrite and it seems to cause problems.
With the FTP i delete from the FTP first, then upload the new folder. To avoid the same issue of not overwriting.
Could laa be used for server too?
Trying it on GP250 server to see
DD
I can be used on the Server
I belive testing has been done and it proved not to really make any difference. But i may be wrong.
CAWS ran the server with LAA hack, no problems have risen during our event.
Well it seems to use a bit more memory than before so it may help but thanks for the answers guys
DD
is it possible to uninstall this hack somehow? fps are not constant anymore
just open LAA again and deselect core.exe
Oh its that simple lol Thanks DD
I think you select the core exe and then make sure the checkbox is unchecked to tell LAA NOT to do anything when core starts
Just to confirm;
The LAA tool modifies a 1bit flag in thhe program file .exe header stub. This is an existing flag that instructs WOW64, a core windows function that allow windows software to be backwards compatible with newer versions of the OS on how to handle memory allocation for this program (<2GB to simulate pre winXP or up to 4GB for winXP emulation), it is not a hack or exe code modification.
The LAA tool simply SETS (1) or UN-SETS (0) this flag, once set the LAA tool has no other purpose and the .exe runs as normal.
It should be totally harmless if the exe memory allocation is well coded.