Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intel Xe graphics driver does not support depth/stencil buffer in d3d9 #149

Open
Xerxes004 opened this issue Dec 17, 2024 · 5 comments
Open

Comments

@Xerxes004
Copy link

Xerxes004 commented Dec 17, 2024

As mentioned in #138, Intel integrated graphics does not support MSAA. After some experimentation on a newer machine, the newer integrated graphics also do not support the call to NativeCreateDepthStencilSurface in this call:

public void CreateDepthStencilSurface(int width, int height, Format format, MultisampleType multisample, int multisampleQuality, bool discard, out IDirect3DSurface9 surfaceHandle, ref IntPtr sharedHandle)
{
NativeCreateDepthStencilSurface method = Marshal.GetDelegateForFunctionPointer<NativeCreateDepthStencilSurface>((*VTable)->CreateDepthStencilSurface);
int result = method(this, width, height, format, multisample, multisampleQuality, discard, out surfaceHandle, ref sharedHandle);
CheckHResult(result);
}

The example app crashes when switching to any tab with a GL control with an "INVALID ARGS" error.

Disabling the call to CreateDepthStencilSurface and checking for a null ptr in IDirect3DSurface9.Release fixes the issue, and the GL control renders properly.

On another, older machine running W10 + Intel i5-10400, the call does not throw an error BUT the depth buffer definitely does not work, and I have to create a new framebuffer + depth/stencil attachment for depth to be processed correctly.

From what I can gather, Intel no longer supports d3d9, and relies on D3D9On12 for the API. From what I can gather, the ball is out of Intel's court on this one.

Likely workaround:

Only use d3d9 render target surface, and use the OpenGL API to set up a new "default" framebuffer. This breaks the convention of having depth enabled by default, but it will only effect Intel integrated graphics users.

Device specs:

Intel(R) Core(TM) i9-14900K
Intel UHD Graphics 770 (31.0.101.4953)
Windows 11 Pro

@Xerxes004
Copy link
Author

Xerxes004 commented Dec 17, 2024

I updated my drivers to 32.0.101.6079, and now I have an exception in Wgl.DXRegisterObjectNV here:

DxInteropColorRenderTargetRegisteredHandle = Wgl.DXRegisterObjectNV(
_context.GLDeviceHandle,
DxColorRenderTarget.Handle,
(uint)GLSharedColorRenderbufferHandle,
(uint)RenderbufferTarget.Renderbuffer,
WGL_NV_DX_interop.AccessReadWrite);

Unchanged example app EXCEPT I'm building for net9.0-windows in both projects. OpenTK 4.9.3.

Error message building for netcore3.1:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Error message building for net9.0-windows:

Fatal error. 0xC0000005

@Xerxes004
Copy link
Author

I submitted a request to Intel to look into the WGL_NV_DX_interop extensions not being found properly with driver 32.0.101.6078. I'll update here if they give me any useful info.

@nick-boey
Copy link

I have run into the same issue on my computer, and have narrowed it down to two specific commits. It's definitely an issue with the Intel integrated graphics, as it works fine when using the dedicated NVIDIA graphics.

On version 4.3.3 it was crashing instantly, but I found it was working back in version 4.2.3. I went back through the commits and I found that it was running fine until this commit, at which point it just renders a black screen. I traced it down to this line in GLWpfControlRenderer.cs, which results in a GL_INVALID_OPERATION error.

GL.FramebufferRenderbuffer(
  FramebufferTarget.Framebuffer,
  FramebufferAttachment.ColorAttachment0,
  RenderbufferTarget.Renderbuffer,
  GLSharedColorRenderbufferHandle);

If I proceed forward through the commits it is only at this commit that it starts to crash instantly with a System.AccessViolationException at this line:

DxInteropColorRenderTargetRegisteredHandle = Wgl.DXRegisterObjectNV(
  _context.GLDeviceHandle,
  DxColorRenderTarget.Handle,
  (uint)GLSharedColorRenderbufferHandle,
  (uint)RenderbufferTarget.Renderbuffer,
  WGL_NV_DX_interop.AccessReadWrite);

Hardware specs:

OS Name Microsoft Windows 11 Enterprise
Processor Intel(R) Core(TM) Ultra 7 165H, 1400 Mhz, 16 Core(s), 22 Logical Processor(s)

Dedicated graphics
Name NVIDIA RTX 500 Ada Generation Laptop GPU
Driver Version 31.0.15.5305

Integrated graphics
Name Intel(R) Arc(TM) Pro Graphics
Adapter Type Intel(R) Arc(TM) Pro Graphics Family, Intel Corporation compatible
Driver Version 32.0.101.6078

@nick-boey
Copy link

The black screen in my case appears to be caused by Wgl.DXRegisterObjectNV returning a zero pointer when run on the Intel integrated graphics, but returning a valid pointer when run on NVIDIA graphics. It only causes the GL_INVALID_OPERATION when the GLSharedColorRenderbufferHandle is then used in the GL.FramebufferRenderbuffer call.

@Xerxes004
Copy link
Author

I saw the same thing you're seeing, @nick-boey. With Intel driver version 32, it seems that the WGL library tries and fails to call that extension function. I sent Intel a sample project located here. If you can, roll your Intel driver back to 31 and see if it fixes the WGL linking issue. If it does, you may still need to remove the GLWpfControl calls that set up the depth/stencil buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants