-
Notifications
You must be signed in to change notification settings - Fork 950
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
Bundles still have lifetime constraints #6433
Comments
Those lifetime constraints got lifted for Render & Compute pass not too long ago, see #5884 and related PRs. |
I recently wrote some test code for python that tests deleting objects in the user code even though they area still in use by wgpu. Everything worked perfectly except for Should I file a different bug about the fact that |
part of the same cleanup, I think this issue captures this well enough already. |
Although
wgpu::RenderPass
andwgpu::RenderBundleEncoder
both implement the traitwpu::util::RenderEncoder
, they have different expectations for the lifetime of their common methods. For methods such asset_pipeline
,set_bind_group
, andset_vertex_buffer
,RenderPass
has no expectations for the lifetime of the argument.RenderBundleEncoder
requires that the argument live at least as long asself
.There is no way of enforcing this lifetime restriction in the C interface or the Python interface to this code. This is documented in this bug at wgpu-native.
Attached is RenderBundleEncoderBug.zip
which contains RenderBundleEncoder.py. It is run by calling
python RenderBundleEncoderBug.py <flag>
where for this bug,flag
is one ofnull-pipeline
,null-bind-group
,null-vertex-buffer
,null-index-buffer
,null-indirect-buffer
. These show that nulling any of these values has no affect on aRenderPass
but will cause theRenderBundleEncoder
to panic.My preference is that this lifetime restriction in
RenderBundleEncoder
(andRenderEncoder
) be removed. Whatever techniqueRenderPass
uses to keep track of the objects (and keep them alive?) can certainly be applied toRenderBundleEncoder
.Alternatively,
RenderBundleEncoder
shouldn't panic. It should never panic except for a serious non-recoverable error. this is an error that can easily be reported back to the user.The text was updated successfully, but these errors were encountered: