If you want to try this out locally, you'll need a copy of this wgpu pr and this gfx pr locally, and you'll need to adjust their dependencies to point to the local copies.

If you do this, the demos currently mostly work except the colors are off, and the shadow demo currently looks like this:

I'm currently in the process of figuring out how the shadow demo is broken.

Cool!
I'm unable to get the example running locally but a potential error cause could be the clipspace difference between vulkan and opengl for the z dimension. There is probably an option in the spirv cross translator which allows to adjust it accordingly. Only GL 4.5+ allows to control the clip settings to natively support Vulkan's design decision iirc

@msiglreith so that would be an issue in gfx-backend-gl, not any of the wgpu crates. Did you ever try running gfx_ocean on GL, out of curiosity? I imagine our current examples in gfx-rs are too primitive to cover this.

@msiglreith so that would be an issue in gfx-backend-gl, not any of the wgpu crates.

It's kind of my fault for bringing up the shadow demo, all of the problems there are of course because of gfx-backend-gl, but the wgpu-rs demos are just complex enough that they actually start pushing its boundaries.

I'm unable to get the example running locally but a potential error cause could be the clipspace difference between vulkan and opengl for the z dimension. There is probably an option in the spirv cross translator which allows to adjust it accordingly.

I'll try and test that theory!

I think now you'll have to adjust Cargo.toml again to get this PR to run, or you might actually have to clone the three PRs (gfx-backend-gl, wgpu, wgpu-rs) locally and add a patch section to Cargo.toml for them all... it's a bit of a mess atm.

@kyren since the dependent PR is merged, could you rebase and make this a non-draft PR please?

Okay, this is rebased and now points to current wgpu master, but there's a drive-by wgpu API compatibility change in it.

Also, none of the examples will work at all until this pr is merged.

Oh, my apologies - didn't realize it's waiting for me!
On the way to merging now. I suppose we'd have to bump the gfx-rs dependency in wgpu-native before proceeding.

On the way to merging now. I suppose we'd have to bump the gfx-rs dependency in wgpu-native before proceeding.

Yeah, though now that the wgpu change is merged this will at least build cleanly, it's just not that useful without the gfx-hal PR... though one could argue that even with the gfx-hal PR it's probably still limited. I guess now that the wgpu PR is merged the specific order of all these things is not too critical.

@kyren would you want to rebase and finish this PR?

Okay, I've rebased the PR. I don't think the examples will work out of the box until some of the gfx-backend-gl changes are updated in cargo, but that's not blocking this.

As soon as I'm at my desk I'll check to make sure that the examples still work as I left them when overriding gfx-backend-gl to point to the master branch.

Well, if you pick the correct git commit for gfx, the hello-triangle example will work, but there are other new problems with the other examples due to wgpu changes I think (hitting this panic, maybe due to rendy changes?).

That isn't blocking this PR though, I just don't want anybody reading this to think it will work out of the box just yet.

When I get back to doing graphics work again I'll take a fresh look at getting wgpu-rs / wgpu / gfx-backend-gl working again to the same state I had it at least.

@omni-viral encountered that panic while testing the GL backend with rendy too - need to decide on a workaround

We need to file this upstream in gfx-rs first and discuss there...
Edit: filed gfx-rs/gfx#2812

That being said, we can still land this as soon as you consider it ready ;)

I think it's ready. The actual changes to the wgpu-rs library itself are pretty minimal, most of this PR is just fixing the examples to optionally use glutin.

bors r+

Build succeeded

• continuous-integration/travis-ci/push