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?
zicklag
All 84 comments
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.
kvark
on 14 Jan 2020
Cool, thanks for the clarification. :+1:
I'm good with closing this then, unless you think it should be left open. :slightly_smiling_face:
zicklag
on 14 Jan 2020
Well, we don't have an issue open for GL, so I'm thinking of leaving this one open.
kvark
on 14 Jan 2020
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?
zicklag
on 20 Feb 2020
@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. https://github.com/gfx-rs/gfx/issues/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 :)
kvark
on 20 Feb 2020
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
on 21 Feb 2020
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?
zicklag
on 22 Feb 2020
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:
- diverge the APIs (unfortunate)
- fix the divergence at lower level by looking into https://github.com/gfx-rs/gfx/issues/3133
kvark
on 22 Feb 2020
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?
zicklag
on 22 Feb 2020
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.
kvark
on 23 Feb 2020
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. :wink:
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
on 23 Feb 2020
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. :smile:
Most of the other examples don't run yet.
zicklag
on 24 Feb 2020
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.
kvark
on 24 Feb 2020
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
on 24 Feb 2020
OK, I've got the following PRs:
- https://github.com/gfx-rs/wgpu/pull/502
- https://github.com/gfx-rs/gfx/pull/3151
- https://github.com/gfx-rs/wgpu-rs/pull/182
- https://github.com/amethyst/rendy/pull/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. :slightly_smiling_face:
zicklag
on 25 Feb 2020
@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.
zicklag
on 29 Mar 2020
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 notifications@github.com 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.
kvark
on 29 Mar 2020
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 https://github.com/gfx-rs/gfx/pull/3151 ( rebased onto hal-0.5 ). Now there are no features whatsoever just like the rest of wgpu-rs. :smiley: 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.
zicklag
on 11 Apr 2020
Now with seamless wgpu integration, we can start chopping through the issues of the GL backend and fill those gaps. Amazing work, @zicklag !
kvark
on 11 Apr 2020
Praise the Lord. :smiley: Thanks for all of the help, @kvark!
I've still got to go through the wgpu changes and review them, especially after the rebase onto the latest master, but it is a much smaller change than the gfx-backend-gl one so it shouldn't be that difficult to evaluate.
BTW the gfx-backend-gl PR rebases effortlessly on to hal-0.5 as well, so that will be really easy to backport.
Do we want to enable gl for MacOS in wgpu? Right now it has the same platform gates as Vulkan ( I think it's everything but MacOS and iOS ).
zicklag
on 12 Apr 2020
Do we want to enable gl for MacOS in wgpu? Right now it has the same platform gates as Vulkan ( I think it's everything but MacOS and iOS ).
It would be nice, even if not ultimately required.
BTW the gfx-backend-gl PR rebases effortlessly on to hal-0.5 as well, so that will be really easy to backport.
I wonder to what extent this could be backwards compatible?
kvark
on 12 Apr 2020
It would be nice, even if not ultimately required.
OK, I think all I have to do is change the #[cfg] checks not to exclude MacOS so that should be easy.
I wonder to what extent this could be backwards compatible?
What do you mean? Like, could it be backported to 0.4 as well?
zicklag
on 12 Apr 2020
What do you mean? Like, could it be backported to 0.4 as well?
No, I mean, it seems like your changes are not backwards compatible even to hal-0.5 (unless you keep glutin to be the default feature, yikes!). But ideally we'd want them on hal-0.5 release, so that wgpu non-breaking update can be made.
kvark
on 12 Apr 2020
Ah, that's a good point. Hmm...
Yeah, I think the best option for getting the changes available as early as possible would probably be just to make glutin the default backend until hal-0.6. I'm not positive there aren't any other breaking changes if we do that, so I'll double-check that.
zicklag
on 12 Apr 2020
Got a PR that backports the surfman backend for gfx-backend-gl to hal-0.5 where wgpu will be able to use it without a breaking release: https://github.com/gfx-rs/gfx/pull/3216.
I'll be working on polishing the wgpu and wgpu-rs PRs next which shouldn't be a huge deal to get finished.
zicklag
on 16 Apr 2020
@zicklag feel free to ping me if you want someone to test your branches on MacOS, I'd be more than happy to :)
bschwind
on 21 Apr 2020
Just an update for this thread on our current status:
The surfman backend for gfx-backend-gl was merged, but after merging we discovered some misconceptions about why it "worked" for the examples that were successful with it. After investigation @kvark discovered that it was not actually sharing graphics resources in GL contexts, so we are currently blocked by https://github.com/pcwalton/surfman/issues/65.
It seems like it will be relatively simple to resolve that issue, but I'm not sure when I will have the time to look into it. If somebody else wanted to tackle that, that would be great.
After that is covered, it is ( saving any unforeseen issues ) a simple thing to update the surfman backend for gfx-backend-gl to use the new shared resources mode and then just a little big more work before we have very minimal support for OpenGL in WGPU.
If we got https://github.com/pcwalton/surfman/issues/65 out of the way I might be able to force in the time to get the rest of it done, because I've pretty much already done the work it just has to be rebased.
zicklag
on 1 Jun 2020
Definitely excited for this. Checked out this branch and associated others to try and run examples on raspberry pi but I got same failure as CI. Tried hacking around it but gave up :) will try again once new stuff lands tho. This is great work !
m4b
on 2 Jun 2020
@zicklag thanks for the update!
I implemented https://github.com/servo/surfman/pull/185 that will hopefully unblock you if/when it's merged.
kvark
on 3 Jun 2020
Awesome @kvark! Thanks for doing that!
Once that gets in I'll do what I can to free time to finish it off. :+1:
zicklag
on 3 Jun 2020
@zicklag you can technically just switch the dependency to my fork and work with it, if you find time
kvark
on 3 Jun 2020
Great point, I'll do that.
zicklag
on 3 Jun 2020
Is there anything I can help with? I have access to a macbook as well as a desktop with windows/linux dual boot. I have a small amount of experience with OpenGL context sharing too. I'm really excited to see OpenGL support for wgpu!
bschwind
on 3 Jun 2020
I'm going to try getting the bit of work done necessary to finish off the branches for this effort and then we could definitely use some testing. After getting minimal OpenGL support there are probably going to be a lot of bugs/limitations in the gfx-backend-gl backend revealed as we try to run WGPU projects on it and those will probably need some help.
zicklag
on 3 Jun 2020
@zicklag great! Mention me any time you need testing done.
bschwind
on 3 Jun 2020
Quick update: there is a discussion going on right now about re-architecturing surfman to detach surfaces from contexts entirely. This will allow gfx-backend-gl to avoid using GL context sharing, but more importantly - to avoid the nasty blit on present!
We are looking forward to see the plan of action by @pcwalton. This kinda leaves us in the air. We could continue with the context sharing, for now, just to get things going, but later on we'll need to mostly rewrite the surfman integration part :/
kvark
on 3 Jun 2020
I'm leaning towards just waiting on that for now. I don't think there is a huge motivation to getting it out the door right now when it will probably need more work even then to make it usable in an actual project. ( In earlier tests I was only able to get some of the examples working while other projects such Pixels and Nannou I never got working at all ).
Very good news about the possibility of getting rid of that blit, though!
zicklag
on 3 Jun 2020
Will the opengl backend be transparent to multithreading, like the other modern backends?
It would be really good to know to decide how to structure a new project if I want to get support for opengl when is ready in the future.
Also it would be interesting to know if multiple windows will be supported in a similar way to modern backends.
siriux
on 27 Jun 2020
Re: threading, I can't see any reasonable way it wouldn't be, as gfx-portability relies on it, as does wgpu. Also note: https://github.com/gfx-rs/gfx/blob/master/src/hal/src/device.rs#L391
cwfitzgerald
on 27 Jun 2020
@siriux as @cwfitzgerald said, it's definitely our goal and current plan to have GL:
- transparent to multi-threading like other backends
- transparent to initialization and multiple windows support, like other backends
However, we are still in prototyping phase on the way to achieve that. Surfman API is being refactored to allow these cases, and we've yet to see if the refactor will be a success.
kvark
on 27 Jun 2020
@kvark that would be perfect. Looking forward to the Surfman refactoring.
siriux
on 28 Jun 2020
Great work being done here!
@kvark Is there a way for us to track the progress of prototyping and refactoring and/or some way to help out?
lukabavdaz
on 23 Jul 2020
@lukabavdaz we are basically waiting for @pcwalton to get surfman in a shape where we can use it in gfx-backend-gl.
Of course, this isn't ideal, especially if you have energy to help here and now. You can check https://github.com/gfx-rs/gfx/pull/3216 code and this comment specifically - https://github.com/gfx-rs/gfx/pull/3216#issuecomment-625322960
Since then, my context sharing features got in surfman - https://github.com/servo/surfman/pull/185
So what we can do today is basically making the GL backend work in master of gfx-rs by using GL context sharing and an extra blit on presentation (like https://github.com/gfx-rs/gfx/pull/3216 with this commit), while depending on surfman as a git dependency. That would let wgpu to start using it now.
Once surfman is re-architectured, we should be update the gfx-backend-gl, and wgpu would not even notice.
kvark
on 23 Jul 2020
I'm on a new laptop that suits me much better now so it should be easier for me to find time to get the interim https://github.com/gfx-rs/gfx/pull/3216 working again. Somebody else could do it, but I've got a lot of context about where it is at now so it will probably be much less work if I can manage it. Feel free to ping me if I don't get to this in the next couple weeks or so.
zicklag
on 23 Jul 2020
OK, I just cloned the repos and spent a a little bit of time working on the conflicts with my gl support branches. I'm hundreds of commits behind and I haven't touched this in a while so it might be a little bit still, but we'll see if we can't finally pull this off. :slightly_smiling_face:
zicklag
on 5 Aug 2020
@zicklag, I'm trying to find a way to run iced on Raspberry Pi 4 (https://github.com/hecrj/iced/issues/428). Since Vulkan support there is in it's infancy, OpenGL is probably the only practical solution.
Could you please tell me, is there a way to try out your branch? How usable it is right now? Or may be there is an earlier version of wgpu that would work with GL?
P.S.: Thank you for the work you do. I really appreciate that! :heart:
0x7CFE
on 22 Aug 2020
@0x7CFE so right now, it isn't usable at all, but I'll be working on this over the weekend, hopefully finishing the first step in GFX ( https://github.com/gfx-rs/gfx/pull/3340 ), but you never know, my weekends have been busy lately.
As for an older version, I don't think there is any older version that worked enough to use with Iced.
Also, if this gets in, there may still be a number of bugs that need to be fixed in the GL backend, and I'm not sure who will be able to tackle those. Still, it might work with Iced, but we'll see.
My very next step is to fix https://github.com/gfx-rs/gfx/pull/3340 and then I will start integrating that with WGPU. Hopefully it won't take too long, but again, my time is a bit unpredictable. I'll post any updates here.
P.S.: Thank you for the work you do. I really appreciate that! heart
Thanks for the thanks. :smiley:
zicklag
on 22 Aug 2020
Which exactly version of OpenGL will be supported?
qarmin
on 24 Aug 2020
@qarmin we'll support lower versions of GL if possible, but initially we'll probably focus on:
- OpenGL 4 (maybe OpenGL 3) or higher
- OpenGL ES 3 or higher
grovesNL
on 24 Aug 2020
Which exactly version of OpenGL will be supported?
I personally don't know the difference between OpenGL and OpenGL ES, but currently I believe that OpenGL 3.3 is the minimum version required to function and that is the version that the GL backend currently requests:
version: sm::GLVersion::new(3, 3), // TODO: Figure out how to determine GL version
Good news, I think we're getting close! :smiley:
Got the example running on OpenGL, with the required context sharing setup through surfman.
I've also started porting WGPU to the latest GFX including support for OpenGL and it's going very well so far. Looks like it will be easy ( for the initial port, anyway, not counting fixing the GL backend to work with everything WGPU does ). Hopefully we'll be done with this soon!
WIP PR for GFX:
zicklag
on 26 Aug 2020
Is your branch at a state you're mostly happy with @zicklag? I might fork it & see if I can get it working with Bevy engine & OpenGL ES 3.0 (for us Pinebook pro owners :P), unless you're still working out the major kinks
Unorthodactyl
on 26 Aug 2020
@Unorthodactyl The GFX portion of this ( https://github.com/gfx-rs/gfx/pull/3340 ) should be ready now, but it will still need a PR to WGPU and WGPU Core. I'll be putting those out soon.
After that it will be ready to try with Bevy. I've got an OpenGL only computer would like to get Bevy running on, too. :)
BTW, the OpenGL backend is only really supported on Linux right now, I think. Though it might also work on MacOS. ( I'm not sure what a Pinebook pro is. :stuck_out_tongue_winking_eye: ) If you are running Windows, you should be able to use WGPU's DirectX 11 backend I think.
zicklag
on 26 Aug 2020
@zicklag Pinebook Pro is a fully FOSS compliant ARM-based laptop. It technically has Vulkan support but only with non-FOSS kernel blobs (which run like ass anyway)
My other laptop is also limited only to OpenGL, unless I run windows but windows is massive headache to develop on imo
Unorthodactyl
on 26 Aug 2020
I just got the WGPU cube example running on OpenGL!
It's got some kind of strange pixelated edges that wrap around the cube. I'm not sure what that's from and it's rather out of my experience level to fix that at the moment. Also it and hello-triangle are pretty much the only examples that work at the moment, all of the others either crashing or showing nothing, but I think that's enough to start a PR, then we can start fixing the bugs.
I'll have the code up as PRs soon.
zicklag
on 27 Aug 2020
This kind of artifact means that the drivers are not properly synchronizing access to that texture. I.e. we blit the result of rendering, but the context where we take it from didn't do the necessary state transition to make it readable.
kvark
on 27 Aug 2020
Uh, oh. Is that hard to fix. 😬 🤞
zicklag
on 27 Aug 2020
I suppose it's one of those things where the behavior of GL drivers with shared contexts is underspecified. We need to find a way to convince the context owning the swapchain image (i.e. the surface context) that this image is going to be blit from. Currently, we are doing the blit operations on the root context instead.
So we should experiment. For example, try to bind the swapchain texture as glBindTexture on the surface context before blitting.
kvark
on 27 Aug 2020
Got a draft PR for WGPU: https://github.com/gfx-rs/wgpu/pull/907.
zicklag
on 29 Aug 2020
Thanks for all your work on this @zicklag . I'm excited to see this getting so close.
jmwright
on 29 Aug 2020
Thanks for the kind words @jmwright! And for everyone elses :+1:'s :tada:'s and :heart:'s. It's been a long effort and it helps that people are glad to have it. :smiley:
Now there are the following PRs for supporting GL in WGPU:
- #910: Adds CFG aliases that make it easier to feature-gate code for different backends ( edit: merged! )
- This should be able to be merged soon as it doesn't change anything feature-wise
- #907: Integrates the GFX GL backend with WGPU
- This needs to wait on a new GFX release that will include the fixes for the GL backend
There is also a branch for wgpu-rs that has some hacked in changes that allow you to test running the examples with the GL backend. There is no PR for that one yet as there is almost no changes needed and we need WGPU to be release before we can set the dependent crate versions properly so I'll create the PR when those are made.
Other than code review and releases to to be made, it's all pretty much in-place except for the rendering artifacts ( https://github.com/gfx-rs/gfx/issues/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
You should also be able to include wgpu-rs in a project as a dependency like so:
wgpu = { git = "https://github.com/katharostech/wgpu-rs.git", branch = "gl-final-showdown" }
That way you can test it out with different projects.
zicklag
on 30 Aug 2020
Regarding the cube artifacts, is it something that could be helped by glFenceSync?
bschwind
on 31 Aug 2020
@bschwind that's a good hint!
@zicklag that's another thing we need to try. See slide 14 of http://developer.download.nvidia.com/GTC/PDF/GTC2012/PresentationPDF/S0356-GTC2012-Texture-Transfers.pdf
Basically, the device context should create a fence by calling glFenceSync, and the surface context should do glWaitSync before blitting. Notably, ARB_sync may not be supported everywhere, but this is something we need to try anyway.
kvark
on 31 Aug 2020
@zicklag, I've tried building cube exmaple as you suggested:
git clone https://github.com/katharostech/wgpu-rs.git --branch gl-final-showdown
cd wgpu-rs
cargo run --example cube
Unfortunately I get
pi@raspberrypi:~/work/wgpu-rs $ cargo run --example cube
error: no example target named `cube`
Am I doing something wrong?
0x7CFE
on 31 Aug 2020
Also, I tried building iced with patched wgpu and it failed when building wgpu_glyph crate:
error[E0423]: expected function, tuple struct or tuple variant, found struct variant `wgpu::BindingResource::Buffer`
--> /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu_glyph-0.10.0/src/pipeline.rs:436:27
|
436 | resource: wgpu::BindingResource::Buffer(transform.slice(..)),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ did you mean `wgpu::BindingResource::Buffer { /* fields */ }`?
@zicklag, looks like the interface was changed in an incompatible way?
0x7CFE
on 31 Aug 2020
Yup, that interface was changed in https://github.com/gfx-rs/wgpu-rs/pull/523 to make it more consistent.
cwfitzgerald
on 31 Aug 2020
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);
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!
Songtronix
on 31 Aug 2020
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.
zicklag
on 31 Aug 2020
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.
jmwright
on 31 Aug 2020
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.
zicklag
on 31 Aug 2020
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
Looks like it fails on GetPlatformDisplay which is a bit strange :confused:
0x7CFE
on 1 Sep 2020
@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.
jmwright
on 1 Sep 2020
@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.
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.
zicklag
on 1 Sep 2020
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
Whoa, I've never seen a compiler segfault. :wink:
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. :astonished:
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.
zicklag
on 8 Sep 2020
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.
jmwright
on 8 Sep 2020
@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.
siriux
on 29 Sep 2020
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!
kvark
on 29 Sep 2020
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.
zicklag
on 29 Sep 2020
Yes, we totally do that as the last step. We should dig up the matrix logs...
kvark
on 29 Sep 2020
kvark
on 29 Sep 2020
There's still some outstanding issues, but OpenGL support has been merged into WGPU!
zicklag
on 5 Nov 2020
Related issues
kvark
·
3Comments
paulkernfeld
·
3Comments
cloudhead
·
4Comments
Phaiax
·
4Comments
LaylConway
·
3Comments
Most helpful comment
OK, I just cloned the repos and spent a a little bit of time working on the conflicts with my gl support branches. I'm hundreds of commits behind and I haven't touched this in a while so it might be a little bit still, but we'll see if we can't finally pull this off. :slightly_smiling_face: