DeviceLost with D3D12 on Intel HD 4000 #849
Comments
|
Running any examples results in |
|
Yes, any tutorial results in this error. Thank you for your time! |
|
I used log level 'trace', but no additional information was provided (I followed this explanation). cube:
shadow / skybox:
|
|
It seems that Vulkan is not working on my end. Running the
and running it with
I will check my display driver, but do you have another idea what could be posing this problem? |
|
Ok, that is expected. I thought you are on Linux/Vulkan because I know Windows doesn't support Vulkan on Intel 4000, but Linux does. There is nothing you can do about it. Now it's clear that your issue is in D3D12 backend. Could you run the example from Visual Studio? See our wiki for information on how to get D3D12 debug output. |
|
Good to know, thanks. Running it in VS I get this message:
and then a bunch of threads and the program itself exiting on code 101. Does this help? |
|
Whoops, still was runnning on the vulkan backend. Now I get a whole lot of errors, I'll try to group them, so I don't post an endless wall of text. |
|
Here is the shortened error message:
I hope that helps... |
|
Thank you for these logs! Strangely, they don't explain what's actually happening there. Could you try running any D3D12 apps, or even git clone https://github.com/gfx-rs/gfx
cd gfx/examples
cargo run --features dx12 --bin quad |
|
I ran the quad example.
and nothing else until I forcefully closed the window. Running the .exe in VS gives this error message:
|
|
Quick update: I tried running the wgu-rs examples with DX11 and it ran fine, so at least that's a workaround. No other backend works.. |
|
I'd like to know more about the problem. We can't easily abandon D3D12 for HD 4000 family on Windows, since it doesn't support Vulkan either. Something must tell us what's going on there... |
|
I'm happy to help wherever I can! Just tell me what you need. |
|
I found out that HD Graphics 4000 is an IvyBridge chip, and it's not meant to support DX12 at all (starts with Haswell). Perhaps you could try running the gfx-rs's compute example too? |
|
Another thing, this exception needs to be investigated in detail:
|
|
Running the gfx-rs compute example like this: ...\gfx\examples> cargo run --bin compute --features dx12 1 2 3 4gave me this output
and no errors |
|
ok, great. So it's not that DX12 is not supported, but rather that the support is very limited. It could be that we are trying to do something that assumes a higher feature level than 11_0 without realizing it, and the driver goes nuts. |
|
DX is weird like that, it lets you use higher versions of the API with lower feature levels as long as you don't try to use the features. If we find a backend that only supports 11_0, we should only count it as a DX11 backend, and ignore the 12. Not sure how the details of that will work. |
|
That's certainly one valid way to address this, thanks to the fact we have a DX11 backend. However, it needs much more work before it can be usable, so there is a certain value in trying to get even 11_0 feature level in DX12 backend to work correctly. |
|
Seems like I have the same problem like this. My old laptop has the Nvidia GT 720m Run the DX12 backend always crashes with this If I set backend to DX11, it doesn't crash anymore but nothing shows up. Do we have any help with this old stuff? |
|
Since we don't have the hardware/platform to reproduce this, it would help if you could try figuring out the problem on your own. Running from Visual Studio should give you the debug messages, call stacks, etc. I'm curious to see where we are not handling this properly. |
|
Running the cube.exe in VS and there are many error logs: Searching around I found similar problem at: bkaradzic/bgfx#1484 As the workaround mentioned, I changed something with CSSetUnorderedAccessViews from 16 to 8 at
Then run the cube example again. OutputI'm very new to graphic and also Rust. I have no idea what it is and how it work. Thank you. |
|
I think we should investigate/fix the original issue with DX12 backend on that feature level. |
|
Ok. I will dig into the dx12 backend. |
|
I'm having roughly the same issue (drawing doesn't work with the dx12 backend) with an Intel HD 4200, which supports feature level 11_1. In particular, running the gfx quad example ( Running in Visual Studio, the debug output (excluding DLL loading/unloading messages) is: |
That's quite actionable, thank you! |
|
@PeterHatch this was a different issue (affecting more than just Intel HD 4000), is about to be fixed in gfx-rs/gfx#3360 . Sorry about the inconvenience! |
3360: [dx12] fix root signature indexing r=kvark a=kvark Fixes a critical problem reported in gfx-rs/wgpu#849 (comment) It appears to be a regression from #3342, where I accidentally started using the root offsets where the root indices are expected. We might need to change their types to not hit this any more times (maybe in d3d12-rs even? cc @msiglreith ). PR checklist: - [ ] `make` succeeds (on *nix) - [ ] `make reftests` succeeds - [x] tested examples with the following backends: D3D12 Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
|
Okay, I'm now much closer to the same issue others reported - nothing drawn in the window, and it hangs. Command line output, with RUST_LOG=traceVisual Studio outputThe bit that sticks out to me the most is the Testing earlier versions, the hal-0.6 branch is the same; hal-0.5 has the same behavior, but instead of the error message it has this warning, repeated 3 times: Unlike earlier versions, hal-0.4 does not hang, though it still doesn't draw anything. It prints the same warning messages as 0.5, and repeats them whenever I move the mouse. hal-0.3 and hal-0.2 are the same as 0.4, except it warns about root constants at indexes 0-7 instead of just 0 & 1, and repeats the messages constantly, not just when I move the mouse. Hope this is helpful; let me know if there's anything else it'd be useful for me to do. |
|
What version of gfx-backend-dx12 was this log obtained from? The "Undefined user data element in the root signature at 0" are supposed to be fixed on latest. |
It's the latest version - most recent commit is 4871e2d305210ea79aea392c600361bbafa25a23. Or possibly one version earlier, I updated at some point while working on things, but the last commit just changed the metal backend, and testing on the latest again still shows the same error. |
|
Ok, this may be a red herring. The problem was that the example declared the push constants but didn't bind them (with |
|
Yeah, that fixes the error message but nothing else. My next guess at the issue is this output from Visual Studio: It's triggered by trying to present the first frame, with this code: But not sure how to track it down any further, since it's presumably something about how the scene was set up earlier that is causing the issue. |
|
Yeah, that's unfortunate, and matches other reports. It appears that, either:
Next possible step is - trying to reduce the work we do, and seeing when it starts working again. For example, the first comment here talks about the tutorial. What about |
|
Okay, I think I figured out the problem. Part of it, at least. The issue seems to be when running on cards that only support Resource Tier 1 - there's significant code for that case, and I'm not sure it's ever been tested; it's certainly not working now. In particular, |
|
That's a wonderful investigation! The Resource Tier 1 is checked as Getting memory requirements from resources returns a mask corresponding to the resource type only, see here. Finally, when allocating memory, we select the the So, in theory, all the code is there. I did however found a case where the code would be wrong: if However, I'm not seeing how we'd hit this case. The quad example in gfx-rs only uses a single data format for the texture - |
|
Ah, yes, I was wrong. I was conflating Resource Heap Tier & Resource Binding Tier. (I knew I was confused about whether or not the two functions were done by the same thing, but read something that made me think they were; looking back, I seem to have just misread it.) My card is Resource Heap Tier 2, which is why the debugger was showing Resource Binding Tier is separate, and it's 1 on the same cards we've seen failure reports on. (And 2 only on Nvidia's Kepler chipset, according to the chart at https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D.) This is never actually checked - if it is the issue, I think it would not be from the resource limits but the one other restriction (from https://docs.microsoft.com/en-us/windows/win32/direct3d12/hardware-support):
I don't know enough to know if that's something that's being done or not. |
|
The binding tier seems to only have lower maximum counts for resource bindings. The quad example doesn't nearly put a pressure on those. And it also binds all the descriptor heaps that are referenced from the descriptor tables. So there is no UB there. |
|
So this seems to be a driver issue, for me at least. Using the driver Windows Update considers the latest available - from 2015! - it works. Intel Driver & Support Assistant finds a 2020 driver, but will not install it, saying to check the computer manufacturer's site instead - HP in my case, and they don't have a Windows 10 graphics driver for this computer. Intel has instructions on how to manually install the driver, with the note that it could cause issues - that's what I'd done, and apparently it did indeed cause issues. |
|
Intel drivers had OEM locks on them until very recently, which is preventing you from upgrading. Is this the instructions you followed https://www.intel.com/content/www/us/en/support/articles/000056629/graphics.html? |
|
Closing due to backend rewrite. |
teoxoy
added
external: driver-bug
I was trying this tutorial on my laptop but it does not run. The message is:
at
...\wgpu-core-0.5.6\src\device\life.rs:263.My laptop is running Intel HD Graphics 4000, but it runs fine on my desktop with a GTX 1080. The issue still persists with examples from this repo.
The text was updated successfully, but these errors were encountered: