Upgrade to wpgu 0.10

[kylc]

This PR updates the library to be compatible with wgpu 0.10.

Everything compiles and all the demos run, except for the cube.rs demo. It seems to stall out in the Example::render() function when submitting the command buffer to the queue. I will need to investigate if this is due to a change in wgpu or just a bug in updating to the latest version.

Because of this unsolved issue this PR is marked as WIP.

Fixes #65

[willemv]

For me, every example fails except the cube sample:

C:\Users\user\Development\imgui-wgpu-rs(master)> cargo run --example hello_world
   Compiling imgui-wgpu v0.16.0 (C:\Users\user\Development\imgui-wgpu-rs)
    Finished dev [unoptimized + debuginfo] target(s) in 8.75s
     Running `target\debug\examples\hello_world.exe`
[2021-08-23T20:27:33Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-23T20:27:33Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }
[2021-08-23T20:27:33Z ERROR wgpu::backend::direct] wgpu error: Validation Error

    Caused by:
        In Device::create_render_pipeline
          note: label = `imgui-wgpu pipeline`
        Internal error in VERTEX shader: D3DCompile error (0x80004005): C:\Users\user\Development\imgui-wgpu-rs\imgui.vert.spv(38,12-17): error X3003: redefinition of 'VertexInput_main::member'



thread 'main' panicked at 'Handling wgpu errors as fatal by default', C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\backend\direct.rs:2159:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\std\src\panicking.rs:541
   1: wgpu::backend::direct::default_error_handler
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\backend\direct.rs:2159
   2: core::ops::function::Fn::call<fn(enum$<wgpu::Error>),tuple<enum$<wgpu::Error>>>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:70
   3: alloc::boxed::{{impl}}::call<tuple<enum$<wgpu::Error>>,UncapturedErrorHandler,alloc::alloc::Global>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\alloc\src\boxed.rs:1589
   4: wgpu::backend::direct::ErrorSinkRaw::handle_error
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\backend\direct.rs:2146
   5: wgpu::backend::direct::Context::handle_error<enum$<wgpu_core::pipeline::CreateRenderPipelineError>>
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\backend\direct.rs:166
   6: wgpu::backend::direct::{{impl}}::device_create_render_pipeline
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\backend\direct.rs:1240
   7: wgpu::Device::create_render_pipeline
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.10.1\src\lib.rs:1709
   8: imgui_wgpu::Renderer::new
             at .\src\lib.rs:387
   9: hello_world::main
             at .\examples\hello_world.rs:98
  10: core::ops::function::FnOnce::call_once<fn(),tuple<>>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\examples\hello_world.exe` (exit code: 101)

[willemv]

All examples work when forcing the backend to VULKAN

[willemv]

The failing build steps are caused by new clippy warnings, #68 fixes those in a separate PR.

[cwfitzgerald]

Thanks for this! #68 is in, so you can rebase.

[kylc]

@willemv Interesting that it seems to fail in the shader validation stage. In this PR those compiled shaders are unchanged. I wonder if this is an issue introduced in the wgpu D3D backend in version 0.10.

You might try this PR in conjunction with #67. Naga will likely compile shaders to more wgpu-compliant SPIR-V.

[willemv]

@kylc Thanks for the suggestion. I tried in conjunction with your #67 PR, but that didn't fix it

Looking into this some more, it looks like a bug in naga. It translates the compiled spirv file to a hlsl file containing the following struct :

struct VertexInput_vs_main {
    float2 member : LOC0;
    float2 member : LOC1;
    float4 member : LOC2;
};

which is obviously wrong (three members with the same name).

I'll log an issue with naga to follow up on this.

In the meantime, we could convert the shaders to straight wgsl, which, I think, will avoid the bug by losing less naming information.

[cwfitzgerald]

I think converting the shaders to wgsl is likely a good idea anyway. I can help with this process if it's needed.

[willemv]

I'm not familiar with wgsl, so @cwfitzgerald if you could help with that that would be nice

[kylc]

I have a WGSL conversion over on this branch: https://github.com/kylc/imgui-wgpu-rs/tree/to-wgsl

The differences are 1) the individual vertex and fragment shaders have been combined into a single shader in the imgui code, 2) there is no WGSL preprocessor so we have to use simple string substitution to manage the SRGB/linear color definitions.

I had originally abandoned the effort because I read WGSL was not yet supported by some wgpu backends (web?), but I can no longer find that info so I may be mistaken.

[cwfitzgerald]

@kylc the code looks good, but we should be able to do without the string replacement by having multiple entry points:

[[stage(fragment)]]
fn fs_main_linear(in: VertexOutput) -> FragmentOutput {
    let color = srgb_to_linear(in.v_Color);

    return FragmentOutput(color * textureSample(u_Texture, u_Sampler, in.v_UV));
}

[[stage(fragment)]]
fn fs_main_srgb(in: VertexOutput) -> FragmentOutput {
    let color = in.v_Color;

    return FragmentOutput(color * textureSample(u_Texture, u_Sampler, in.v_UV));
}

Then when we make the pipeline, just also pass in the fragment shader entry point name.

[kylc]

Great idea, I hadn't considered that. I will update the branch and open a PR when I have a chance.

[cwfitzgerald]

Thank you so much!

[kylc]

See #69 for shader translation to WGSL.

[willemv]

I'll log an issue with naga to follow up on this.

I finally got around to logging that issue: gfx-rs/naga#1316

[cwfitzgerald]

@kylc what's the status here, naga patch will be out in the next couple hours :)

[kylc]

I haven't yet been able to resolve the deadlock issue in the cube example that I mentioned in the PR. That said, it only happens on one of my machines (Intel UHD 620/Vulkan backend) and the cube demo seems like a somewhat non-standard usage of wgpu, creating multiple CommandEncoders per render frame.

I'd be curious to hear if anyone else has trouble with the cube example. If not, maybe this is just down to the configuration of that one machine and shouldn't hold up this merge.

[cwfitzgerald]

@kylc this seems like gfx-rs/wgpu#1672 which, while unfortunate, we shouldn't block on.

[kylc]

Thanks for tracking that down. Ready to merge on my end. I just rebased and updated the changelog.

[kylc]

Fixed formatting issues.

[cwfitzgerald]

Thank you so much! I want to land this and #69 and I'll cut a release.

[ChristianIvicevic]

Is there any plan when the release will be rolled out? I'd like to upgrade to wgpu 0.10 myself but have to wait for the changes in this PR to be released.

[cwfitzgerald]

@ChristianIvicevic cutting a release as we speak

[cwfitzgerald]

Published!

[kylc]

Thank you @cwfitzgerald!