D3D11 - Fix for AMD-based CPUs with built-in graphics. IsRHIDeviceAMD might be integrated grapihcs or a discrete GPU. Just get the budget from the OS via IDXGIAdapter3. Fall back to the original calculation method if the interface for IDXGIAdapter3 does not exist (e.g. Win7).
#rb Jason.Stewart
[FYI] Chris.Bunner
#rnx
#jira
#ROBOMERGE-SOURCE: CL 12898017 via CL 12898088 via CL 12898094 via CL 12898112 via CL 12898125
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v681-12776863)
[CL 12898140 by rolando caloca in Main branch]
use -nocrashdebugging to disable.
#rb rolando.caloca
#jira none
#ROBOMERGE-SOURCE: CL 12861781 in //UE4/Release-4.25/... via CL 12861847 via CL 12861868
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v681-12776863)
[CL 12861916 by jonas meyer in Main branch]
#rb Ethan.Geller, Aaron.Mcleran, Rob.Gay, Maxwell.Hayes, Phil.Popp
[FYI] ethan.geller
#ROBOMERGE-SOURCE: CL 12826047 via CL 12826127 via CL 12826139
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v681-12776863)
[CL 12826160 by jimmy smith in Main branch]
[FYI] Jimmy.Smith
#ROBOMERGE-SOURCE: CL 12687512 via CL 12687514 via CL 12687517
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12687521 by bob tellez in Main branch]
[FYI] Jimmy.Smith
#ROBOMERGE-SOURCE: CL 12687159 via CL 12687168 via CL 12687178
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12687197 by bob tellez in Main branch]
#rb aaron.mcleran
#ROBOMERGE-SOURCE: CL 12680734 via CL 12680742 via CL 12680743
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12680746 by jimmy smith in Main branch]
#rb ethan.geller, aaron.mcleren
#ROBOMERGE-SOURCE: CL 12680724 via CL 12680731 via CL 12680735
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12680741 by jimmy smith in Main branch]
-Hololens was set up to do extended execution rather than suspend/resume as a workaround to a very old long since fixed sdk bug.
-Now it can suspend/resume correctly.
-Sleep still forces an app restart on PC, because we do not support suspend/resume with remoting.
-The D3D Trim on suspend is PLATFORM_HOLOLENS out of an abundance of caution. It may well be correct for windows as well, but if its wrong the result will be hitches in d3d operations when resuming, which seems tricky.
#rb Steve.Smith
#jira UE-91648
#lockdown nick.whiting
#ROBOMERGE-SOURCE: CL 12675971 in //UE4/Release-4.25/... via CL 12675982 via CL 12675988
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12675993 by jeff fisher in Main branch]
[FYI] jens.petersam
#ROBOMERGE-SOURCE: CL 12666538 via CL 12666546 via CL 12666548 via CL 12666552 via CL 12666559 via CL 12666561
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12666569 by chris adams in Main branch]
This would cause DXGI_ERROR_INVALID_CALL, which would cause the engine to halt.
#rb steve.smith
#jira UE-86278
#ROBOMERGE-SOURCE: CL 12657314 in //UE4/Release-4.25/... via CL 12657317 via CL 12657320
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12657324 by jonas meyer in Main branch]
#rb ethan.geller, aaron.mcleran
#ROBOMERGE-SOURCE: CL 12585286 via CL 12585288 via CL 12585290 via CL 12586679 via CL 12586694 via CL 12586715
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12586762 by jimmy smith in Main branch]
theory is this happens for users with multiple adapters, where not all of them support ALLOW_TEARING
#rb none
#ROBOMERGE-SOURCE: CL 12531858 via CL 12531868 via CL 12532702 via CL 12532798 via CL 12532904
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v673-12478461)
[CL 12533127 by jonas meyer in Main branch]
- Integrate new NvAftermath version which supports GPU Crash minidumps now
- Refactor GPU crash handling on D3D12 to unify multiple crash paths (use exception handling when GPU minidump is created to make sure it properly saved)
- Cleanup error reporting on GPU crash
- Make sure only one thread will log and show error messages
#rb Emil.Person
#ROBOMERGE-SOURCE: CL 12508032 via CL 12508036 via CL 12508040
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v673-12478461)
[CL 12508050 by kenzo terelst in Main branch]
Use
-gpupreference=1 to prefer minimum power
-gpupreference=2 to prefer highest performance
Default is 2. Any other value causes it to fallback to old code.
upgrade dxgi to latest
#jira UE-64085
#rb none
#ROBOMERGE-SOURCE: CL 12387036 in //UE4/Release-4.25/... via CL 12387039
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v671-12333473)
[CL 12387041 by jonas meyer in Main branch]
Use
-gpupreference=1 to prefer minimum power
-gpupreference=2 to prefer highest performance
Default is 2. Any other value causes it to fallback to old code.
upgrade dxgi to latest
#jira UE-64085
#rb none
[CL 12387036 by Jonas Meyer in 4.25 branch]
The driver extension functions just set an internal flag which is processed on the next dispatch, so doing an end/begin is just a no-op. In order to correctly break up an overlap group, RHIBeginUAVOverlap() must remember that overlap was requested, and actually call the driver extension function after the next draw or dispatch.
Also removed the attempted UAV "barrier" from FD3D11DynamicRHI::RHITransitionResources(). This didn't do anything because of the above bug, but if it did, it would have prevented overlap from occurring in many valid cases, because we don't track which UAVs are actually written by the previous dispatches in a group. The D3D11 RHI must not try to interpret transitions for breaking up overlap groups; it's up to the caller to ensure that the begin/end calls wrap dispatches which are safe to overlap, and must also use transitions for the RHIs which support barriers, where begin/end overlap has no effect.
#rnx
#rb Jonas.Meyer
#jira none
#ROBOMERGE-SOURCE: CL 12242226 in //UE4/Release-4.25/... via CL 12242249
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v667-12241502)
[CL 12242283 by mihnea balta in Main branch]
The driver extension functions just set an internal flag which is processed on the next dispatch, so doing an end/begin is just a no-op. In order to correctly break up an overlap group, RHIBeginUAVOverlap() must remember that overlap was requested, and actually call the driver extension function after the next draw or dispatch.
Also removed the attempted UAV "barrier" from FD3D11DynamicRHI::RHITransitionResources(). This didn't do anything because of the above bug, but if it did, it would have prevented overlap from occurring in many valid cases, because we don't track which UAVs are actually written by the previous dispatches in a group. The D3D11 RHI must not try to interpret transitions for breaking up overlap groups; it's up to the caller to ensure that the begin/end calls wrap dispatches which are safe to overlap, and must also use transitions for the RHIs which support barriers, where begin/end overlap has no effect.
#rnx
#rb Jonas.Meyer
#jira none
[CL 12242226 by mihnea balta in 4.25 branch]
[FYI] Peter.Sauerbrei,Chris.Bunner
#ROBOMERGE-OWNER: jian.ru
#ROBOMERGE-AUTHOR: jian.ru
#ROBOMERGE-SOURCE: CL 12126084 via CL 12126339 via CL 12132576
#ROBOMERGE-BOT: (v659-12123632)
[CL 12132633 by jian ru in Main branch]
