-
Notifications
You must be signed in to change notification settings - Fork 854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tracing regression in 0.20.0 vs 0.19.4 #5795
Comments
I edited my local cargo cache to insert a debug log on the buffer that's being set to be freed that is crashing things, which you can see below (with some hand formatting for better legibility:
I don't create a buffer with |
So only one place creates a label with that name, the Some debug logging on the args there reveals:
The described buffer to create is supposedly the buffer I'm copying from, but by this point in the trace, that buffer should already exist. But if I slap a seemingly useless So I think that's the end of my bug report for now, as I don't understand why this temporary buffer is needed when copying from this buffer, and I don't know why it's not getting a proper ID during creation, but I do have a workaround for the time being. |
@dfellis: Just the context I'm aware of: We're in the middle of transitioning backend resources to being tracked only by I believe that the solution here is to progress in our migration of resource tracking code that uses CC @teoxoy, @jimblandy. |
@ErichDonGubler understood. Do you know what the timeline is on that conversion? I've realized that my hack to work around this won't cut it because it fails for the OpenGL backend since And with that, I probably have to hold off on upgrading until |
@dfellis: We don't currently have one, but if this conversion is blocking or regressing user code, there's a good chance we can justify prioritizing it! I'll let others comment on further context here, since I don't have it. 😅 |
@ErichDonGubler got it! But in the meantime, I have finally realized what's actually causing the crash in I turned on tracing when I couldn't get my code working on the RISC-V single board computer I bought to specifically try and catch bugs in my code from platform assumptions, and then started getting errors. (Hooray, purchase justified ;) ) In the meantime I figured out that the issue was the Vulkan driver on this SBC doesn't implement everything needed for With the apparent fix for 0.20.0 being to slap Okay, I agree, so let's try and figure out how to replicate whatever Tested it on the RISC-V SBC and it also worked there: the difference is just removing So now I would say my real bug report is that the
|
copy_buffer_to_buffer
regression in 0.20.0 vs 0.19.4
Description
Attempting to use
copy_buffer_to_buffer
in 0.20.0 crashes with:The full backtrace from one of my test runs is:
Somehow, something internal to wgpu doesn't have an ID. I temporarily added
#derive(Debug)
to my own structures and debug logged the buffers I'm passing tocopy_buffer_to_buffer
and they all had IDs, so I'm not sure what exactly is going on, but looking a bit higher up the stack, it looks like it's related to the automatic GPU resource cleanup logic in 0.20.0 though I don't understand why it would be triggered.Repro steps
I put a trimmed version of the code in a gist you just need to copy the
main.rs
file to asrc/main.rs
in a normal Rust project to test it.Expected vs observed behavior
This code, (with minor modifications to remove the
compilation_options
field from theComputePipelineDescriptor
, compiles and runs successfully on 0.19.4, but crashes on 0.20.0Extra materials
I include the trace.zip it generated.
Platform
I've tested this on Fedora/x86-64 and Debian/RISC-V with the same results, only
wgpu
version 0.20.0 is affected.The text was updated successfully, but these errors were encountered: