OpenGL support #841
Labels
Comments
karroffel
added
C-Feature
|
Yup just for some additional context, I upgraded bevy to use "git wgpu" here: https://github.com/cart/bevy/tree/upgrade-wgpu, but I get this error:
Probably somehow related to the fact that Bevy does some rendering stuff (like creating gpu resources) on other threads. |
|
Using Then I hit an issue where wgpu didnt like that we use Removing that unlocked a new error: Which indicates that we're using an unsupported binding type: @kvark I'm just pulling you in so you're aware of where we're at. I'm not asking you for anything 😄 |
|
I pushed a new branch with the changes listed above: https://github.com/cart/bevy/tree/opengl-testing |
|
It's too early for Bevy to play with our OpenGL backend. Let us at least get our own samples running first 😅 |
|
Any updates on this? Today I tried and wgpu-rs examples work with latest gfx-backend-gl |
|
No updates yet. We're waiting on two things:
|
|
wgpu-rs OpenGL support is now enabled on master but not ready for general consumption. At the very least we want to be running all of our own examples before recommending it. So far, it only runs a few examples. |
|
Makes sense to me. Definitely take your time / don't feel any pressure from our end 😄 |
|
A little update on this: Bevy now runs with latest wgpu-rs master + OpenGL, but: |
|
This is cool! I'd like to try this out (since I do not have vulkan support). My strategy was modifying wgpu = { git = "https://github.com/gfx-rs/wgpu-rs.git", branch = "master" }But after doing that, I get compile errors like this : |
|
Yep, you need some modifications for this to work, see my |
|
Okay, thanks for the headsup! I'm able to build, but trying a few examples, I quickly saw that there is work to do. :) |
More precisely, all the interaction with the instance, surface, adapter, device, and the queue has to happen on the same thread. But command buffers can be created and recorded on multiple threads, still. So Bevy can get the multithreading benefits. What you aren't going to be able to do (but want to do) is asynchronous resource creation with GL.
Since our basic examples run, I wonder why you are getting the black window. Would be good to see what the difference is, and whether our |
|
Last time we discussed this in Bevy discord engine dev channel it seems that this is a binding issue in bevy when hacking core bevy thread pool module to use the |
|
Yeah theres definitely at least one bevy-specific |
|
Any updates on this since wgpu 0.7 release? |
|
gfx-rs/wgpu#1646. Not sure if this issue is relevant, but for anyone who stumbles along this thread like I did. |
|
Just found this issue through @Mimerme 's cross-reference. Just for anybody who's interested, I'm probably going to be doing some work trying to get Bevy going with the latest WGPU and OpenGL support. Another relevant discussion I started in WGPU: gfx-rs/wgpu#1630 I've gotten bevy's latest, work-in-progress pipelined rendering branch ported to WGPU master, but OpenGL won't start up yet ( and the new Vulkan backend isn't doing gamma correction right so I'm looking at that too ). I'll probably be looking into it soon-ish. |
|
I've gotten almost all of the Bevy 3D examples to run on OpenGL in my fork of WGPU master and Bevy's work-in-progress pipelined rendering branch! Also this doesn't require any changes on the Bevy side regarding multi-threading. GPU resources cannot be created in parallel, unfortunately, due to limitations of OpenGL, but the backend will do the locking necessary to prevent errors when creating resources from multiple threads. And like mentioned above, you can still record command buffers in parallel just fine. For some reason the At the same time I'm also working on getting WebGL working. That's a bit more difficult, but I'm still making progress with the help of the WGPU folks and it's looking very promising!
|
|
Fantastic work @zicklag! Haha I've been lurking on all of your wgpu prs. This all happened so fast ❤️ |
|
glTF example is now working! @jakobhellermann found the last shader translation issue and opened a PR that fixes it: gfx-rs/naga#1144. 🎉
|
bors bot
added a commit
to gfx-rs/wgpu
that referenced
this issue
Jul 27, 2021
1729: Handle Multi-threaded EGL Context Access r=cwfitzgerald,kvark a=zicklag **Connections** #1630, bevyengine/bevy#841 **Description** Implements the synchronization necessary to use the GL backend from multiple threads. Accomplishes this by using a mutex around the GL context with extra wrapping to bind and unbind the EGL context when locking and unlocking. **Testing** Tested on Ubunty 20.04 with a fork of the Bevy game engine and the WGPU examples ( not that the examples test the multi-threading ). ## Remaining Issues There is only one Bevy example I cannot get to run yet and it's the `load_gltf` example. It fails with a shader translation error: ``` Jul 26 20:36:50.949 ERROR naga::back::glsl: Conflicting samplers for _group_3_binding_10 Jul 26 20:36:50.950 WARN wgpu::backend::direct: Shader translation error for stage FRAGMENT: A image was used with multiple samplers Jul 26 20:36:50.950 WARN wgpu::backend::direct: Please report it to https://github.com/gfx-rs/naga Jul 26 20:36:50.950 ERROR wgpu::backend::direct: wgpu error: Validation Error Caused by: In Device::create_render_pipeline Internal error in FRAGMENT shader: A image was used with multiple samplers ``` Interestingly, I think the shader in question doesn't have a `group(3), binding(10)` anywhere that I know of so I'm going to have to drill down a bit more and find out exactly which shader translation is failing more. This could potentially be fixed in a separate PR. I think the rest of this PR is rather straight-forward and the fix for the error above is probably mostly unrelated to the primary changes made in this PR. Co-authored-by: Zicklag <zicklag@katharostech.com>
|
gfx-rs/wgpu#1729 was merged and I've got a branch that brings the Since WGPU 0.10 isn't released yet ( and there's still other changes for WebGL that will be comming up hopefully ), I'm not sure when Bevy will want to update. Just let me know if that branch would be useful and I can push it up and open a PR. |
|
Yeah we need to stay on stable wgpu releases so that we can release on crates.io. However a draft pr that updates the |
|
Haha, just to fix any misconceptions, even though I got the bevy examples working on the pipelined rendering branch, I apparently didn't test any of the pipelined examples. 😅 I didn't realize there were different examples for the pipelined renderer. GL isn't working with the pipelined renderer yet, but I'll be looking into it. |
5 tasks
|
I haven't been able to test |
|
I'll fire my old laptop over the weekend and give it a build! |
|
@cart what does |
|
When running with When I disable msaa, I run into Using #3291 with |
|
@kvark here is the output: Looks like the GL adapter is detected. |
That error is from Naga and will be fixed by gfx-rs/naga#1616 @cart https://gist.github.com/joyrexus/16041f2426450e73f5df9391f7f7ae5f may be helpful when posting looooooong things |
|
@cart uh, this one is rather annoying
What this means is that we couldn't find an EGL config supporting "egl::NATIVE_RENDERABLE". This happens on some configurations, including Android and Angle, where it's harmless, and we specifically allow it there. But on Intel+NV laptops, of which I had one, this means nothing can be presented by the NV GPU. I.e. we'd get the context and draw, but you'd see only a black screen. So we decided to instead report the presentation to be incompatible in this case, just to be on the safe side. Most likely this is some sort of a platform issue on the intersection of Nvidia with Linux's graphics stack. We had a similar issue on Vulkan, and Intel landed a patch where they effectively do the same thing - reporting the adapter as incapable of presenting. It would be interesting to see if it works for you otherwise. If you check out |
|
With that I get: |
|
I mean, try running wgpu-rs examples. |
|
Ah sorry. As you called out, when I run the cube example it starts up but I get a blank / black window. |
|
gfx-rs/wgpu#2307 and gfx-rs/naga#1616 fix all issues for me both on webgl and opengl. |
|
Awesome. I think thats enough for me to remove this from the milestone (but ill leave this issue open until some group of people can use opengl on bevy main). |
|
I noticed when trying the WebGL backend on a MacBook, I get the following error: Which I assume is gfx-rs/wgpu#2271. I guess this will happen on all WebGL builds running on a screen bigger then 2048x2048? Mine is 2560x1600. Currently running bevy main on |
|
When using commands.spawn_bundle(OrthographicCameraBundle::new_2d());the following shader error occurs: The same error happens with Empty app with default plugins, |
|
You shouldn't use |
I'm getting a similar error on Chrome on my Android phone, where I'm trying to get the app resolution to match the window inner dimensions. I wrote it up here: #4021 Is there a way to detect what the limits are on a device so that I can resize to the limit? |
With access to the It isn't clear to me why this isn't just the obvious default used by |
|
The reason is very simple. If your programs use all the capabilities of HW by default, then you'll often end up in a situation where your program doesn't run on another machine. This happens because it may implicitly depend on one of your platform specific capabilities or limits. |
|
I didn't check what changed, but with the bevy 0.6 release I didn't encounter this error anymore. But considering that the resolution isn't something optional, I believe that Bevy should automatically apply this specific limit.
If I understand this correctly @kvark, the only reason not to use all the capabilities of a HW is to support API traces? |
|
Thanks for your help @parasyte, it has led me to a workaround (which I wrote up here). In my case I was sending |
|
I think this can be closed now. Does anybody have any objections? While I haven't done extensive testing recently, I have been able to run Bevy games with OpenGL for a while now. |
|
Closing for now. If y'all run into new problems, please open an issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Wgpu now has a working OpenGL backend. I know bevy intends to support that, but it does not work yet.
Creating this issue to make it easier to track progress on that front.
The text was updated successfully, but these errors were encountered: