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
    Anyone still having this issue in 4.20.2? I simply open a blank project and turn on show FPS in the default level and my FPS fluctuates, I have also delete the dll mentioned above and still the issue persists.

    Leave a comment:


  • replied
    FYI
    The way I solved the stutter on 4.19.2:
    - close UE4
    - in your project folder, in Config\DefaultEngine.ini, under [/Script/Engine.RendererSettings]: add the line "r.gpucrashdebugging=False"
    - start UE4, open your project, build all and package your game
    - in the packaged game folder delete (or rename) Packaged\WindowsNoEditor\Engine\Binaries\ThirdParty\NVIDIA\NVaftermath\Win64\GFSK_Aftermath_Lib.x64.dll

    Leave a comment:


  • replied
    Originally posted by John Alcatraz View Post

    You really need to ship that source, I couldn't imagine working on any project without modifying the engine source, and of course I'd like to use your plugin, but I'm waiting for years now that you fix that. Theres almost no other UE4 plugin that limits you like that to launcher builds.
    Yes true. I believe it shouldn't be a problem as software IP (should) are contained in the dll (in this case IKinema DLL). Therefore, integration code should be given out as it is just integration and contains no IK specific code.

    Leave a comment:


  • replied
    Originally posted by razmaz51 View Post
    in 4.19 got a packaging error after deleting the aftermath dll and disabling it ---------------------------ERROR: Failed to copy D:\UE_4.19\Engine\Binaries\ThirdParty\NVIDIA\NVaftermath\Win64\GFSDK_Aftermath_Lib.x64.dll to D:\unreal projects\Shoot\Saved\StagedBuilds\WindowsNoEditor\Engine\Binaries\ThirdParty\NVIDIA\NVaftermath\Win64\GFSDK_Aftermath_Lib.x64.dll

    After deleting the files, make sure you run GenerateProject.bat, then open, clean, recompile?
    Worked for me, if that helps

    Leave a comment:


  • replied
    in 4.19 got a packaging error after deleting the aftermath dll and disabling it ---------------------------ERROR: Failed to copy D:\UE_4.19\Engine\Binaries\ThirdParty\NVIDIA\NVaftermath\Win64\GFSDK_Aftermath_Lib.x64.dll to D:\unreal projects\Shoot\Saved\StagedBuilds\WindowsNoEditor\Engine\Binaries\ThirdParty\NVIDIA\NVaftermath\Win64\GFSDK_Aftermath_Lib.x64.dll

    Leave a comment:


  • replied
    Originally posted by Waurelius View Post
    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!


    Hi There, i see 4.20 is out now, and the release logs state this:
    • New: Added support for NVIDIA Aftermath to be enabled by default.


      So, has this been disabled/fixed in the current new 4.20 release?


      Cheers!

    Leave a comment:


  • replied
    Thing i dont get is i been using 4.19 for quite a while now and this just started in the last day or so.

    Leave a comment:


  • replied
    Originally posted by Simon-IKinema View Post

    With indie we don't ship our integration source which means you can't rebuild the plugin binaries out of the box. The good news is we have the 4.20 update ready to go - just waiting on the official release so users wont have to hang around to update your engine.
    You really need to ship that source, I couldn't imagine working on any project without modifying the engine source, and of course I'd like to use your plugin, but I'm waiting for years now that you fix that. Theres almost no other UE4 plugin that limits you like that to launcher builds.
    Last edited by John Alcatraz; 07-14-2018, 01:47 PM.

    Leave a comment:


  • replied
    Originally posted by TheJamsh View Post
    Amazing that the team found a workaround this quickly. Goes to show what a good repro project can do.



    Can you not compile the plug-in yourself in this instance? If not, 4.20 is probably just around the corner, so hopefully you can move versions easily.
    With indie we don't ship our integration source which means you can't rebuild the plugin binaries out of the box. The good news is we have the 4.20 update ready to go - just waiting on the official release so users wont have to hang around to update your engine.

    Leave a comment:


  • replied
    Amazing that the team found a workaround this quickly. Goes to show what a good repro project can do.

    Originally posted by StickySnoutStd View Post
    IKinema plugin.
    Can you not compile the plug-in yourself in this instance? If not, 4.20 is probably just around the corner, so hopefully you can move versions easily.

    Leave a comment:


  • replied
    Originally posted by Waurelius View Post
    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!

    Thank you VERY much, been waiting for this.
    That's great news that it will be fixed in 4.20.

    Leave a comment:


  • replied
    Originally posted by Waurelius View Post

    Yes this should work as well. You may have to force a rebuild if UBT doesn't pick up the modification for some reason.
    Sadly i cant make engine changes because im relying on IKinema plugin. But as i read ur description its fixed in 4.20 and the most recent test i did with 4.20p5 with all Ikinema plugin functionaly disabled, it seemed to run smooth as it should.

    Leave a comment:


  • replied
    There seems to be a bug. It is using:


    Code:
    void FD3D11DynamicRHIModule::StartupModule()
    {
    #if NV_AFTERMATH
        // Note - can't check device type here, we'll check for that before actually initializing Aftermath
    
            FString AftermathBinariesRoot = FPaths::EngineDir() / TEXT("Binaries/ThirdParty/NVIDIA/NVaftermath/Win64/");
            if (LoadLibraryW(*(AftermathBinariesRoot + "GFSDK_Aftermath_Lib.x64.dll")) == nullptr)
            {
                UE_LOG(LogD3D11RHI, Warning, TEXT("Failed to load GFSDK_Aftermath_Lib.x64.dll"));
                GDX11NVAfterMathEnabled = 0;
                return;
            }
            else
            {
                UE_LOG(LogD3D11RHI, Log, TEXT("Aftermath initialized"));
                GDX11NVAfterMathEnabled = 1;
            }
    
    #endif
    }
    But LoadLibraryW is documented as requiring backslashes:

    https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

    Under "Remarks" it tells a complicated alternate search it will do if given a relative path that fails.

    UE4 should maybe be using: IPlatformFile::ConvertToAbsolutePathForExternalAppForRead instead here?

    Leave a comment:


  • replied
    Originally posted by John Alcatraz View Post

    Shouldn't it be enough to only change

    if (Target.Platform == UnrealTargetPlatform.Win64)

    to

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

    In NVaftermath.build.cs?
    Yes this should work as well. You may have to force a rebuild if UBT doesn't pick up the modification for some reason.

    Leave a comment:


  • replied
    StickySnoutStd I would expect the LoadLibrary call to simply fail silently rather than crash but changing the code via my or John Alcatraz 's method should also work.

    Leave a comment:

Working...
X