Handle wgpu::Texture::Destroy() correctly
Categories
(Core :: Graphics: WebGPU, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: sotaro, Assigned: nical)
References
Details
Crash Data
Attachments
(1 file)
Texture::Destroy() is implemented as part of Bug 1856787. But it causes the regression Bug 1860921. Texture::Destroy() should be handled correctly
Reporter | ||
Comment 1•1 year ago
•
|
||
Just implementing Texture::Destroy() { Cleanup(); } caused the following crashes.
- https://searchfox.org/mozilla-central/rev/aa189da432fac500242d9374f044947357f7144e/third_party/rust/wgpu-core/src/storage.rs#125
- https://searchfox.org/mozilla-central/rev/aa189da432fac500242d9374f044947357f7144e/third_party/rust/wgpu-core/src/storage.rs#128
jimb, :nical, any ideas on how to implement Texture::Destroy()?
Assignee | ||
Comment 2•1 year ago
|
||
I suspect that if we run into these crashes it is because Texture::Destroy
ended up calling texture_drop
on the wgpu side. All of the _drop
functions in wgpu are only meant to be used when the last reference to the texture is gone. Generally there are _destroy
methods which do some deinitialization but keep the texture registered with a flag marking it as invalid.
Assignee | ||
Comment 3•1 year ago
|
||
Yeah so I had a look and the situation was as I descried. I'll implement it since I am familiar with it.
Assignee | ||
Comment 4•1 year ago
|
||
Comment 6•1 year ago
|
||
Backed out for causing build bustages in RefPtr.h
- Backout link
- Push with failures
- Failure Log
- Failure line: /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:54:38: error: member access into incomplete type 'mozilla::webgpu::CommandEncoder'
Comment 8•1 year ago
|
||
Backed out along with Bug 1861985 & Bug 1865364 for causing bustage due to CommandEncoder.
Comment 10•1 year ago
|
||
bugherder |
Assignee | ||
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Copying crash signatures from duplicate bugs.
Description
•