Check for NV_DX_interop extension available and fallback mode

[marcotod1410]

At this current time, this control only works if the NV_DX_interop is supported. If the extension is not supported, an AccessViolationException is thrown. This happened to me on a virtual machine where 3D acceleration was enabled via a virtual Mesa graphics card.

I've got the following questions:

• Should we check for the NV_DX_interop extension support before creating the DXGLContext? If so, should we expose a dependency property and/or an event when the initialization fails? Doing so, the control could notify the user about the issue, so that the error can be handled correctly by the application.
• If the extension is not supported, should the library provide a fallback mode for rendering? I was thinking also about the rendering mode used before the NV_DX_interop way was introduced (rendering to an hidden window, then copying the buffer to a WriteableBitmap).

[NogginBops]

I think we should fall back (or at least have the option to fall back) to a version that does that CPU roundtrip if interop is not supported. And making sure the user can query if they got a fast backend or a slow one.

[NogginBops]

Moving this to 4.3.1.

[Krugpelke]

I've had black screen issues with Intel UHD gpus, in those cases software fallback seems to solve the problem, but on some integrated gpus this AccessViolationException completely crashes my application and I've had no success try/catching this. It would be great if it would be possible to at least safely handle cases when this control fails to initialize.

[NogginBops]

@Krugpelke how would you like to handle the initialization error? Should we throw a more specific exception or should we have some other way of handling this?

[Krugpelke]

Personally, I'm completely fine with throwing an exception in how it's currently implemented in 4.3.1, it should work as long as NV_DX_interop is safely handled. Actually, disregard my previous comment about DxGlContext constructor crashing, I was thinking about 4.2.3, previously I would crash in DxGLFramebuffer constructor on var genHandle = Wgl.DXRegisterObjectNV(context.GlDeviceHandle, dxRenderTargetHandle, (uint)GLSharedTextureHandle, (uint)TextureTarget.Texture2D, WGL_NV_DX_interop.AccessReadWrite). In 4.3.1, however, the crash happens in DxGlContext Dispose on Wgl.DXCloseDeviceNV(DxDevice.Handle), this dispose is getting called from the finalizer for some reason, the exception for clarity is:

Exception thrown at 0x00007FFD2A857BCC (nvoglv64.dll) in Application.exe: 0xC0000005: Access violation reading location 0x000001E35169A5EE.
An unhandled exception of type 'System.AccessViolationException' occurred in OpenTK.Graphics.dll
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

[NogginBops]

With 67129a3 I've added a PlatformNotSupportedException when WGL_NV_DX_interop can't be found. We can implement the fallback mode in 4.3.3.