bindBuffer errors in webgl bevy game #2378
Comments
|
Here's a dump from what I believe is the start of a frame to the first INVALID_OPERATION. edit: reuploaded twice Here's the webgl2context shim I'm using (originally from bjorn3). I'm cramming into the middle of the getContext function in |
|
So I'm not entirely sure what the expected order of these console logs and error messages coming in would be, but it seems possible that the next lines are actually triggering the error, perhaps? And if that's the case, then it indeed seems like My patch has the effect of changing the "rebinding as GL_ELEMENT_ARRAY_BUFFER" into an "unbinding" and preventing this error. But it seems like the actual problem may be elsewhere? |
|
@zicklag apologies for the unsolicited ping, but this code seems to be yours (thanks!) so I'm wondering if you might have any insight. |
|
No problem! Actually as I look closer at that code again, it looks like your "hack" is actually the correct code and I think you have discovered a legit oversight in my code! A little bit higher up we have this: let is_index_buffer_only_element_dst = !self
.shared
.private_caps
.contains(super::PrivateCapabilities::INDEX_BUFFER_ROLE_CHANGE)
&& dst_target == glow::ELEMENT_ARRAY_BUFFER
|| src_target == glow::ELEMENT_ARRAY_BUFFER;
// WebGL not allowed to copy data from other targets to element buffer and can't copy element data to other buffers
let copy_dst_target = if is_index_buffer_only_element_dst {
glow::ELEMENT_ARRAY_BUFFER
} else {
glow::COPY_WRITE_BUFFER
};This checks for platforms such as WebGL which can't bind an element array buffer as a different kind of buffer. Then we set the At the end where you have made your code modification: gl.bind_buffer(copy_src_target, None);
if is_index_buffer_only_element_dst {
gl.bind_buffer(glow::ELEMENT_ARRAY_BUFFER, self.current_index_buffer);
} else {
gl.bind_buffer(copy_dst_target, None);
}We're really just trying to unbind the buffers that we bind in the code above to set things back to "normal". In this case your new code: gl.bind_buffer(copy_src_target, None);
gl.bind_buffer(copy_dst_target, None);That is actually what it should have been in the first place, I think! You can probably open a PR and someone who understands it better than me will have more insight on whether that's actually the right fix. :) |
|
Thanks, I may do that. Interestingly, it seems like this is the only actual usage of Ideally, I'd like to understand what's going on here well enough to create a more minimal reproduction of the crash. |
|
Oh, you're right. Your change isn't what it's supposed to be. Now I'm remembering more of how this worked. So...
So that code actually looks fine. The error you are getting might not be due to this code at all then. It might be that some code in I'm not totally sure what's wrong, but now I'm thinking that the code you were modifying is probably correct. At least that last |
|
My last train thought that I'll pick up later was that perhaps there's a command out there somewhere that is binding to |
|
I think I'm understanding what's going on here a whole lot better now after diving into the webgl 2 spec. (Relevant sections 5.1, 5.2) Still, I think something fishy may be going on with But So here's my latest attempt: rparrett@856d86e This seems to be working well for me. Next on my list:
|
|
Like most of the WebGL backend, I actually copied it from the GFX GL backend: https://github.com/gfx-rs/gfx/blame/bc77309afdb0829605982370a3e17382c5968071/src/backend/gl/src/queue.rs#L661. It looks like @Gordon-F first made the commit that used the current index buffer tracking. @Gordon-F, do you have any idea what might be going on? |
|
Oh, that's good to know, thanks. Hm, I'm seeing that in the gfx gl backend, |
|
That on its own seems to also resolve my issue. Although I think that the current Still, this makes for a very digestible PR so maybe I'll go for that. |
|
Awesome, good catch! I must have missed that as I migrated it from gfx. 👍 👍 |
Description
Hundreds of this warning, which does not crash the game
Followed eventually by this one, which does
Repro steps
Now play the game naturally. Complete each level in sequence, returning to the level select screen and advancing to the next one. Eventually, clicking the next level will crash the game before the level even appears on the screen. I have had this happen mostly when advancing to level 4 or 5.
When you have played this far already and have solutions saved, you can skip to the level prior to the crash, send the pixies, wait for the popup, and then proceed to the next level.
Extra materials
Traces of the full repro were hundreds of megabytes to gigabytes. Here are what I think are the relevant bits that I was able to extract using a webgl2 context shim and by enabling chrome logging (dev tools will crash)
Initial non-fatal error spam context
This general pattern will repeat many times. As far as I can tell, this doesn't make any sense. It's possible that somewhere earlier that buffer was bound to something else.
Fatal error context
Dropped buffer later bound?
Workaround
It seemed based on the "non-fatal" error traces that "copy buffer to buffer" was failing in some way. Having no idea what this code really does, I attempted this hack: rparrett@12ea780 which I thought made sense at the time, but now I'm pretty sure is just coincidentally making my stuff work.
This did fix the issue for me though. And surprisingly didn't seem to harm other wgpu examples (I could have easily missed something there). Also, another game of mine that was working now continues to work with that patch applied.
Context
The game is
Platform
MacOS 12.0.1 (m1)
Chrome 97, Firefox 95
bevy 0.6 from crates.io (also with patched wgpu dep)
wgpu master 01f62ba
Also tested in Chrome in a Windows/nvidia environment.
Next
I am dumping all the information I have about this issue so that error messages are searchable in case someone else has the same issue.
Please let me know if you are looking into this and I can be of any help.
The text was updated successfully, but these errors were encountered: