-
Notifications
You must be signed in to change notification settings - Fork 687
Metal backend: Add operator implementations #15023
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
base: gh/manuelcandales/142/head
Are you sure you want to change the base?
Metal backend: Add operator implementations #15023
Conversation
Stack from ghstack (oldest at bottom): |
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/15023
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New Failure, 1 Unrelated FailureAs of commit 4367977 with merge base 6e0c9f6 ( NEW FAILURE - The following job has failed:
FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
* ExecutorTorch implementation of aoti_torch_mps_mm_out. | ||
* Performs simple matrix multiplication: out = self @ mat2 | ||
*/ | ||
AOTITorchError aoti_torch_mps_mm_out( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does custom ops use caching mechanism like the ETMetalShaderLibrary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not yet. These fallback ops are implemented using MPSGraph, so, here we would be caching the graph. This is something I want to look into later when optimizing performance. But this deserves time. In particular, since I never understood why MPSGraph operations have a non-trivial CPU overhead in PyTorch, in spite of PyTorch having a caching mechanism for MPSGraphs.
// For attention weights, zero-fill the GPU buffer (shared memory allows CPU memset) | ||
std::memset(attn_contents_ptr, 0, attn_size_bytes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you need zero filling here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I though it was nicer to return 0, rather than some random stuff.
|
||
// Set output tensor handles | ||
*ret0 = out_tensor_handle; | ||
*ret1 = attn_tensor_handle; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is ret1 actually populated or just zerod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just zeroed.
We are using MPSGraph's scaledDotProductAttention which only returns the output tensor.
We need to return an attention tensor because we need to match _scaled_dot_product_attention_math_for_mps signature. But we don't really need it, it gets thrown away here
Adds bfloat16/float32 working implementations of the following AOTI shim ops: - aoti_torch_mps_mm_out - aoti_torch_mps_convolution - aoti_torch_mps__scaled_dot_product_attention_math_for_mps Adds a stub implementation of aoti_torch_mps_addmm_out ghstack-source-id: 61b8cc4 ghstack-comment-id: 3392300522 Pull-Request: pytorch#15023
Adds bfloat16/float32 working implementations of the following AOTI shim ops:
Adds a stub implementation of aoti_torch_mps_addmm_out