Is OpenGL Supported now?

[zicklag]

With #183 getting closed in wgpu-rs does that mean that OpenGL is now supported here and we can update the checkmark on the README?

[kvark]

GL was removed some time after we added it. Currently, it's not supported.
We'll be happy to accept patches that re-enable it. This may become a priority for us in the future, but it's not the most pressing thing right now.

[zicklag]

Cool, thanks for the clarification. 👍

I'm good with closing this then, unless you think it should be left open. 🙂

[kvark]

Well, we don't have an issue open for GL, so I'm thinking of leaving this one open.

[zicklag]

At this point, would all that is necessary to get this working be to add the GL gfx backend code just like the Vulkan backend code? I was just messing around with it ( I really hardly any idea what I'm doing ) and I think I got everything except wgpu-native to compile on Linux. With wgpu-native I hadn't figured out how to do the window creation for the GL backend yet.

I pretty much just went through and whenever there were feature gates for Linux I added a section that would use the Gl backend instead of the Vulkan backend if the GL feature was enabled. It was a little haphazard and needs to be organized, but as far as I can tell the last step was window creation.

Am I in the right direction or is there more that is going to need to be done?

[kvark]

@zicklag the problem here is to minimize any deviation from the existing paths. Ideally, the code should support GL fully transparently, but this requires gfx-backend-gl to be smarter about its surfaces, i.e. gfx-rs/gfx#3133

You can post your code as a draft PR, and we'll be happy to see if you are moving in the right direction :)

[zicklag]

OK, cool. After looking around more I see how the surface creation is unimplemented!(). I'll do some looking around to see if I can get a better grasp on the API. If I come up with anything I'll draft a PR.

[zicklag]

So, as far as I understand, as shown in the gfx quad example, you can create an OpenGL surface from a context, split from a windowed context, that was built with Glutin, but in wgpu-native I we already have a raw window handle that we want to create the surface for, and I don't know how to create a glutin Context from the raw window handle.

It looks like, if I can get a Context from the raw window handle, I will be able to create the Surface and there shouldn't really be any more code branching for GL at that point, similar to the Quad example.

Where should I look to find out how to go from RawWindowHandle to glutin Context?

[kvark]

The quad example also shows that we don't initialize the surface the same way on GL. It looks like we need something like raw-gl-handle here, so that we don't depend directly on glutin/sdl/glfw. And even with this, there would be a separate entry point like wgpu_create_gl_surface(RawGlHandle).

This is just the start of our problems though. In a typical GL the window is your context. So we wouldn't be able to enumerate adapters and create devices the way we do now, unless we either:

1. diverge the APIs (unfortunate)
2. fix the divergence at lower level by looking into OpenGL surface via surfman gfx#3133

[zicklag]

So I just found build_raw_wayland_context which looks like we could use that in the GL backends Instance.create_surface() to create a headless context that isn't tied to a window.

Then is Instance.enumerate_adaptors() not going to work for that?

As far as I can find that leaves all of the platform specific code in the gl backend and we wouldn't need a separate wgpu_create_gl_surface(RawGlHandle) because it can create the raw wayland context?

[kvark]

The raw wayland context is what you'd want to create (on wayland only) to back the Instance.
Then, when the user creates a surface, you'd want to back it with another context that is not pure and tied to a window, but also shares all resources with the original context of the instance. This is at least the way I could see it working.

[zicklag]

I went in that direction and I think I've got the context creation working. I don't fully understand what it would mean to have the two contexts share resources like you are saying, but currently it is compiling and getting past the context creation successfully. Hopefully the rest of that will make more sense later, or I've already happened to get it right. 😉

It currently isn't successfully picking up the GL adapter so that is the next thing I have to look at, but I think I've found where I need to start looking.

[zicklag]

OK I've gotten to the point now where it is getting the adapter and failing an assertion.

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `256`: Adapter storage buffer offset alignment not compatible with WGPU', <::std::macros::panic macros>:5:6

If I comment those assertions out ( just to see where it gets next ) I get:

thread 'main' panicked at 'Requested format Bgra8Srgb is not in supported list: [Rgba8Unorm, Bgra8Unorm]', <::std::macros::panic macros>:5:6

I'll try to look into these, but any help understanding the path forward is welcome.

---

Edit: Also a note, I don't actually have wayland on my machine so I'm creating the context with Xlib, but I've got the code in there for both Xlib and wayland so far.

Edit2: After commenting out that second failing assertion I got the Cube demo to work!! Over RDP of all things LOL. We'll have to do something about those assertions, but that is really promising. 😄

Most of the other examples don't run yet.

[kvark]

Thanks, @zicklag , great to see progress here! The first assertion is just due to GL backend not providing a meaningful value for one of the limits here https://github.com/gfx-rs/gfx/blob/77c3e28331f8ab593e57425b47db344f0e9e8112/src/backend/gl/src/info.rs#L361

If you want to help fixing it, you can check out gfx locally ("hal-0.4 branch") and add a [patch.crates-io] section to your wgpu checkout that overrides the gfx libs (you'll likely need the gfx-hal, gfx-backend-gl, and gfx-backend-vulkan overrides). Then, do cargo update -p gfx-backend-gl and cargo update -p gfx-hal. Then fix the GL backend to a point where it doesn't complain :) We'll be happy to accept this patch and publish it.

Also, please make a PR here on wgpu so that we can provide you with feedback early.

[zicklag]

Sounds good! I've already got all of those libraries setup locally with patches on wgpu, wgpu-rs, and gfx-backend-gl. I was using the master branch so I'll rebase on the hal-0.4 branch.

I'll get at PRs up when I get the chance, probably later today.

[zicklag]

OK, I've got the following PRs:

• Wgpu gl support #502
• OpenGL surface via surfman gfx#3151
• Wgpu gl support wgpu-rs#182
• Update Rendy Descriptor For Latest Hal? amethyst/rendy#269

---

I still have to fix the failing assertions and probably some other stuff ( oh, like the rebase ), so they are just drafts, but now you can see the code. 🙂

[zicklag]

@kvark Technically its possible to support both the glutin and surfman GL backends for wgpu, but do you think that it would be better just to support surfman? It would reduce the amount of features a user would have to pick from when building it. Instead of having to specify either gl-glutin or gl-surfman possibly with gl-surfman-x11 ( on Linux only ), they would just have the x11 option.

---

On a side note, I'm really not liking having the x11 feature, actually, but surfman won't build on MacOS with the feature enabled, and you can't run it on X11 on Linux without the feature enabled.

I think to maintain the featureless backend selection we just need to get surfman to compile on MacOS even if the x11 feature is enabled. I'll look into that, but we still need to decide on whether or not to support glutin.

[kvark]

We can't support glutin under the same API, so I don't think we really have an option here. Let's only care about surfman in wgpu.

…

On Mar 28, 2020, at 20:49, Zicklag ***@***.***> wrote:  @kvark Technically its possible to support both the glutin and surfman GL backends for wgpu, but do you think that it would be better just to support surfman? It would reduce the amount of features a user would have to pick from when building it. Instead of having to specify either gl-glutin or gl-surfman possibly with gl-surfman-x11 ( on Linux only ), they would just have the x11 option. On a side note, I'm really not liking having the x11 feature, actually, but surfman won't build on MacOS with the feature enabled, and you can't run it on X11 on Linux without the feature enabled. I think to maintain the featureless backend selection we just need to get surfman to compile on MacOS even if the x11 feature is enabled. I'll look into that, but we still need to decide on whether or not to support glutin. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[zicklag]

I just pushed updates to my PR's for wgpu and wgpu-rs getting the cube and triangle examples working again with the latest code from gfx-rs/gfx#3151 ( rebased onto hal-0.5 ). Now there are no features whatsoever just like the rest of wgpu-rs. 😃 Just cargo run --example cube.

I will probably need some help with it but none of the other examples are working: boids, capture, describe, hello-compute, mipmap, msaa-line, shadow, skybox.

I'm not sure if boids or hello-compute are expected to work anyway because compute isn't even supported in the GL backend for gfx at the moment. I don't know anything about why or what is necessary for compute on GL.

[kvark]

Now with seamless wgpu integration, we can start chopping through the issues of the GL backend and fill those gaps. Amazing work, @zicklag !

[zicklag]

Am I doing something wrong?

Um, that's kind of strange. Can you see if there is in fact a cube folder in the examples/ dir?

Also, I tried building iced with patched wgpu and it failed when building wgpu_glyph crate:

Yes that branch is necessarily using the unreleased version of WGPU which has some minor breaking changes. That one should be very simple to fix as I just ran into the same thing while building Bevy with the changes.

Note: BTW, Bevy builds, but it panics because of, I'm assuming, current deficiencies/bugs in gfx-backend-gl. I'm guessing Iced will have similar issues.

The Diff for Bevy was, go from this:

wgpu::BindingResource::Buffer(wgpu_buffer.slice(range.clone()))

to this:

wgpu::BindingResource::Buffer {
  buffer: wgpu_buffer,
  offset: range.start,
  size: NonZeroU64::new(range.end - range.start)
}

In your case I'm guessing you change it to:

wgpu::BindingResource::Buffer {
  buffer: transform,
  offset: 0,
  size: None
}

Also, for other projects using WGPU, to make sure WGPU properly selects OpenGL as the backend that will be used at runtime, you need to change the line somewhere in the project that says something like this:

wgpu::Instance::new(wgpu::BackendBit::PRIMARY);

To this:

wgpu::Instance::new(wgpu::BackendBit::PRIMARY | wgpu::BackendBit::SECONDARY);

That will make it search for support for all available graphics backends. If you hardware supports Vulkan, though it will use Vulkan because it works better. If you are on a system that has vulkan and you want to force using the GL backend to test it, you can change that line to this instead:

wgpu::Instance::new(wgpu::BackendBit::GL);

[Songtronix]

Hope I do not derail this issue but regarding this

Other than code review and releases to to be made, it's all pretty much in-place except for the rendering artifacts ( gfx-rs/gfx#3353 ) present on the cube example as seen above. This is quite outside of my expertise to knowledgeably attempt to fix so if anybody want's to help with that, that would be great!
To test it out you just have to:
git clone https://github.com/katharostech/wgpu-rs.git --branch gl-final-showdown
cd wgpu-rs
cargo run --example cube

I've tried the cube example but I'm only getting a black window. That's the output I get after closing the window:

[0.812309 ERROR]()(no module): Not all descriptor sets were deallocated
[0.812358 ERROR]()(no module): Descriptor pool is still in use during allocator disposal. DescriptorPool { raw: DescriptorPool, capacity: 64, available: 63 }

I get some warnings too:

[0.054282 WARN]()(wgpu_core::instance): Missing features: IMAGE_CUBE_ARRAY | VERTEX_STORES_AND_ATOMICS | FRAGMENT_STORES_AND_ATOMICS
[0.054569 WARN]()(wgpu_core::device): Surface does not support present mode: MAILBOX, falling back to FIFO
[0.139336 WARN]()(no module): Unsupported builtin 4
[0.139388 WARN]()(no module): Unknown decoration ColMajor
[0.139416 WARN]()(no module): Unknown decoration MatrixStride
[0.143897 WARN]()(wgpu_core::device): Surface does not support present mode: MAILBOX, falling back to FIFO
[0.146910 WARN]()(no module): [API/Performance] ID 131218 : Program/shader state performance warning: Vertex shader in program 1 is being recompiled based on GL state.

Here's probably some important info:

[0.055537 INFO](Instance::pick_adapter)(no module): Vendor: "NVIDIA Corporation"
[0.055603 INFO](Instance::pick_adapter)(no module): Renderer: "GeForce GTX 1050 Ti/PCIe/SSE2"
[0.055623 INFO](Instance::pick_adapter)(no module): Version: 3.3.0, NVIDIA 450.66
[0.055640 INFO](Instance::pick_adapter)(no module): Shading Language: 3.30, NVIDIA via Cg compiler

I can do some more tests as needed. Excited for opengl support!

[zicklag]

Hmm, I don't know what the issue is there. Maybe you could try the triangle example: cargo run --example hello_triangle?

Edit: Actually the black screen you get could be related to the synchronization errors that are creating rendering artifacts for my driver. If the current design is undefined behaviour because of shared FBO's then it could result in a black screen on one driver and glitches on another driver. I'll post here when I get an attempted fix at the synchronization issues and you can try again.

[jmwright]

I am able to get both the cube and hello-triangle examples to run on a RockPro64 running Armbian Bionic Desktop.

I do get the following warning, but don't know if it's anything important.

libEGL warning: DRI2: failed to authenticate

I'll be happy to do other testing if it will be helpful.

[zicklag]

Oh, good, thanks @jmwright. So I think that helps to confirm that we definitely need to fix some stuff around synchronization as it doesn't work for @Songtronix, works half-way for me and works completely fine for @jmwright.

I'll be trying out the suggestions here to see if I can fix the issues I'm getting on my system and move towards a more sound setup. After that @Songtronix and @jmwright, you guys can try it on your systems and see if it's any better/worse.

[0x7CFE]

After some hacking of wgpu_glyph and iced I was able to build and run clock example on Raspberry Pi4 using GL backend.

Unfortunately it crashed with the following message:

thread 'main' panicked at 'egl function was not loaded', /home/pi/work/iced/target/debug/build/surfman-ed97b4f3cd055d77/out/egl_bindings.rs:284:13

@zicklag, any ideas on why that happens? Is there a way to know what particular function fails? see below

Detailed backtrace:

thread 'main' panicked at 'egl function was not loaded', /home/pi/work/iced/target/debug/build/surfman-ed97b4f3cd055d77/out/egl_bindings.rs:284:13
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   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:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: std::panicking::begin_panic
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/panicking.rs:438
  12: surfman::egl::missing_fn_panic
             at /home/pi/work/iced/target/debug/build/surfman-ed97b4f3cd055d77/out/egl_bindings.rs:284
  13: surfman::egl::Egl::GetPlatformDisplay
             at /home/pi/work/iced/target/debug/build/surfman-ed97b4f3cd055d77/out/egl_bindings.rs:465
  14: surfman::platform::unix::x11::connection::create_egl_display::{{closure}}
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/unix/x11/connection.rs:270
  15: std::thread::local::LocalKey<T>::try_with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:263
  16: std::thread::local::LocalKey<T>::with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:239
  17: surfman::platform::unix::x11::connection::create_egl_display
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/unix/x11/connection.rs:268
  18: surfman::platform::unix::x11::connection::Connection::new
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/unix/x11/connection.rs:87
  19: surfman::platform::unix::x11::implementation::connection::<impl surfman::connection::Connection for surfman::platform::unix::x11::connection::Connection>::new
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/unix/x11/../../../implementation/connection.rs:30
  20: surfman::platform::generic::multi::connection::Connection<Def,Alt>::new
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/generic/multi/connection.rs:65
  21: <surfman::platform::generic::multi::connection::Connection<Def,Alt> as surfman::connection::Connection>::new
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/generic/multi/connection.rs:249
  22: surfman::platform::generic::multi::connection::Connection<Def,Alt>::new
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/surfman-0.3.0/src/platform/generic/multi/connection.rs:63
  23: gfx_backend_gl::window::surfman::SM_CONN::__init
             at /home/pi/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/c9fcd08/src/backend/gl/src/window/surfman.rs:28
  24: core::ops::function::FnOnce::call_once
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libcore/ops/function.rs:232
  25: std::thread::local::lazy::LazyKeyInner<T>::initialize
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:289
  26: std::thread::local::fast::Key<T>::try_initialize
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:425
  27: std::thread::local::fast::Key<T>::get
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:410
  28: gfx_backend_gl::window::surfman::SM_CONN::__getit
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:175
  29: std::thread::local::LocalKey<T>::try_with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:262
  30: std::thread::local::LocalKey<T>::with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:239
  31: <gfx_backend_gl::window::surfman::Instance as gfx_hal::Instance<gfx_backend_gl::Backend>>::create
             at /home/pi/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/c9fcd08/src/backend/gl/src/window/surfman.rs:113
  32: wgpu_core::instance::Instance::new
             at /home/pi/.cargo/git/checkouts/wgpu-56857823b01a1582/b4ea52c/wgpu-core/src/instance.rs:50
  33: wgpu_core::hub::Global<G>::new
             at /home/pi/.cargo/git/checkouts/wgpu-56857823b01a1582/b4ea52c/wgpu-core/src/hub.rs:690
  34: <wgpu::backend::direct::Context as wgpu::Context>::init
             at /home/pi/.cargo/git/checkouts/wgpu-rs-7d28407a28c1c884/16cc8c2/src/backend/direct.rs:532
  35: wgpu::Instance::new
             at /home/pi/.cargo/git/checkouts/wgpu-rs-7d28407a28c1c884/16cc8c2/src/lib.rs:1280
  36: iced_wgpu::window::compositor::Compositor::request::{{closure}}
             at wgpu/src/window/compositor.rs:29
  37: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libcore/future/mod.rs:66
  38: futures_executor::local_pool::block_on::{{closure}}
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:317
  39: futures_executor::local_pool::run_executor::{{closure}}
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:87
  40: std::thread::local::LocalKey<T>::try_with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:263
  41: std::thread::local::LocalKey<T>::with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:239
  42: futures_executor::local_pool::run_executor
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:83
  43: futures_executor::local_pool::block_on
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:317
  44: <iced_wgpu::window::compositor::Compositor as iced_graphics::window::compositor::Compositor>::new
             at wgpu/src/window/compositor.rs:86
  45: iced_winit::application::run
             at /home/pi/work/iced/winit/src/application.rs:163
  46: iced::application::Application::run
             at /home/pi/work/iced/src/application.rs:229
  47: clock::main
             at examples/clock/src/main.rs:8
  48: std::rt::lang_start::{{closure}}
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/rt.rs:67
  49: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  50: std::panicking::try::do_call
             at src/libstd/panicking.rs:331
  51: std::panicking::try
             at src/libstd/panicking.rs:274
  52: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  53: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  54: std::rt::lang_start
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/rt.rs:67
  55: main
  56: __libc_start_main
             at /build/glibc-FUvrFr/glibc-2.28/csu/libc-start.c:308

[0x7CFE]

Looks like it fails on GetPlatformDisplay which is a bit strange 😕

[jmwright]

@0x7CFE I ran the following on Arbian Bionic to get past that error.

sudo apt install libglfw3-dev libgles2-mesa-dev

I didn't test whether you needed both or just one of those packages.

[0x7CFE]

@jmwright, awesome! Thanks for the hint.

Indeed, it helped to move forward a bit. Still no luck whatsoever:

thread 'main' panicked at 'TODO: ContextCreationFailed(BadMatch)', /home/pi/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/c9fcd08/src/backend/gl/src/window/surfman.rs:122:27
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   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:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: rust_begin_unwind
             at src/libstd/panicking.rs:419
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:111
  13: core::option::expect_none_failed
             at src/libcore/option.rs:1268
  14: core::result::Result<T,E>::expect
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libcore/result.rs:963
  15: <gfx_backend_gl::window::surfman::Instance as gfx_hal::Instance<gfx_backend_gl::Backend>>::create::{{closure}}
             at /home/pi/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/c9fcd08/src/backend/gl/src/window/surfman.rs:122
  16: std::thread::local::LocalKey<T>::try_with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:263
  17: std::thread::local::LocalKey<T>::with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:239
  18: <gfx_backend_gl::window::surfman::Instance as gfx_hal::Instance<gfx_backend_gl::Backend>>::create
             at /home/pi/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/c9fcd08/src/backend/gl/src/window/surfman.rs:113
  19: wgpu_core::instance::Instance::new
             at /home/pi/.cargo/git/checkouts/wgpu-56857823b01a1582/b4ea52c/wgpu-core/src/instance.rs:50
  20: wgpu_core::hub::Global<G>::new
             at /home/pi/.cargo/git/checkouts/wgpu-56857823b01a1582/b4ea52c/wgpu-core/src/hub.rs:690
  21: <wgpu::backend::direct::Context as wgpu::Context>::init
             at /home/pi/.cargo/git/checkouts/wgpu-rs-7d28407a28c1c884/16cc8c2/src/backend/direct.rs:532
  22: wgpu::Instance::new
             at /home/pi/.cargo/git/checkouts/wgpu-rs-7d28407a28c1c884/16cc8c2/src/lib.rs:1280
  23: iced_wgpu::window::compositor::Compositor::request::{{closure}}
             at wgpu/src/window/compositor.rs:29
  24: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libcore/future/mod.rs:66
  25: futures_executor::local_pool::block_on::{{closure}}
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:317
  26: futures_executor::local_pool::run_executor::{{closure}}
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:87
  27: std::thread::local::LocalKey<T>::try_with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:263
  28: std::thread::local::LocalKey<T>::with
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/thread/local.rs:239
  29: futures_executor::local_pool::run_executor
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:83
  30: futures_executor::local_pool::block_on
             at /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:317
  31: <iced_wgpu::window::compositor::Compositor as iced_graphics::window::compositor::Compositor>::new
             at wgpu/src/window/compositor.rs:86
  32: iced_winit::application::run
             at /home/pi/work/iced/winit/src/application.rs:163
  33: iced::application::Application::run
             at /home/pi/work/iced/src/application.rs:229
  34: clock::main
             at examples/clock/src/main.rs:8
  35: std::rt::lang_start::{{closure}}
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/rt.rs:67
  36: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  37: std::panicking::try::do_call
             at src/libstd/panicking.rs:331
  38: std::panicking::try
             at src/libstd/panicking.rs:274
  39: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  40: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  41: std::rt::lang_start
             at /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libstd/rt.rs:67
  42: main
  43: __libc_start_main
             at /build/glibc-FUvrFr/glibc-2.28/csu/libc-start.c:308
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[zicklag]

Yeah @0x7CFE, I don't know how many real projects are going to work with GL support at the moment. As far as I understand, gfx-backend-gl has hardly been used for anything in practice other than minimal examples and because it hasn't gotten any really strong testing there are probably a lot of bugs or otherwise unimplemented functionality.

Hopefully by adding it as a backend to WGPU, though, we can finally start testing it out in real projects that already use WGPU and we can start fixing the bugs. Once we get the WGPU changes released, we can start creating bug reports for GFX to address the issues that are encountered while trying to run WGPU projects using the GL backend.

[jmwright]

This may be something that is a build tool issue or that needs to be filed against a different repo, but I thought I'd post here just to check. I created a fresh project with only 3 dependencies, and tried to build it on my RockPro64 64-bit ARM (Bionic Desktop) device. The app builds fine with wgpu = "0.5.0" instead of using the gl-final-showdown branch. Here are the dependencies when the build fails.

[dependencies]
winit = "0.20"
wgpu = { git = "https://github.com/katharostech/wgpu-rs.git", branch = "gl-final-showdown" }
shaderc = "0.6"

I get a segmentation fault somewhere along the line when compiling

[ 55%] Building CXX object spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/build_module.cpp.o
[ 56%] Building CXX object spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/ccp_pass.cpp.o
spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/build.make:182: recipe for target 'spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/build_module.cpp.o' failed
CMakeFiles/Makefile2:901: recipe for target 'spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/all' failed
Makefile:129: recipe for target 'all' failed

--- stderr
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_ASM_COMPILER
    CMAKE_ASM_FLAGS


In file included from /usr/include/c++/7/map:60:0,
                 from /home/jwright/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.2/build/spirv-tools/source/opt/ir_context.h:21,
                 from /home/jwright/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.2/build/spirv-tools/source/opt/build_module.h:21,
                 from /home/jwright/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.2/build/spirv-tools/source/opt/build_module.cpp:15:
/usr/include/c++/7/bits/stl_tree.h: In member function ‘void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type) [with _Key = const spvtools::opt::Function*; _Val = std::pair<const spvtools::opt::Function* const, spvtools::opt::PostDominatorAnalysis>; _KeyOfValue = std::_Select1st<std::pair<const spvtools::opt::Function* const, spvtools::opt::PostDominatorAnalysis> >; _Compare = std::less<const spvtools::opt::Function*>; _Alloc = std::allocator<std::pair<const spvtools::opt::Function* const, spvtools::opt::PostDominatorAnalysis> >]’:
/usr/include/c++/7/bits/stl_tree.h:1861:5: internal compiler error: Segmentation fault
     }
     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
