Gfx: [dx12] Cannot run with GNU target

[ghost]

Short info header:

• GFX version: 0.1.0
• OS: Windows 10

> 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]

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]

@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]

Does your gpu support dx12?

[ghost]

@msiglreith According to

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

[msiglreith]

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

• Does quad also crash?
• Could you try in release mode?
• Does the debug console (running in visual studio) emit something?

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]

@msiglreith

• I just ran quad and it has also crashed the same way, with the same wio panic!
• I've again attempted to ran quad using --release, and the same panic occurred. Same call stack.
• I'm using MinGW (x86_64-pc-windows-gnu) to build gfx since VS is kinda expensive for my current internet.

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]

@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]

@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]

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

[crlf0710]

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]

@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...