-
Notifications
You must be signed in to change notification settings - Fork 51
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
Comments
I updated my drivers to 32.0.101.6079, and now I have an exception in GLWpfControl/src/GLWpfControl/GLWpfControlRenderer.cs Lines 198 to 203 in d5c1851
Unchanged example app EXCEPT I'm building for Error message building for netcore3.1:
Error message building for net9.0-windows:
|
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. |
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
If I proceed forward through the commits it is only at this commit that it starts to crash instantly with a
Hardware specs:OS Name Microsoft Windows 11 Enterprise Dedicated graphics Integrated graphics |
The black screen in my case appears to be caused by |
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. |
Update: After some back and forth, I've finally made contact with an engineer at Intel. I've been told that this issue has been opened with the Intel driver team. They told me it's internal case number 22020848268. They want the ability to reproduce the issue with as "few layers as possible," so I may need to write some example code for them in C++. |
It's understandable to want as few layers as possible, but due to the DirectX context being created by WPF it's possible that it's not as easy as we'd want to create an "equivalent" context ourselves. But if this issue happens generally on intel drivers then it might be easier to reproduce the issue. |
I have not heard anything new from Intel, but I am having the same issue with an Intel B570 graphics card, driver version 32.0.101.6262.
|
Out of curiosity, I went and ran the version 4.2.3 example, and it seems to work as expected. The same example crashes with the above error with 4.3.3. So it has to be something different between those two versions. |
I guess the biggest clue here is that 4.2.3 doesn't attempt to share the depth stencil buffer between DirectX and OpenGL. I've opened a PR here #151 that does the changes so that the depth buffer is hosted in OpenGL land instead of shared between OpenGL and DirectX. If you are able to test this PR that would be great @Xerxes004 @nick-boey |
@NogginBops will test that first thing tomorrow morning. I really appreciate your help on this. I stumbled upon another clue: If I change the "type" parameter of
I haven't gotten much further than this, but I'll drop any nuggets I find in here. |
Did you also change the OpenGL object to be a texture? |
No, I only changed that one param. Another interesting thing to note is that if I call |
Weird... That seems like an Intel driver bug? |
I agree, RenderBuffer is explicitly allowed by the NV_DX_interop spec for a I think their bug lies either in their implementation of Very likely their interface for I need to get this working, hell or high water, so I will try to use the registered Texture2D method that |
This still crashes for me here |
With or without MSAA? |
Without MSAA; the Renderbuffer target is what makes it blow up. I was able to work around all of the bugs using a Texture2D target, and forgoing the DX depth/stencil shared resource. I highly doubt this PR is something that GLWpfControl should take wholesale because it will break anyone's code who is relying on the depth/stencil attachment in the default framebuffer. But this PR represents code that works for what I need for my Intel application. It's a long story, but we rely on Intel's oneAPI for some critical functionality at my company, and the Intel GPUs work "out of the box" in that ecosystem. The same can't be said for D3D9 interop, apparently...... I am creating my own depth/stencil buffers and MSAA-enabled framebuffers because I need to have parts of my program drawn with MSAA, and parts without. Please let me know if there's anything you need from me, I'm more than happy to contribute some Intel-specific code so that others can be un-stuck. CC @nick-boey |
I guess we could switch to textures instead of renderbuffers, but then MSAA is not expected to work (but I guess it doesn't work anyway so it doesn't really matter). By doing this we should get something that works decently ok on intel GPUs while they hopefully fix their broken drivers. |
Sounds good to me. I'm going to send Intel some more info and I'll keep you all posted. |
@NogginBops I updated #152 with a possible solution to decide which "renderer" to use at runtime, based on passing the MSAA test. If the MSAA test fails, the "Texture2D" renderer is used. If it passes, the direct surface sharing is used. I kept the GLWpfControl and GLWpfControl settings interfaces the same, only internal interfaces were changed. I tried several times to attach an MSAA renderbuffer to the Texture2D framebuffer, but it just leaves the screen blank. I opted to just skip MSAA entirely for that renderer, like you had before. Cheers |
I pushed a "fix" for the depth/stencil buffer not being honored in the shared surface framebuffer. I am setting up a separate framebuffer and blitting to it after the render pass. MSAA now works as well. |
Good news, all: Intel reached out and said they were able to root-cause the driver issue with their RENDERBUFFER registration. The public release of the fix is forthcoming. |
That's great! We'll still want the workaround for some time though, but we can switch on it at runtime. |
Good stuff. For anyone who wants access to the workaround, we are using this branch for our production code without any issues, so far. It needs some more massaging to squeeze out maximum performance (like skipping the blit if MSAA is off) but it works for what we need. |
I'll try and find some time to review #152 soon so we can get the workaround merged. From what I've seen so far it looks promising. |
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:GLWpfControl/src/GLWpfControl/Interop/DXInterop.cs
Lines 307 to 314 in d5c1851
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 inIDirect3DSurface9.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
The text was updated successfully, but these errors were encountered: