Direct3D12 UWP Game DR (C++/WinRT) template generated code crashes

[ghost]

Current system configuration: Windows 10 17763.134 Visual Studio 2017 15.9.2 Direct3DUWPGame VSIX version 6.3 Graphics Intel HD 4600 and NVIDIA GeForce GT 755M (optimus technology) with latest drivers from Intel and NVIDIA.

Note: I have been observing this error since very early days of Creator's update. I thought by this time this issue will be resolved but it hasn't.

I compile and run the default generated code in 32-bit debug build and resize the window continuously until it crashes and observe the following messages in output window

log.txt

DXGI ERROR: IDXGISwapChain::GetContainingOutput: The swapchain's adapter does not control the output on which the swapchain's window resides. [ MISCELLANEOUS ERROR #80: ] ... repeated message above too many times DXGI ERROR: IDXGISwapChain::ResizeBuffers: Swapchain cannot be resized unless all outstanding buffer references have been released. [ MISCELLANEOUS ERROR #19: ] Exception thrown at 0x76BAAB32 in Direct3D UWP Game1.exe: Microsoft C++ exception: DX::com_exception at memory location 0x0314CE90. Exception thrown at 0x76BAAB32 in Direct3D UWP Game1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000. Exception thrown at 0x76BAAB32 (KernelBase.dll) in Direct3D UWP Game1.exe: WinRT originate error - 0x80004005 : 'Failure with HRESULT of 887A0001'.

I see the DXGI Error message with Direct3D 11 but for some reason it does not seem to crash. Direct3D12 code crashes easily.

[walbourn]

The only place I use GetContainingOutput is in the DeviceReources function UpdateColorSpace which I handle failure gracefully, so I think that debug output might be noise. That said, the only report of this has been when using WARP12.

Can you confirm you are actually running on a HARDWARE device with DirectX 12 instead of a WARP12 device? Look in the debug output:

Direct3D Adapter - WARP12

or

Direct3D Adapter (%u): VID:%04X, PID:%04X - %ls

[ghost]

I am using the most up-to-date and patched version of Windows 10 SDK (10.0.17763.0) on real H/W

Direct3D Adapter (0): VID:10DE, PID:0FCD - NVIDIA GeForce GT 755M

Complete Debug output log https://github.com/walbourn/directx-vs-templates/files/2606169/log.txt

Note: You need a laptop that has NVIDIA optimus technology to repro this issue. The display is controlled by Intel HD 4600 but dynamically the DirectX processing is offloaded to GeForce GT 755M as can be seen from the debug output

[walbourn]

The DeviceResources implementation is using the new IDXGIFactory6::EnumAdapterByGpuPreference method to prefer the NVIDIA over the Intel on your system. You can try commenting out that code block in your DR to see if it avoids the problem. By design the new API is supposed to provide a supported way to prefer the full-power GPU.

As I said, the noise from the GetContainingOutput method might just need to be suppressed in the code at the top of DeviceResources::CreateDeviceResources as this could just be a quirk (one of many) for the NVIDIA optimus technology.

I'm more concerned about the 'not yet released' issue in ResizeBuffers because to my knowledge I've released them all at that point.

[ghost]

OK I modified the function void DeviceResources::CreateDeviceResources() to comment the call to GetAdapter and pass nullptr directly to D3D12CreateDevice() as follows..

ComPtr<IDXGIAdapter1> adapter;
//GetAdapter(adapter.GetAddressOf());

// Create the DX12 API device object.
ThrowIfFailed(D3D12CreateDevice(
    nullptr, //adapter.Get(),
    m_d3dMinFeatureLevel,
    IID_PPV_ARGS(m_d3dDevice.ReleaseAndGetAddressOf())
    ));

With this change the app selects GPU 0 i.e. Intel, the resizing horribly and exceptionally slow with too much lag but it never crashes. Now I tried to override the adapter by going to settings and selecting high performance (See attached screenshot) and I still have a crash. See log.

Default Adapter Crash.txt

[walbourn]

What Windows 10 SDK are you building against?

[ghost]

Windows 10 SDK (10.0.17763.0)

[walbourn]

So the core problem here is that the UWP ResizeStarted and ResizeCompleted events have regressed. I'm no longer getting the events, so I'm not able to avoid the dozens of resizes per second. I've asked for investigation on this from the Windows team.

The GetContainingOutput message is just noise that should be suppressed, so I've added that in this commit

[ghost]

As initially commented I am seeing this issue since Creator's update. Also why does this happen only with DX12 ?
Anyway let me know if you want me to do any experimentation stuff at my end. I am currently sticking to DX11 for my UWP app development for simplicity but in future I might want to use DX12.

[walbourn]

The ResizeStarted event behavior is missing for both DX11 & DX 12, which is the direct solution for the 'slow resize' problem. This was apparently regressed in the Windows 10 (October 2018; build 17763) release, so they are looking at that.

Now as to the problem you are seeing with ResizeBuffers failing, I'm beginning to think that is an NVIDIA bug. I can't reproduce it on any system other than an NVIDIA Optimus laptop.

[ghost]

I am an ex-NVIDIA employee and I worked in their chipset division developing kernel drivers on Windows long ago. 16+ years I have developed windows kernel drivers.

I had reported a BSOD to NVIDIA few months back caused by their GFX driver related to power events. I could not start my laptop as it immediately crashed every time and I had to reformat my laptop and restore it with an old driver. They could not repro but after I asked them to try out Optimus system they were able to repro. They took 1 month to fix the issue.

Based on my exp I don't think I can file this issue with them. They will redirect me back to you guys. I wonder if there should be some new WHQL tests to catch such issues (ResizeBuffers failing).