[Impeller] Fix 1d threadgroup dispatch size, Implement drawPoint geometry computation with compute, fallback to specialized CPU.#42060
Conversation
| layout(local_size_x = 16) in; | ||
|
|
||
| layout(std430) readonly buffer PointData { | ||
| vec2 points[]; |
There was a problem hiding this comment.
You should include a uint count here to guard against OOB access.
There was a problem hiding this comment.
Oh, I see, you put it as a uniform.
There was a problem hiding this comment.
(Consider adding a comment that the count for this is in the uniform)
| point_data; | ||
|
|
||
| layout(std430) writeonly buffer GeometryData { | ||
| vec2 geometry[]; |
There was a problem hiding this comment.
Probably want a count here too?
| // TODO(dnfield): https://github.com/flutter/flutter/issues/112683 | ||
| // We should be able to use length here instead of an extra arrgument. |
There was a problem hiding this comment.
I kind of doubt this will ever get fixed, we should probably just remove these.
There was a problem hiding this comment.
We can actually ifdef/function constant these out based on a runtime flag if the device supports non-uniform threadgroup sizing.
…nto draw_with_compute
|
I found a problem with how dispatch was being done. We were setting the threadGroup size as if it were the threadsize, which resulted in us doing way more work than necessary. I've now fixed this for one dimension, so that the thread group size is correctly computed as the units of work / maxThreadgroupSize. This is still broken for 2D. fyi @dnfield |
|
|
||
| // For now, check that the sizes are uniform. | ||
| FML_DCHECK(grid_size == thread_group_size); | ||
| // FML_DCHECK(grid_size == thread_group_size); |
There was a problem hiding this comment.
I think we should rethink this API. What would make sense to me is 1. specifying the units of work in a grid size.
Maybe there are cases where we need to control threadgroup size? not sure
| } | ||
|
|
||
| auto size = MTLSizeMake(width, height, 1); | ||
| [encoder dispatchThreadgroups:size threadsPerThreadgroup:size]; |
There was a problem hiding this comment.
This is ok but we should really fix this in a separate PR
…int geometry computation with compute, fallback to specialized CPU. (flutter/engine#42060)
flutter/engine@2b14f8a...3267fa2 2023-05-19 bdero@google.com [Impeller] Limit blur kernel to 1000x1000 pixels (flutter/engine#42154) 2023-05-19 skia-flutter-autoroll@skia.org Roll Fuchsia Mac SDK from IGeTvUK2wkajmQQ2k... to pwdDQgM88sqLmZczj... (flutter/engine#42163) 2023-05-19 skia-flutter-autoroll@skia.org Roll Skia from 0a63dbe8cd15 to 7202b405f061 (1 revision) (flutter/engine#42162) 2023-05-19 jonahwilliams@google.com [Impeller] Fix 1d threadgroup dispatch size, Implement drawPoint geometry computation with compute, fallback to specialized CPU. (flutter/engine#42060) Also rolling transitive DEPS: fuchsia/sdk/core/mac-amd64 from IGeTvUK2wkaj to pwdDQgM88sqL If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…7224) flutter/engine@2b14f8a...3267fa2 2023-05-19 bdero@google.com [Impeller] Limit blur kernel to 1000x1000 pixels (flutter/engine#42154) 2023-05-19 skia-flutter-autoroll@skia.org Roll Fuchsia Mac SDK from IGeTvUK2wkajmQQ2k... to pwdDQgM88sqLmZczj... (flutter/engine#42163) 2023-05-19 skia-flutter-autoroll@skia.org Roll Skia from 0a63dbe8cd15 to 7202b405f061 (1 revision) (flutter/engine#42162) 2023-05-19 jonahwilliams@google.com [Impeller] Fix 1d threadgroup dispatch size, Implement drawPoint geometry computation with compute, fallback to specialized CPU. (flutter/engine#42060) Also rolling transitive DEPS: fuchsia/sdk/core/mac-amd64 from IGeTvUK2wkaj to pwdDQgM88sqL If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Compute shader implementation of #41803
I found this to be generally more straightforward, and we can revisit the vertex shader approach with GLES.
Benchmark is pending here: flutter/flutter#126728
Note: rendering behavior is identical even though this is now a single draw call. This is becuase strokes have overdraw prevention enabled by default, while this new contents does not