sagudev
sagudev
This will require some changes in CTS: https://github.com/gpuweb/cts/issues/3809 --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x]...
The main loop is `break`ed at: https://github.com/servo/servo/blob/a730469b704878da9b484b0018f369438ce08851/components/webgpu/wgpu_thread.rs#L635 https://github.com/servo/servo/blob/a730469b704878da9b484b0018f369438ce08851/components/webgpu/wgpu_thread.rs#L688
I manually tested and it works. But if configure canvas is also run it does not get dropped because underlying GPUTexture is have owning ref to GPUDevice, even after page...
Meta bug for all things that need to be done for `mach build` to become `cargo build` alias. #### Sensible default features on servoshell - [ ] `media-beckend` GStreamer -...
Currently we have entries like this: https://github.com/servo/servo/blob/7982f0dc27cad98057a0a953cca76e2b86aa37ed/components/script/dom/bindings/codegen/Bindings.conf#L159-L161 that generate code for: https://github.com/servo/servo/blob/7982f0dc27cad98057a0a953cca76e2b86aa37ed/components/script/dom/gpu.rs#L105-L107 I think every method that returns promise requires this, so we could just automatically assign `inRealms` to such...
Very common pattern in webgpu code is: ```rust if let Err(e) = sender.send(WebGPURequest::ComputePassSetBindGroup { ... }) { warn!("Error sending ComputePassSetBindGroup with: {e:?}") } ``` and it drives me nuts. Instead...
**Is your feature request related to a problem? Please describe.** Spec says that we should invalidate `GPUCommandEncoder` on invalid usage (see [copybuffertobuffer](https://www.w3.org/TR/webgpu/#dom-gpucommandencoder-copybuffertobuffer) for example). Currently error is just returned without...
Running [`webgpu:api,validation,state,device_lost,destroy:queue,writeTexture,2d,uncompressed_format:*`](https://gpuweb.github.io/cts/standalone/?q=webgpu:api,validation,state,device_lost,destroy:queue,writeTexture,2d,uncompressed_format:*) on https://github.com/sagudev/servo/commit/bb841f16edee6d92baf7638155b5d02d1806160a `adapter_request_device` thread: ``` thread backtrace thread #90, name = 'WGPU' frame #0: 0x000071f5b652725d libc.so.6`syscall at syscall.S:38 frame #1: 0x00005eb1f06178a9 servo`parking_lot::raw_rwlock::RawRwLock::wait_for_readers at linux.rs:112:13 frame #2: 0x00005eb1f061788c servo`parking_lot::raw_rwlock::RawRwLock::wait_for_readers...
**Description** More deadlocks between queue.submit and poll_all devices (both threads are running device.maintain). queue.submit thread: ``` thread #107, name = 'WGPU' frame #0: 0x00007ffff6f2725d libc.so.6`syscall at syscall.S:38 frame #1: 0x000055555bd3a8c2...
Here https://github.com/gfx-rs/wgpu/blob/18b758e3889bdd6ffa769085de15e2b96a0c1eb5/wgpu/src/backend/wgpu_core.rs#L286 only `wgc::device::DeviceError::OutOfMemory` error is mapped to `wgpu::Error::OutOfMemory`, while https://docs.rs/wgpu/latest/wgpu/?search=OutOfMemory lists more way `OutOfMemory` variants.