make[2]: *** [spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/build_module.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [spirv-tools/source/opt/CMakeFiles/SPIRV-Tools-opt.dir/all] Error 2
make: *** [all] Error 2
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2

build script failed, must exit now', /home/jwright/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.44/src/lib.rs:885:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[zicklag]

Whoa, I've never seen a compiler segfault. 😉

Anyway I think that's unrelated to the direct changes made by the gl-final-showdown branch, but it could be indirectly related either because of change that the branch picks up from master or because I ran a cargo update ( maybe, I don't remember ) on that branch. Probably try it with the master branch and if it has the same problem open a new issue.

---

While I'm here, an update on progress: I'm still working towards fixing the rendering artifacts but I've taken a quick detour over to learnopengl.com to actually learn OpenGL, because until this point I didn't actually know what a framebuffer or a renderbuffer was. 😲

Anyway, OpenGL actually seems really easy so far. I'm going to skim through the tutorials and such just to get a better picture of how things work and then hopefully come back better armed to fix the issue. It shouldn't take long to get what I feel is a decent enough exposure to how OpenGL works before I should be able to start debugging the rendering issue here again.

[jmwright]

Probably try it with the master branch and if it has the same problem open a new issue.

I switched to the following line in Cargo.toml and I do not get the segfault.

wgpu = { git = "https://github.com/gfx-rs/wgpu-rs.git", branch="master" }

At this point I don't think it's worth bogging down the GL development on your fork with this segfault @zicklag . We can wait and see if anyone else has this issue, or if it's specific to my hardware/OS.

[siriux]

@kvark Any news on the changes on surfman needed to avoid context sharing? Given the current situation with Mozilla I'm not sure if this is something we can expect.

Context sharing seems to be the source of many problems/artifacts in the examples, and I imagine many more in real applications. And avoiding it sounded like a promising solution.

[kvark]

Now that @pcwalton has departed from Mozilla, and there is no issue describing what they had in mind, and there is no news about any progress, I'd say we are on our own. Surfman itself will likely keep being maintained as Servo uses it, but we'd likely need to reconstruct the ideas Patrick had, and possibly try to implement it ourselves... Help is much needed!

[zicklag]

Is there anywhere that we have any rough explanation about what the original non-sharing idea was? Maybe we should dump that in a surfman tracking issue.

[kvark]

Yes, we totally do that as the last step. We should dig up the matrix logs...

[kvark]

Filed servo/surfman#202

[zicklag]

There's still some outstanding issues, but OpenGL support has been merged into WGPU!

• Implement OpenGL Backend For Unix Platforms #907
• Enable GL backend wgpu-rs#606