search

gfx-rs / gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
http://gfx-rs.github.io/
Apache License 2.0
5.35k stars 549 forks source link

[dx12] Cannot run with GNU target #2355

Open ghost opened 5 years ago

ghost commented 5 years ago

Short info header:

> cargo run --bin compute --features dx12 1 2 3 4
    Finished dev [unoptimized + debuginfo] target(s) in 0.37s
     Running `D:\home\hydroper\Sources\RustLibs\gfx\target\debug\compute.exe 1 2 3 4`

ERROR 2018-08-28T15:12:30Z: gfx_backend_dx12: Failed on dxgi factory creation: -2005270527
thread 'main' panicked at 'assertion failed: !ptr.is_null()', C:\Users\neide\.cargo\registry\src\github.com-1ecc6299db9ec823\wio-0.2.0\src\com.rs:20:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: process didn't exit successfully: `D:\home\hydroper\Sources\RustLibs\gfx\target\debug\compute.exe 1 2 3 4` (exit code: 101)

Error (with backtrace)

ERROR 2018-08-28T17:05:28Z: gfx_backend_dx12: Failed on dxgi factory creation: -2005270527
thread 'main' panicked at 'assertion failed: !ptr.is_null()', C:\Users\neide\.cargo\registry\src\github.com-1ecc6299db9ec823\wio-0.2.0\src\com.rs:20:9

stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at libstd\sys\windows\backtrace/mod.rs:65
   1: std::sys_common::backtrace::print
             at libstd\sys_common/backtrace.rs:71
             at libstd\sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::begin_panic
             at C:\projects\rust\src\libstd/panicking.rs:445
   6: <wio::com::ComPtr<T>>::from_raw
             at D:\home\hydroper\Sources\RustLibs\gfx/<panic macros>:3
   7: gfx_backend_dx12::Instance::create
             at src\backend\dx12\src/lib.rs:685
   8: compute::main
             at examples\compute/main.rs:40
   9: std::rt::lang_start::{{closure}}
             at C:\projects\rust\src\libstd/rt.rs:74
  10: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  11: _rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  12: std::panic::catch_unwind
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
  13: std::rt::lang_start_internal
             at libstd/rt.rs:58
  14: std::rt::lang_start
             at C:\projects\rust\src\libstd/rt.rs:74
  15: main
  16: _tmainCRTStartup
  17: mainCRTStartup
  18: GLOBAL__sub_I__ZNSt12ctype_bynameIwEC2ERKSsy
  19: GLOBAL__sub_I__ZNSt12ctype_bynameIwEC2ERKSsy

error: process didn't exit successfully: `D:\home\hydroper\Sources\RustLibs\gfx\target\debug\compute.exe 1 2 3 4` (exit code: 101)
kvark commented 5 years ago

Thanks for the report! Hopefully, someone with Windows10 can take a look at it shortly. In the meantime, you could help (unless you want to look at it yourself?) by setting RUST_BACKTRACE=1 and providing us with the stack trace.

ghost commented 5 years ago

@kvark Finally I figured out it's a environment variable.

Hm, this error looks to be within the wio dependency of gfx, but it compiled alright... :v

msiglreith commented 5 years ago

Does your gpu support dx12?

ghost commented 5 years ago

@msiglreith According to

image

Yes. I do also've the D3D12.dll in System32.

msiglreith commented 5 years ago

Thanks, it's actually on of the very first calls CreateDXGIFactory2 failing.

The next step would probably be then to isolate the call by removing the prior debug_assertion part and remove the dxgi1_3::DXGI_CREATE_FACTORY_DEBUG` flag.

Difficult to debug as I'm unable to reproduce it.

ghost commented 5 years ago

@msiglreith

The next step would probably be then to isolate the call by removing the prior debug_assertion part and remove the dxgi1_3::DXGI_CREATE_FACTORY_DEBUG` flag.

So I've to fork wio to change dxgi1_3. I'm not sure if this will be very portable, since I'd have to change Cargo.toml in the gfx clone.

msiglreith commented 5 years ago

@hydroper thanks for testing to so far

I'm using MinGW (x86_64-pc-windows-gnu) to build gfx since VS is kinda expensive for my current internet.

Actually I'm not sure if MinGW supports dx12 so far. Not sure if someone has tested it so far.

I'll basically have to fork wio to change dxgi1_3, right?

It just crashes in wio as we pass a nullptr. You could clone gfx repository and change the lines mentioned. The wio dependency can stay as is.

ghost commented 5 years ago

@msiglreith Yeah, it was quite easy to change the lines. I stripped lines 673..682

        let hr = unsafe {
            dxgi1_3::CreateDXGIFactory2(
                dxgi1_3::DXGI_CREATE_FACTORY_DEBUG,
                &dxgi1_4::IDXGIFactory4::uuidof(),
                &mut dxgi_factory as *mut *mut _ as *mut *mut _)
        };

        if !winerror::SUCCEEDED(hr) {
            error!("Failed on dxgi factory creation: {:?}", hr);
        }

Then saved and ran cargo run --bin compute --features dx12 1 2 3 4 on examples and still got the same result.

Actually I'm not sure if MinGW supports dx12 so far. Not sure if someone has tested it so far.

That means MinGW could be incompatible with DXGI/wio. Well... I should sacrifice my internet for VS the 3rd time...

kvark commented 5 years ago

Relevant: https://github.com/gfx-rs/gfx/blob/ec67cfea199601159447d78734694132f5cfed09/Makefile#L16

crlf0710 commented 5 years ago

Mmm, i'm using win10 and windows-gnu stable. Currently these programs runs fine using dx12 on my machine, and I can see the gfx-rs logo in the quad example.

ghost commented 5 years ago

@crlf0710 For me they ran compilling with MSVC++, but not with MinGW (stable-windows-gnu). Oh, and it's one of the latest MinGW distros...