Verify if the adapter is available in RenderingContextDriverD3D12::_initialize_devices

[scgm0]

Fix #112282

According to Microsoft's documentation, when the ppDevice parameter of D3D12CreateDevice is null, it can verify whether a device can be created without actually creating one. Therefore, it should be possible to use this method to determine if an adapter is truly available.

Although I'm not entirely sure if my code is correct, I have conducted simple tests on both a Windows 11 virtual machine and a physical machine. Now, it correctly triggers rendering fallback in the virtual machine, and the physical machine can also use d3d12 normally.

It's still uncertain what impact this has on performance.

[blueskythlikesclouds]

Code make sense to me, but the device initialization process warrants a refactor to fix #98207 anyway, which would also naturally handle your issue. It's better if we can avoid the D3D12 runtime validating the adapter twice.

[scgm0]

Code make sense to me, but the device initialization process warrants a refactor to fix #98207 anyway, which would also naturally handle your issue. It's better if we can avoid the D3D12 runtime validating the adapter twice.

It appears that some functionalities can only be verified after the device is created. The solutions are either to move the actual logic of device initialization to RenderingContextDriverD3D12 for verification, or to add minimal device initialization code in RenderingContextDriverD3D12 for validation purposes.

So, should I close this PR and wait for the refactoring, or can we merge this PR first and then proceed with the refactoring?

[blueskythlikesclouds]

It can stay open, I'm still planning how to go with the refactor.

[scgm0]

It can stay open, I'm still planning how to go with the refactor.

I hope to complete this as soon as possible, as several users have reported that they cannot run my application because their computers do not support DirectX 12.
The reason I did not default to OpenGL3 is that some users' computers only support DirectX 12 and not OpenGL3. Therefore, I changed the default rendering driver to DirectX 12 and am relying on the rendering fallback feature.

[clayjohn]

The reason I did not default to OpenGL3 is that some users' computers only support DirectX 12 and not OpenGL3.

Devices that only support D3D12 should automatically fall back from OpenGL to ANGLE. Do you have any more information about those devices so we could investigate further? I am assuming they are Snapdragon based ARM laptops?

[scgm0]

The reason I did not default to OpenGL3 is that some users' computers only support DirectX 12 and not OpenGL3.

Devices that only support D3D12 should automatically fall back from OpenGL to ANGLE. Do you have any more information about those devices so we could investigate further? I am assuming they are Snapdragon based ARM laptops?

In fact, that user has an x86-64 Windows 10 computer with an AMD Radeon (TM) R9 Fury Series graphics card. I don't remember more details, but I recall from the information I looked up at the time that the user's computer hardware should support OpenGL 3, and it might be an issue with him drivers.