Announcement

Collapse
No announcement yet.

4.19 & 4.20 Editor & Packaged Games Have Hangs/Hiccups Constantly

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by Waurelius View Post
    Note that you'll need to do the .ini change AND the code change ( or just delete the dll ). As it's a bit of janky double-init logic in there for Aftermath.
    Shouldn't it be enough to only change

    if (Target.Platform == UnrealTargetPlatform.Win64)

    to

    if (Target.Platform == UnrealTargetPlatform.Win64 && false)

    In NVaftermath.build.cs?
    Last edited by John Alcatraz; 07-11-2018, 04:23 PM.

    Leave a comment:


  • replied
    Originally posted by StickySnoutStd View Post
    Im on 4.19.2, and tried the workaround with setting the Engine/Config/BaseEngine.ini r.gpucrashdebugging = False AND deleting the GFSDK_Aftermath_Lib.x64.dll from Binaries/ThirdParty/NVIDIA/NVaftermath/Win64/ i restarted my PC and now whenever i open my project, the engine crashes immediately, if i just start the engine to make a blank project, it crashes too. What may i have done wrong?
    for 4.19.2 it is necessary changes at the source code: "GDX11NVAfterMathEnabled to 0 in FD3D11DynamicRHIModule::StartupModule"

    Leave a comment:


  • replied
    On the other hand, i tried 4.20 and there it seem to run absolutely perfect, only problem i have, is that i rely on some thirdparty plugin that is obv. not updated to 4.20 yet, but it looks like this could solve it for me too.

    Leave a comment:


  • replied
    Im on 4.19.2, and tried the workaround with setting the Engine/Config/BaseEngine.ini r.gpucrashdebugging = False AND deleting the GFSDK_Aftermath_Lib.x64.dll from Binaries/ThirdParty/NVIDIA/NVaftermath/Win64/ i restarted my PC and now whenever i open my project, the engine crashes immediately, if i just start the engine to make a blank project, it crashes too. What may i have done wrong?

    Leave a comment:


  • replied
    Waurelius Can confirm that extinguishing Aftermath deals with the issue (398.36, 4.19.2)
    Thanks and looking forward to it being fixed.

    Leave a comment:


  • replied
    Waurelius Thanks for the tip! Totally works.

    Time Since Boot: 20.98 Seconds

    Platform Memory Stats for Windows
    Process Physical Memory: 851.90 MB used, 878.93 MB peak
    Process Virtual Memory: 1136.92 MB used, 1207.85 MB peak
    Physical Memory: 5905.68 MB used, 10426.95 MB free, 16332.62 MB total
    Virtual Memory: 6074.63 MB used, 10426.95 MB free, 134217728.00 MB total


    Time Since Boot: 175.87 Seconds

    Platform Memory Stats for Windows
    Process Physical Memory: 852.74 MB used, 878.93 MB peak
    Process Virtual Memory: 1137.39 MB used, 1207.85 MB peak
    Physical Memory: 5876.44 MB used, 10456.18 MB free, 16332.62 MB total
    Virtual Memory: 6050.56 MB used, 10456.18 MB free, 134217728.00 MB total

    Seriously many thanks for tracking this down. Opened up the particle map and the stutter was gone as well. Haven't done a long test yet, but I'm confident.

    Just to confirm 4.19.2 with the .ini change and I just backed up the .dll and deleted it.

    Leave a comment:


  • replied
    Note that you'll need to do the .ini change AND the code change ( or just delete the dll ). As it's a bit of janky double-init logic in there for Aftermath.

    Leave a comment:


  • replied
    spazfirem I took a look back and the .ini change I suggested is NOT sufficient for 4.19. Looks like 4.19 had a bug with the Aftermath initialization code that is kinda forcing it on. We straightened all that out in 4.20. Sorry about that, I hadn't realized that was going on. If you look in the log you will see "Aftermath enabled and primed" which indicates that it's on. Looks like for a binary release the only way to really kill it would be to delete the GFSDK_Aftermath_Lib.x64.dll from Binaries/ThirdParty/NVIDIA/NVaftermath/Win64/. If you can make code changes, then then forcing GDX11NVAfterMathEnabled to 0 in FD3D11DynamicRHIModule::StartupModule should resolve it.

    Leave a comment:


  • replied
    Should the fix work in 4.19.2? I just tried and noticed no change :/ Below is the info from Dethrey's project with the render targets. (verified that r.gpucrashdebugging is 0, ran in standalone game)

    Time Since Boot: 20.23 Seconds

    Platform Memory Stats for Windows
    Process Physical Memory: 889.68 MB used, 926.53 MB peak
    Process Virtual Memory: 1177.03 MB used, 1226.25 MB peak
    Physical Memory: 5499.68 MB used, 10832.95 MB free, 16332.62 MB total
    Virtual Memory: 6117.48 MB used, 10832.95 MB free, 134217728.00 MB total


    Time Since Boot: 182.32 Seconds

    Platform Memory Stats for Windows
    Process Physical Memory: 1264.52 MB used, 1681.52 MB peak
    Process Virtual Memory: 1552.15 MB used, 1970.98 MB peak
    Physical Memory: 5823.97 MB used, 10508.65 MB free, 16332.62 MB total
    Virtual Memory: 6473.42 MB used, 10508.65 MB free, 134217728.00 MB total


    I also still had the original particle test project with the mesh emitters laying around and noticed the hitch within a minute or so.

    Leave a comment:


  • replied
    Hey folks. We've been investigating this for a while with some help from Nvidia and have determined many of these leaks and hitches can be attributed to a bug in Aftermath that was exposed by a change in the way we render certain things. For the moment in 4.20 we will be disabling Aftermath by default ( you can still enable it manually if you need it ). The change is a simple one in Engine/Config/BaseEngine.ini to set r.gpucrashdebugging to False. I've confirmed that this fixes the leak (and so far in my soak the hitching) in Deathrey's project. If anyone is interested in testing this fix, make the change I mentioned then reboot your machine just to be sure, and run your projects again. You can confirm Aftermath is disabled in the log, or just by checking the state of 'r.gpucrashdebugging' via the console. (It should be 0). If anyone STILL sees a leak or hitching please report back as it's likely a separate but similar issue. Thanks to everyone in this thread for helping us track this down!
    Last edited by Waurelius; 07-11-2018, 11:40 AM. Reason: typo

    Leave a comment:


  • replied
    Originally posted by Ninjin View Post

    Sure, but if the new driver versions are also not working and you are silent about the whole situation, even if the most popular twitch streamers experience the same issue on Fortnite and restart their whole game after a couple of matches, it gets frustrating. Overwatch had a driver issue that took them more than half a year to fix if not longer, but they at least gave an announcement and told users which latest driver version they should download. Instead some of the more experienced users have to invest time and find out which version is working. Then all other people have to read the forum and find out on which page someone said something about a version that seems to work. Besides, Blizzard asked the community for logs and their hardware. I understand it's ludicrous to check every hardware setup, but with the data collected the least you can check is the most common setup that has the problem. All in all, it just gives the impression epic is doing nothing the whole time or they miraculously are the only ones who don't have this problem.

    (Also, I mentioned Fotnite and I know nobody can tell if their problem is correlated to the engine and how many smaller issues contribute to the leak, fact is, since march/april or something the engine and Fortnite are leaking concerning amount of memory on the newest 1060 drivers (which is the most used graphics card according to Steam data) for me and enough other people to give at least a post about it)
    It is always communicated to the manufacturers ie Nvidia - it is not silent. Or smallish engine developer will just watch the communication and decides to blacklist the driver etc. It is not unusual.

    Leave a comment:


  • replied
    Just to add to this thread, got a heads up that an issue I'm having could be somewhat related: getting constant hitches when enabling motion blur on mesh particles, video here for context: https://youtu.be/HPPuSYPHZ5o

    Also can confirm that closing the editor and reopening seems to reset the issue temporarily, but the longer it is open, the more obvious the issue gets.

    On freshly opening the editor, I have constant stable 120FPS with a particle system running with thousands of mesh pieces. Then even 10 minutes later, the issue becomes so bad that same particle system is dipping from 120 down to 10FPS or lower with extremely obvious hitches lasting for what seems like almost a second of half second each.

    Hopefully a fix is on the way!
    Last edited by EoinOBroin; 07-10-2018, 10:34 PM.

    Leave a comment:


  • replied
    Originally posted by Syed View Post
    I have read somewhere that game engine developer often stumble upon quirky driver issue - they will not do certain things correctly, and the sane thing to do is to simple do the 'if driver_version == xxxx' then do this.. Some drivers simply lie their capabilities and they get parsed in the 'if blocks' too...
    Sure, but if the new driver versions are also not working and you are silent about the whole situation, even if the most popular twitch streamers experience the same issue on Fortnite and restart their whole game after a couple of matches, it gets frustrating. Overwatch had a driver issue that took them more than half a year to fix if not longer, but they at least gave an announcement and told users which latest driver version they should download. Instead some of the more experienced users have to invest time and find out which version is working. Then all other people have to read the forum and find out on which page someone said something about a version that seems to work. Besides, Blizzard asked the community for logs and their hardware. I understand it's ludicrous to check every hardware setup, but with the data collected the least you can check is the most common setup that has the problem. All in all, it just gives the impression epic is doing nothing the whole time or they miraculously are the only ones who don't have this problem.

    (Also, I mentioned Fotnite and I know nobody can tell if their problem is correlated to the engine and how many smaller issues contribute to the leak, fact is, since march/april or something the engine and Fortnite are leaking concerning amount of memory on the newest 1060 drivers (which is the most used graphics card according to Steam data) for me and enough other people to give at least a post about it)
    Last edited by Ninjin; 07-04-2018, 04:05 PM.

    Leave a comment:


  • replied
    I have read somewhere that game engine developer often stumble upon quirky driver issue - they will not do certain things correctly, and the sane thing to do is to simple do the 'if driver_version == xxxx' then do this.. Some drivers simply lie their capabilities and they get parsed in the 'if blocks' too...

    Leave a comment:


  • replied
    Any idea why they only blacklisted those, and not all newer ones?

    Leave a comment:

Working...
X