We are first dividing the current usage by 100 then multiplying by the threshold. So we could run into a situation where current usage = budget but because we divided by 100 then multiplied by 100, current usage and budget might no longer be equal.
Differential Revision: https://phabricator.services.mozilla.com/D246758
Notable WebGPU CTS changes:
- Demotions from tier 2 to tier 3:
- `webgpu:shader,execution,expression,unary,{i32,u32}_conversion:f32:*` started regressing on Windows.
- Promotions to tier 2 from tier 3:
- Across all platforms:
- `webgpu:shader,execution,expression,call,builtin,cross:f32:*`
- `webgpu:shader,execution,expression,unary,i32_conversion:abstract_float:*`
- `webgpu:shader,execution,expression,unary,u32_conversion:abstract_float:*`
- `webgpu:shader,execution,limits:nesting_depth_braces:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_copy:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_elementwise:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_mixed:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:scalar_zero_value:*` was promoted on Linux and Windows, but stays in macOS on account of failing `f16` functionality. My guess is that these failures are also present on the other platforms, but we don't see the because `shader-f16` is not aviailable on our other CI platforms yet.
- From macOS, completing the set of all platforms passing:
- `f16` functionality, which, again, was likely not visible on our other CI platforms before:
- `webgpu:shader,execution,expression,call,builtin,cross:f16:*`
- `webgpu:shader,validation,decl,override:type:*`
- `webgpu:api,validation,capability_checks,limits,maxUniformBufferBindingSize:createBindGroup,at_over:*`
was promoted on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D243593
Notable WebGPU CTS changes:
- Demotions from tier 2 to tier 3:
- `webgpu:shader,execution,expression,unary,{i32,u32}_conversion:f32:*` started regressing on Windows.
- Promotions to tier 2 from tier 3:
- Across all platforms:
- `webgpu:shader,execution,expression,call,builtin,cross:f32:*`
- `webgpu:shader,execution,expression,unary,i32_conversion:abstract_float:*`
- `webgpu:shader,execution,expression,unary,u32_conversion:abstract_float:*`
- `webgpu:shader,execution,limits:nesting_depth_braces:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_copy:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_elementwise:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_mixed:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:scalar_zero_value:*` was promoted on Linux and Windows, but stays in macOS on account of failing `f16` functionality. My guess is that these failures are also present on the other platforms, but we don't see the because `shader-f16` is not aviailable on our other CI platforms yet.
- From macOS, completing the set of all platforms passing:
- `f16` functionality, which, again, was likely not visible on our other CI platforms before:
- `webgpu:shader,execution,expression,call,builtin,cross:f16:*`
- `webgpu:shader,validation,decl,override:type:*`
- `webgpu:api,validation,capability_checks,limits,maxUniformBufferBindingSize:createBindGroup,at_over:*`
was promoted on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D243593
WRT WebGPU CTS, we have some interesting changes:
- Promotions from tier 3 to tier 2:
- `webgpu:shader,execution,expression,call,builtin,textureStore:out_of_bounds:*`
- All of `webgpu:shader,execution,expression,binary,ai_arithmetic:*` on Windows and Linux.
- Some of `webgpu:shader,execution,expression,binary,bitwise:*` on Windows and Linux:
- `…:bitwise_and:*`
- `…:bitwise_exclusive_or:*`
- `…:bitwise_or:*`
- `webgpu:shader,execution,expression,call,builtin,textureStore:out_of_bounds:*`
- Some of `webgpu:shader,execution,expression,unary,*` on Windows and Linux:
- `…,ai_assignment:abstract:*`
- `…,ai_assignment:abstract:*`
- `…,ai_complement:complement:*`
- `webgpu:shader,execution,limits:switch_case_selectors:*` on Windows and macOS.
- `webgpu:shader,execution,limits:workgroup_array_byte_size_override:*` on all but Windows debug.
- `webgpu:shader,execution,zero_init:compute,zero_init:*` on macOS.
- `webgpu:shader,validation,expression,access,vector:abstract:*`
- `webgpu:shader,validation,expression,call,builtin,textureGather:offset_argument,non_const:*` on all but Windows debug.
- `webgpu:shader,validation,expression,call,builtin,textureSample:offset_argument,non_const:*`
- `webgpu:shader,validation,expression,call,builtin,textureSampleGrad:offset_argument,non_const:*`
- Most of `webgpu:shader,validation,statement,switch:*`:
- `…:case_types_match:*`
- `…:condition_type_match_case_type:*`
- `…:parse:*`
- Demotions from tier 2 to tier 3:
- `webgpu:api,validation,capability_checks,limits,maxColorAttachmentBytesPerSample:beginRenderPass,at_over:*`
- Otherwise notable potential regressions:
- `webgpu:shader,validation,expression,matrix,mul:overflow_scalar_abstract:*`
Differential Revision: https://phabricator.services.mozilla.com/D242218
Previously we were enforcing a minimum webgpu canvas size of 1x1. This
was causing the following conformance tests to fail:
- webgpu:web_platform,canvas,configure:size_zero_after_configure:*
- webgpu:web_platform,canvas,readbackFromWebGPUCanvas:transferToImageBitmap_zero_size:configure=true
These tests expect a validation error to occur when calling configure()
with a zero-sized canvas, and the readbackFromWebGPUCanvas test
additionally expects transferToImageBitmap() to throw. Neither of these
were occuring.
By allowing the canvas size to be 0x0, we ensure that the snapshotting
code will fail and throw an error. Additionally, we will attempt to
create a 0x0 texture for the swapchain, which the newly added validation
code will prevent and instead raise a validation error.
Differential Revision: https://phabricator.services.mozilla.com/D240748
WebGPU CTS run: https://treeherder.mozilla.org/jobs?repo=try&revision=02e0b7243aedb87972250504dd6bf64d74ff3f96
I updated the patch with the expectations from that run.
There were some regressions in tier 2:
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/execution/expression/call/builtin/textureStore/cts.https.html.ini`
- test path: `webgpu:shader,execution,expression,call,builtin,textureStore:bgra8unorm_swizzle:*`
- with error: "Error: Unexpected validation error occurred: Shader module creation failed: Parsing error"
- see: https://treeherder.mozilla.org/logviewer?job_id=496834446&repo=try&lineNumber=3089
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/call/builtin/value_constructor/cts.https.html.ini`
- new failures related to vector/matrix constructors with abstract types
- see: https://treeherder.mozilla.org/logviewer?job_id=496835790&repo=try&lineNumber=2094
There were also a new failures in tier 3 related to abstract types:
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/and_or_xor/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/bitwise_shift/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/comparison/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/div_rem/cts.https.html.ini`
Overall, there were lots of new passes related to abstract types and I suspect those new failures were actually false positives previously.
Limit tests at `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/api/validation/capability_checks/limits/` are as noisy as always...
One more try push with all the changes: https://treeherder.mozilla.org/jobs?repo=try&revision=e3b4d3b039ca9e84aa2f4ec0b824c4530f41695d
Differential Revision: https://phabricator.services.mozilla.com/D239942
Store last submitted TextureId in PresentationData for getting front buffer snapshot.
WebGPUParent::RecvQueueSubmit() stores the latest TextureId in the swap chain in PresentationData::LastSubmittedTextureId. To do so, it retrieves the OwnerId from ExternalTexture. Next, get PresentationData from OwnerId.
If readback is required, it is performed synchronously. Its implementation is borrowed from WebGPUParent::RecvSwapChainPresent().
Differential Revision: https://phabricator.services.mozilla.com/D233473
To destroy vk::Image and vk::DeviceMemory, VkImageHandle::destroy() uses function pointers that were stored during allocating vk::Image and vk::DeviceMemory. But it caused crashes when they were destroyed after destroying Global.
The change stops to store the function pointers.
Differential Revision: https://phabricator.services.mozilla.com/D234133
This migration was non-trivial!
On the WebGPU side, a change in how load and store operations in render
attachments were represented meant that we needed to re-work FFI for
`RenderPassDepthStencilAttachment` and `RenderPassColorAttachment`, with
most of the effort going towards the former. These types, along with
`Option`, needed FFI-friendly replacements for `Option` and the related
types in `wgpu-core`.
There was also some housekeeping done to avoid duplicate dependencies:
* Create `thiserror` shim that downgrades v2 → v1. Otherwise, v2 would
be brought in by the new WGPU. We can't go in the opposite direction
yet, because `bitsclient` has code that breaks on upgrade. The next
patch in this series addresses this, and reverses the direction of the
shim.
* Also remove the now-unused shim adapting from `cfg_aliases` 0.1 to
0.2.
Co-Authored-By: Jim Blandy <jimb@red-bean.com>
Differential Revision: https://phabricator.services.mozilla.com/D233192
This migration was non-trivial!
On the WebGPU side, a change in how load and store operations in render
attachments were represented meant that we needed to re-work FFI for
`RenderPassDepthStencilAttachment` and `RenderPassColorAttachment`, with
most of the effort going towards the former. These types, along with
`Option`, needed FFI-friendly replacements for `Option` and the related
types in `wgpu-core`.
There was also some housekeeping done to avoid duplicate dependencies:
* Create `thiserror` shim that downgrades v2 → v1. Otherwise, v2 would
be brought in by the new WGPU. We can't go in the opposite direction
yet, because `bitsclient` has code that breaks on upgrade. The next
patch in this series addresses this, and reverses the direction of the
shim.
* Also remove the now-unused shim adapting from `cfg_aliases` 0.1 to
0.2.
Differential Revision: https://phabricator.services.mozilla.com/D233192
It is invalid to configure a GPUCanvasContext to 'GPUStorageBinding' usage with 'bgra8unorm' format on a GPUDevice with 'bgra8unorm-storage' disabled. When ExternalTexture is used, it is not checked.
Differential Revision: https://phabricator.services.mozilla.com/D232316
When WebGPUParent::RecvSwapChainPresent() does readback, there is still pending ReadbackPresentCallback() exists. Since the callback is going to be called by next wgpu_server_queue_submit() or next wgpu_server_poll_all_devices().
Global::device_poll() triggers the ReadbackPresentCallback() if the callback is pending state.
Differential Revision: https://phabricator.services.mozilla.com/D232915
