You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the device has string reference to the resources and the resources have strong references to the device. This cycle is manually broken in triage_suspected by looking at the reference count.
We want to remove this manual reference count management and only rely on weak refst to break the cycles.
@cwfitzgerald put together a diagram that illustrates the end result:
The text was updated successfully, but these errors were encountered:
@cwfitzgerald how does the queue fit in the above diagram? The WebGPU spec says that the device has a strong reference to the queue (but we can make it work in the browser either way by having the JS-facing objects have the strong references in the right order even if wgpu-core internally has it the other way around).
Currently the queue has a strong reference in to the device in wgpu-core.
@nical I believe it's "queue owns device", "device has weakref to queue". This doesn't really vibe with the idempotent queue method call on device in WebGPU, but I don't think we need to have that in wgpu-core.
If we were to model the WebGPU way, it would be "device owns InternalQueue", "queue owns InternalQueue". This way the device can hand out the same internal queue over and over to separate Queue objects.
At the moment the device has string reference to the resources and the resources have strong references to the device. This cycle is manually broken in
triage_suspected
by looking at the reference count.We want to remove this manual reference count management and only rely on weak refst to break the cycles.
@cwfitzgerald put together a diagram that illustrates the end result:
The text was updated successfully, but these errors were encountered: