Repair WindowsDX tests
Closed this issue · 4 comments
Since we moved to newer .NET runtimes and NUnit versions, WindowsDX tests are failing due to Direct3D/Winforms not working in that context. Non-graphical tests work normally.
We need to figure out what prevents them from initializing a Direct3D context and fix that.
Any help welcome.
So I created a Draft PR #8151 that actually has the tests passing again, however not in an ideal or probably recommended way. Wanted to provide some information about what I've run into and tried. Assuming someone more familiar with SharpDX or the WindowsDX code in MonoGame may have some better ideas about what is going on.
- This problem exists in the Master branch today as well. Rolling back versions of .NET, NUnit, and various other things did not seem to make much impact. The issue is still happening on the .NET 6 code even (unless this has been broken for a long time!)
- The Issue appears to be happening on GraphicsDevice.DirectX.cs when creating the Direct3D device via the SharpDX.Direct3D11.Device(driverType, creationFlags, featureLevels) constructor. Whenever you pass a driverType of Reference it throws this issue: SharpDXException: HRESULT: [0x887A0004], Module: [SharpDX.DXGI], ApiCode: [DXGI_ERROR_UNSUPPORTED/Unsupported], Message: The specified device interface or feature level is not supported on this system. If I simply disable the code in the TestGameBase.cs that sets UseReferenceDevice to true and make it use driverType Hardware all of the tests start passing again. Obviously the Reference device is supposed to be fully featured, and the ideal way to do testing. It bypasses a bunch of inconsistencies and unreliability of testing on different hardware, but it does not seem to be working currently.
- I did for giggles try a half baked upgrade of SharpDX to 4.2.0 and got about 50% there where the code could at least build and the tests could run. I was still seeing the fast device creation failures on tests that were not even impacted by the breaking API changes that were not fully fleshed out. Could be user error, but that did not seem to fix the issue.
I am not as familiar with how the Reference device creation worked via debugging prior to when the tests stopped working. Nor I am super familiar with SharpDX. While I can try to find some time to dig in a bit more, and get a better idea of what is happening I wanted to at least share some info. Anyone that has better ideas on how to fix this feel free to jump in or make suggestions!
Thank you for looking into this!
Ah! The reference driver is a software renderer for Direct3D, it is indeed meant to test accuracy and is very slow.
Microsoft has 2 software renderers: the "REF" driver, and WARP.
We might want to test using WARP by setting GraphicsAdapter.UseDriverType = DriverType.FastSoftware right after UseReferenceDevice = true; to see if it changes anything (mind that setting UseReferenceDevice after UseDriverType will reset UseDriverType back to using REF).
But my guess is that it won't change anything. From what I'm reading, WARP has replaced REF since Windows 10 and they are one and the same now.
Also, WARP needs the Windows SDK to be installed in order to work. That's maybe where the error is (but it doesn't explain why it doesn't work on the Github Runner since the Windows SDK is preinstalled there).
Okay, I tested using WARP, and it works, all the tests pass correctly with good accuracy.
REF indeed doesn't work at all. So my guess is that Microsoft actually removed REF entirely and has not made REF to WARP unlike what I read about that.
So just adding GraphicsAdapter.UseDriverType = DriverType.FastSoftware to your PR should do the trick!
Awesome! Makes sense. I have made the changes in a new PR. My previous one was getting a bit messy.