-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limited support for pad on CoreML backend #739
Comments
"Reasonable" is the debatable part, but all of these can be emulated (no fewer than 3 operations though). Hopefully future CoreML ops can support them more efficiently someday. Here's pseudocode for each - let me know if anything could make more sense. They are all very similar conceptually to texture wrapping in graphics APIs (OGL, D3D), except in higher dimensions. With the decomposition below, any dimension count is supported, and there are no repetition limits to input size. constantUse
edgeTake a slice of the very edges,
symmetricTile a mirrored chunk, then slice the result.
reflectionSame as symmetric, except that you slice off the very edges before mirroring the inner chunk to tile. So [3,4,5] mirrored becomes [3,4,5,4], and then tiled becomes [3,4,5,4,3,4,5,4,3...]. |
pad
is implemented on CoreML backend but with lots of constraints.On CoreML (See doc), three modes are supported - constant, reflect, replicate(maps to
edge
mode).edge
mode is not supported.)edge
) then beginning and ending paddings can be at most input size.For the third constraint, we can probably update the spec to add such constraint? #377
For the others, my first question is - @fdwr @huningxin are there reasonable emulations for these unsupported modes and rank limits?
Further questions are - @mwyrzykowski do you think if CoreML can improve pad support with:
symmetric
modeconstant
mode.If none of the restrictions can be emulated / nor supported by CoreML, we will need to either:
a. Add these constraints to WebNN API.
b. Expose the modes limits through
opSupportLimits
. The rank constraints are tricky to expose - as it varies by mode.c. Just let them fail on CoreML with async error messages.. - Not ideal for browser compatibility.
The text was updated successfully, but these errors were encountered: