| 7 Oct 2024 |
 jimb | Demi: I've filed Bug 1923231 to track wgslfuzz. You can CC yourself on that bug if you want to be notified when we start looking into that. | 23:04:42 |
| jimb | In reply to @groves:matrix.org
Most meaningful webidl changes would break the web API for JS too for example, so I think we'll get there eventually This is less true than I thought, though. For example, changing the name of a dictionary type in the WebIDL has no effect on web content, but it's a breaking change in web-sys. Or, similarly, changing the type of an argument to something looser is fine for JS, but breaking for web-sys. | 23:06:47 |
| jimb | I have in mind issues like gpuweb#3573: | 23:07:33 |
| jimb | This has been discussed as a non-breaking editorial change, but it's definitely a breaking change for web-sys. | 23:07:53 |
| jimb | Chrome has a lot of internal and external partners who they consult with regularly to make sure they're happy. So they're already living in the "no going back" web compat world. In that sense, WebGPU is stable. But anyone who's consulting the WebIDL, rather than actually just running JS and seeing what works, is going to have to wait a very long time before they can expect breakage to be rare. | 23:11:02 |
 groves | I think in general wasm-bindgen/web-sys is pretty reaosnable about adding annotations to the webidl or special-casing certain situations, e.g., a type alias would probably be reasonable as an extra annotation on the webidl | 23:13:21 |
 Demi | In reply to @jimb:mozilla.org
Demi: I've filed Bug 1923231 to track wgslfuzz. You can CC yourself on that bug if you want to be notified when we start looking into that. Thank you! I will once I return from travel. | 23:29:57 |
| Demi | In reply to @jimb:mozilla.org
Demi: Yes, we plan to ship WebGPU on Linux in Firefox. Firefox does not knowingly ship features that expose our users to security holes. We'll address Mesa security problems through some combination of blocklisting, validation, workarounds, and upstreaming fixes, on a case-by-case basis. That makes me feel better, thanks! | 23:31:02 |
| 8 Oct 2024 |
 radgerayden | hello, been on a long break and updating wgpu, why was preferred surface removed? | 16:35:08 |
| radgerayden | * hello, been on a long break and updating wgpu, why was preferred surface format removed? | 16:35:55 |
 cwfitzgerald | In reply to @radgerayden:matrix.org
hello, been on a long break and updating wgpu, why was preferred surface format removed? If you look at the surface... Caps you get a list of formats, the 0th format is the preferred | 16:45:17 |
| radgerayden | I see, ty | 16:46:04 |
| radgerayden | code that was previously working now throws CommandBuffer cannot be destroyed because is still in us, if there's an obvious reason do tell me before I spend a couple hours debugging | 18:39:38 |
| radgerayden | * code that was previously working (in 0.19) now throws CommandBuffer cannot be destroyed because is still in use, if there's an obvious reason do tell me before I spend a couple hours debugging | 18:39:53 |
 ErichDonGubler | In reply to @radgerayden:matrix.org
code that was previously working (in 0.19) now throws CommandBuffer cannot be destroyed because is still in use, if there's an obvious reason do tell me before I spend a couple hours debugging Is this on queue submission, perchance? | 19:22:35 |
| radgerayden | yes | 19:22:45 |
| radgerayden | 
Download 0802231601.png | 19:24:09 |
| radgerayden | (not sure if the screenshot of the traceback was sent, I can just paste it if not) | 19:26:19 |
| cwfitzgerald | In reply to @radgerayden:matrix.org
code that was previously working (in 0.19) now throws CommandBuffer cannot be destroyed because is still in use, if there's an obvious reason do tell me before I spend a couple hours debugging This is a bug in how we defined the destructor of the command buffer | 19:37:20 |
| cwfitzgerald | Err renderpass | 19:37:35 |
| radgerayden | is there a workaround? I'm using the release version of wgpu-native, or maybe I should use a more recent commit | 19:38:12 |
| cwfitzgerald | https://github.com/gfx-rs/wgpu/issues/6145 | 19:39:15 |
| cwfitzgerald | Oh you're using wgpu-native | 19:39:25 |
| cwfitzgerald | Are you finishing your renderpass and your command encoder? | 19:39:59 |
| radgerayden | yes | 19:42:49 |
| radgerayden | though I can double check that | 19:43:24 |
| 9 Oct 2024 |
|  Thierry Berger joined the room. | 09:44:31 |
| Thierry Berger | I'm at a point the PR is useful to me ; but I'd like to bring it to "reviewable" ; and I am way out of my comfort zone 😅
I'm seeing 39 failing tests locally ; but I'm based on tag wgpu-v22.1.0 ; and I'm having 32 failing tests there :/
I'll make a list of the new failing tests ; but in the meantime if you have specific feedback/instructions, I'm interested :)
| 09:57:38 |
| ErichDonGubler | Hey all, we were slated to take on a WGPU release this week, and I assigned myself to do it. We need to get this release assigned to someone else, if we want it to happen this week. 😓 As a resident of the Tampa Bay area in Florida, I've spent my work week evacuating from where I live to avoid Hurricane Milton, instead of being able to attend to this. | 11:54:13 |
| cwfitzgerald | @erichdongubler-mozilla:mozilla.org: for the record, I do think that "large scale natural disaster" is a reasonable reason to push the release some weeks - we'll figure something out. Stay safe, wishing you and yours the best | 12:09:36 |
