Closed huangjj27 closed 4 years ago
I'm currently having the same problem. I'm also on windows 10. If I try to run any example, I get the same error as above.
I attached visual studio's debugger to the counter
example, and got this:
counter.exe!ash::vk::KhrSwapchainFn::create_swapchain_khr(ash::vk::Device self, ash::vk::SwapchainCreateInfoKHR * device, ash::vk::AllocationCallbacks * p_create_info, ash::vk::SwapchainKHR * p_allocator) Line 44899 Unknown
counter.exe!ash::extensions::khr::swapchain::Swapchain::create_swapchain(ash::vk::SwapchainCreateInfoKHR * self, core::option::Option<ash::vk::AllocationCallbacks*> create_info) Line 76 Unknown
counter.exe!gfx_backend_vulkan::device::{{impl}}::create_swapchain(gfx_backend_vulkan::Device * self, gfx_backend_vulkan::window::Surface * surface, gfx_hal::window::SwapchainConfig config, core::option::Option<gfx_backend_vulkan::window::Swapchain> provided_old_swapchain) Line 2093 Unknown
counter.exe!gfx_backend_vulkan::window::{{impl}}::configure_swapchain(gfx_backend_vulkan::window::Surface * self, gfx_backend_vulkan::Device * device, gfx_hal::window::SwapchainConfig config) Line 448 Unknown
counter.exe!wgpu_native::device::device_create_swap_chain<gfx_backend_vulkan::Backend>(wgpu_native::hub::Global * global, wgpu_native::id::Id<wgpu_native::device::Device<gfx_backend_empty::Backend>> device_id, wgpu_native::id::Id<wgpu_native::instance::Surface> surface_id, wgpu_native::swap_chain::SwapChainDescriptor * desc) Line 2093 Unknown
counter.exe!wgpu_native::device::wgpu_device_create_swap_chain(wgpu_native::id::Id<wgpu_native::device::Device<gfx_backend_empty::Backend>> device_id, wgpu_native::id::Id<wgpu_native::instance::Surface> surface_id, wgpu_native::swap_chain::SwapChainDescriptor * desc) Line 2126 Unknown
counter.exe!wgpu::Device::create_swap_chain(wgpu::Surface * self, wgpu_native::swap_chain::SwapChainDescriptor * surface) Line 834 Unknown
counter.exe!iced_wgpu::renderer::target::new_swap_chain(wgpu::Surface * surface, unsigned short width, unsigned short height, wgpu::Device * device) Line 80 Unknown
counter.exe!iced_wgpu::renderer::target::{{impl}}::new<winit::window::Window>(winit::window::Window * window, unsigned short width, unsigned short height, float dpi, iced_wgpu::renderer::Renderer * renderer) Line 46 Unknown
counter.exe!iced_winit::application::Application::run<iced::application::Instance<counter::Counter>>(iced_winit::settings::Settings settings) Line 120 Unknown
counter.exe!iced::application::Application::run<counter::Counter>(iced::settings::Settings settings) Line 144 Unknown
counter.exe!iced::sandbox::Sandbox::run<counter::Counter>(iced::settings::Settings settings) Line 129 Unknown
counter.exe!counter::main() Line 13 Unknown
It successfully creates the window, titles it, etc, but it stays empty for a few seconds, and then closes. It looks like it crashes when trying to create the vulkan environment. The actual crash looks deep within the vulkan driver -- it isn't crashing literally on this line, but the call stack gets mangled after this.
The actual error I get when attached is this:
Exception thrown at 0x00007FFD5E42E846 (ig9icd64.dll) in counter.exe: 0xC0000005: Access violation reading location 0x00000000000001B8.
So something has a null pointer to a struct or array, and it's trying to read 440 bytes into that struct/array.
@ejmahler Is this a recent regression? Were you able to run the examples before?
If that is the case, could you try to rollback to 811d8b90d71c26100f0933217f5474e090fbf17c and see if the issue is still there? Also, wgpu-native
released a new patch 3 days ago. You could try to lock the version to the previous one: 0.4.0
.
I tried fixing wgpu-native
to 0.4.0 by adding a line in iced/wgpu/cargo.toml reading "wgpu-native="=0.4.0", and got the same crash as before.
I tried the example revision you shared, and got the same crash as before.
I tried going back to the first revision of the tour.rs example (https://github.com/hecrj/iced/tree/5286ef36b6a5eb6846b5675a7a4aced72601df3b)I could find, but I couldn't compile right away. I had to go into iced/winit/cargo.toml and change the "winit" version to winit = "=0.20.0-alpha3"
so that it wouldn't select alpha4. After that, it compiles, but when I try to run it, it crashes with a different error thread 'main' panicked at 'No adapters found. Please enable the feature for one of the graphics backends: vulkan, metal, dx12, dx11, gl', src\libcore\option.rs:1188:5
.
I guessed that this was a problem with an older version of wgpu, so I went to the oldest version of iced that uses wgpu 0.4. I get this error when trying to compile. It looks like it's referencing a deleted branch of wgpu_glyph: Unable to update https://github.com/hecrj/wgpu_glyph?branch=feature/scissoring Caused by: failed to find branch feature/scissoring
So I tried to use the oldest revision that uses a valid version of wgpu_glyph, which is this: https://github.com/hecrj/iced/tree/c6edc75f588ace61fc2bb2eacf9f26b08d3bda0c This revision crashes with the original crash.
Desperate to get anything working, I went back to a random even older revision of the tour: https://github.com/hecrj/iced/tree/f9de39ddaa3020a9585b1648afb0ead45dfd7aa9/examples/tour
This compiles and runs without any problems. I'll keep digging to see if I can find a more recent revision that runs. In the meantime, do you have any advice for the "No adapters found." error? It might be as simple as enabling a feature or fixing a different version of a library. Also, do you have a local copy of wgpu_glyph's "scissoring" branch that i can use?
Update: I figured out that for the adapter error, I need to modify iced/wgpu/cargo.toml so that the wgpu version looks like this: wgpu = {version="0.3", features=["vulkan"]}
Based on that, the following revision from october 5th, crashes with the original error: https://github.com/hecrj/iced/tree/ae56edc8ccd3462766071cc00c12e92feccf1274
Since I can select my backend by editing this file, I tried setting the graphics backend to dx12 instead of vulkan. When I do this, the example compiles and runs. I'd like to try selecting the dx12 backen in the latest version of iced, but it's not clear to me how to select a backend with wgpu 0.4.
@ejmahler wgpu
chooses a suitable backend at runtime now. I am not sure if it should be using Vulkan on Windows by default if DirectX 12 is available. You should be able to change this line to BackendBit::DX12
to force it:
https://github.com/hecrj/iced/blob/6a0e442ad68c2b104b7e91ef80798610a79aca6b/wgpu/src/renderer.rs#L53
When I change that line of code to directly specify dx12, the examples in the latest version of iced work for me.
@ejmahler Good to know! It may be an issue with your Vulkan driver, or maybe a bug in the Vulkan backend of gfx-hal
.
Just for the record, do you have a dedicated GPU besides your Intel integrated graphics? I am not sure, but it may be that forcing the DirectX 12 backend is making wgpu
choose your dedicated GPU.
Yes, I've got a gtx 1070.
I updated my drivers during the process of troubleshooting this problem, so at minimum it's not a problem of outdated drivers.
@ejmahler Interesting. Thanks!
We may be able to make this configurable for cases like these by using something like environment variables, at least while we get things sorted out... Maybe an ICED_WGPU_BACKEND
?
I investigated your suspicion about choosing the wrong device, and you were right.
In Renderer.rs, I added a dbg!() line right after the statement that specifies the backend:
let adapter = Adapter::request(&RequestAdapterOptions {
power_preference: PowerPreference::LowPower,
backends: BackendBit::DX12,
})
.expect("Request adapter");
dbg!(adapter.get_info());
When BackendBit is dx12, this is the output:
[wgpu\src\renderer.rs:57] adapter.get_info() = AdapterInfo {
name: "NVIDIA GeForce GTX 1070 Ti",
vendor: 4318,
device: 7042,
device_type: DiscreteGpu,
}
When BackendBit is all(), this is the output:
[wgpu\src\renderer.rs:57] adapter.get_info() = AdapterInfo {
name: "Intel(R) UHD Graphics 630",
vendor: 32902,
device: 16024,
device_type: IntegratedGpu,
}
So it looks like it's choosing the wrong device. Perhaps integrated graphics chips don't support swap chains?
Thank you so much for all the testing! It's very hard to debug bugs I cannot reproduce. I really appreciate it.
I'd bet it's either an issue with the Vulkan driver of your integrated GPU, or a bug upstream. I am guessing the issue will also happen with the wgpu
examples. I think opening an issue there would be the next step to take.
I fixed the problem by updating my intel display drivers to the latest version. When I mentioned that I updated drivers before, I only updated my nvidia drivers, because I honestly forgot I even had anything else.
I think the fact that it chooses the intel adapter is troubling, but not at all an urgent priority, because at worst I can disable it.
@ejmahler thanks for All information!I‘ll try to update my GPU driver for my old AMD graphics first
Some experiment results:
step 1. change BackendBit::all()
in render.rs:53 to BackendBit::DX12
, and cargo run --example tour
result: compiled and run, but hangs for seconds and exits, with logs:
iced> cargo run --example tour
Compiling iced_wgpu v0.1.0 (C:\Users\huangjj27\Documents\codes\iced\wgpu)
Compiling iced v0.1.0-beta (C:\Users\huangjj27\Documents\codes\iced)
Finished dev [unoptimized + debuginfo] target(s) in 18.48s
Running `target\debug\examples\tour.exe`
error: process didn't exit successfully: `target\debug\examples\tour.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
step 2. change to BackendBit::DX11
. exactly same error returns
step 3. change to original BackendBit::all()
. exactly same error returns
OS: Windows 10 Pro 1909 Processer: AMD A10-5750M with Radeon(tm) HD graphics Graphics: AMD Radeon HD 8650G + AMD Radeon HD 8790M (Microsoft detected dirvers, date to 2019/8/16, driver version: 26.20.12028.2) (Not update to AMD drivers for the super slow download.)
Update: After adding many dbg!
, it turns out in my case, the windows crashed even berfore Adapter
has finished it request
, So it's probably wgpu::wgn::wgpu_request_adapter
s fault.
It seens that the issue is caused by https://github.com/gfx-rs/wgpu/issues/368
@huangjj27 Thanks for reporting back! This is related to #48 and #69.
I've been meaning to help fix that. I know a bunch of wgpu
users that have been affected by it.
I seem to have a similar crash with examples:
RUST_BACKTRACE=1 cargo run --example counter
Finished dev [unoptimized + debuginfo] target(s) in 0.18s
Running `target/debug/examples/counter`
xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multiple modifiers; Using Mod3, ignoring Lock
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:76
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:60
4: core::fmt::write
at src/libcore/fmt/mod.rs:1030
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:64
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:196
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:473
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:380
12: rust_begin_unwind
at src/libstd/panicking.rs:307
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
14: core::panicking::panic
at src/libcore/panicking.rs:49
15: core::option::Option<T>::unwrap
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/macros.rs:12
16: wgpu_request_adapter
at /home/vladfilippov/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.1/src/instance.rs:474
17: wgpu::Adapter::request
at /home/vladfilippov/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:545
18: iced_wgpu::renderer::Renderer::new
at wgpu/src/renderer.rs:51
19: <iced_wgpu::renderer::Renderer as iced_native::renderer::windowed::Windowed>::new
at wgpu/src/renderer.rs:417
20: iced_winit::application::Application::run
at ./winit/src/application.rs:129
21: iced::application::Application::run
at ./src/application.rs:140
22: iced::sandbox::Sandbox::run
at ./src/sandbox.rs:128
23: counter::main
at examples/counter.rs:4
24: std::rt::lang_start::{{closure}}
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
25: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:49
26: std::panicking::try::do_call
at src/libstd/panicking.rs:292
27: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:80
28: std::panicking::try
at src/libstd/panicking.rs:271
29: std::panic::catch_unwind
at src/libstd/panic.rs:394
30: std::rt::lang_start_internal
at src/libstd/rt.rs:48
31: std::rt::lang_start
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
32: main
33: __libc_start_main
34: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Hm, I am curious which GPU would be chosen if the Highpower one is the requested adapter. (Instead of changing the backend bit)
https://github.com/hecrj/iced/blob/6a0e442ad68c2b104b7e91ef80798610a79aca6b/wgpu/src/renderer.rs#L52
My intuition says it should choose the Nvidia one then... I wonder if it would default to vulkan or dx12 though
@Abendstolz Yes, wgpu
tries to find an integrated device first unless the power preference is set to HighPerformance
.
I think this is a good default for a GUI application. However, I understand there may be cases where an application may prefer to default to a powerful device. We could maybe make this configurable in the Settings
struct.
@hecrj I agree that it's a good default. A game will integrate iced on its own anyway and select the correct adapter.
I was merely curious because I have no system with an integrated and a standalone GPU available atm
Processer: AMD A10-5750M with Radeon(tm) HD graphics Graphics: AMD Radeon HD 8650G + AMD Radeon HD 8790M
After some effort searching around the Internet, I found that these graphic cards don't support vulkan (the newest usable driver is in crimson 16.2.1, while the mininum vulkan supported version is 16.3).
Some facts that may be help
Wanted to try it for after I saw the release of 0.1 and I definitely get the same error. It initially crashed on all examples, so I went and tried the styling example with different backends.
For BackendBit::all()
and BackendBit::VULKAN
I get:
error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
Segmentation fault
For BackendBit::GL
I get:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\Addile\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.4.3\src\instance.rs:474:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 101)
For BackendBit::DX11
I get a blank window that I can move around. When I try to resize it I get:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WindowInUse(WindowInUse)', C:\Users\Addile\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.4.3\src\device.rs:2091:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 101)
BackendBit::DX12
finally worked.
Laptop running Windows 10 with integrated Intel® HD Graphics 620 which should support DX11 and VULKAN. For example Vulkan details for it can be seen at https://vulkan.gpuinfo.org/displayreport.php?id=8035#device for driver 100.7922, I actually just updated today and have the newer 100.7985 driver version that isn't on the site yet.
If I can give any info that would help let me know.
With glow
, the iced works. Thanks for everyone!
I'm trying to run the example on my Windows 10, but I come across this:
I tried to backtrace the log, But it seems to only print a line of log about DPI factor. How could I log more to locate this issue?