!FZyQrssSlHEZqrYcOb:matrix.org

In WebGPU we Rust

1093 Members
v0.16 release is go! 67 Servers

Load older messages


SenderMessageTime
30 May 2023
@jimb:mozilla.orgjimb * That all sounds right to me (the 123)21:07:46
@erichdongubler-mozilla:mozilla.orgErich Gubler * (I'd also like to advocate for avoiding log::level::Info as a separate thing, but it seems that wgpu-the-ecosystem operates on a different definition of Info than I'm accustomed to seeing in projects.) 21:08:06
31 May 2023
@jimb:mozilla.orgjimb

Vulkan question:

VUID-vkCmdEndDebugUtilsLabelEXT-commandBuffer-01912 says:

There must be an outstanding vkCmdBeginDebugUtilsLabelEXT command prior to the vkCmdEndDebugUtilsLabelEXT on the queue that commandBuffer is submitted to

but the command buffers submitted to a queue don't necesarily execute in any particular order, unless there's some explicit or implicit synchronization between them. So it's not clear exactly what "prior" means in that rule.

02:34:50
@jimb:mozilla.orgjimbIs it sufficient to assume "submission order"?02:35:15
@kvark:matrix.orgkvark jimb: submission order, yes. 02:36:49
@cwfitzgerald:matrix.orgcwfitzgerald
In reply to @jimb:mozilla.org

Vulkan question:

VUID-vkCmdEndDebugUtilsLabelEXT-commandBuffer-01912 says:

There must be an outstanding vkCmdBeginDebugUtilsLabelEXT command prior to the vkCmdEndDebugUtilsLabelEXT on the queue that commandBuffer is submitted to

but the command buffers submitted to a queue don't necesarily execute in any particular order, unless there's some explicit or implicit synchronization between them. So it's not clear exactly what "prior" means in that rule.

This rule says nothing about execution, just that such a command must exist earlier in the "stream of commands" on the queue
02:36:51
@kvark:matrix.orgkvarka funny aspect of this is that you can begin a label on one command buffer and end in another02:37:23
@cwfitzgerald:matrix.orgcwfitzgeraldThis is very likely the issue at hand, there's an erroneous validation error in that case, and old Mesa drivers crash 02:38:24
@jimb:mozilla.orgjimb

That's right. We discussed all this in wgpu#3733:

  • There is a bug in the validation layer: it requires matching begin/end labels in each command buffer, not on the queue. This is unfixed upstream.
  • There was a bug in Mesa where unmatched pairs would cause a crash. This is fixed upstream.
    See the issue for links.
05:16:21
@jimb:mozilla.orgjimbI was working on a patch for Vulkan-ValidationLayers today, so I wanted to make sure I understood what I was trying to implement (old-fashioned of me, I know)05:16:51
@jimb:mozilla.orgjimb * I was working on a patch for Vulkan-ValidationLayers today, so I wanted to make sure I understood what I was trying to implement (old-fashioned of me, I know, I should just throw it at ChatGPT and hope for the best)05:17:12
@jimb:mozilla.orgjimbThanks for the confirmatino05:17:27
@jimb:mozilla.orgjimb * Thanks for the confirmation05:17:29
@jimb:mozilla.orgjimb It irks me that we do not get clean wgpu test runs right now. We are also running into naga#2034. 05:22:04
@radgerayden:matrix.orgradgeraydenwhen would I use a storage texture?06:32:58
@jolifanto_bambla:matrix.orgLukas HerzbergerI think whenever you need or want to write pixels using `textureStore`. For example, when you do some kind of postprocessing in a compute shader.07:52:59
1 Jun 2023
@radgerayden:matrix.orgradgerayden(using wgpu-native) I seem to be getting a null BindGroupLayout from wgpuRenderPipelineGetBindGroupLayout but I don't get any error messages.01:30:25
@radgerayden:matrix.orgradgeraydenin the end it was unused bindings in the shader, I think01:40:12
@radgerayden:matrix.orgradgerayden well now I get thread '<unnamed>' panicked at 'invalid bind group layout for bind group descriptor', src/device.rs:582:1 but not quite sure how to debug that 01:52:30
@radgerayden:matrix.orgradgeraydenok protip no layout is valid if you don't use the layout :)02:01:32
@radgerayden:matrix.orgradgerayden(I would have appreciated a better error message here)02:01:42
@rajveermalviya:matrix.orgrajveermalviya

can you try the latest build from trunk
library went through a large rewrite and now it has much better error handling & error reporting.

would appreciate your feedback on it.

06:52:13
@radgerayden:matrix.orgradgerayden
In reply to @rajveermalviya:matrix.org

can you try the latest build from trunk
library went through a large rewrite and now it has much better error handling & error reporting.

would appreciate your feedback on it.

I still get the very same error (but now coming from a different source file, naturally):

thread '<unnamed>' panicked at 'invalid bind group layout for bind group descriptor', src/lib.rs:1309:10
06:58:50
@radgerayden:matrix.orgradgeraydenSince this is just a null argument inside a descriptor, I don't think it's reasonable to panic06:59:12
@radgerayden:matrix.orgradgeraydenwell although I guess it's not inconsistent. Maybe the problem is just the error message06:59:50
@rajveermalviya:matrix.orgrajveermalviya

thread '<unnamed>' panicked at 'invalid bind group layout for bind group descriptor', src/lib.rs:1309:10

that just basically means wgpuCreateBindGroup is getting WGPUBindGroupDescriptor.layout == NULL

07:02:07
@radgerayden:matrix.orgradgeraydenbecause it says "for bind group descriptor", it sounds like I have the wrong kind of layout, not a null layout07:02:33
@radgerayden:matrix.orgradgerayden of course, it's not valid for any descriptor 07:02:52
@rajveermalviya:matrix.orgrajveermalviyahmm, i guess the error message could use better wording and be explicit about layout being null, thanks for feedback.07:04:32
@radgerayden:matrix.orgradgeraydenyou're welcome.07:04:42

There are no newer messages yet.


Back to Room ListRoom Version: 5