Implement global shader registry by SS-JIA · Pull Request #2222 · pytorch/executorch

SS-JIA · 2024-03-03T03:43:16Z

Differential Revision: D54447700

Context

This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime.

Before:

gen_vulkan_spv.py generated two files, spv.h and spv.cpp which would contain the definition and initialization of Vulkan shader registry variables.

After:

Introduce the ShaderRegistry class in api/, which encapsulates functionality of the ShaderRegistry class previously defined in the generated spv.h file
Introduce a global shader registry (defined as a static variable in the api::shader_registry() function
Define a ShaderRegisterInit class (taking inspiration from TorchLibraryInit) that allows for dynamic shader registration
gen_vulkan_spv.py now only generates spv.cpp, which defines a static ShaderRegisterInit instance that triggers registration of the compiled shaders to the global shader registry.

Benefits:

Cleaner code base; we no longer have ShaderRegistry defined in a generated file, and don't need a separate implementation file (impl/Registry.*) to handle shader lookup. All that logic now lives under api/ShaderRegistry.*
Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators

pytorch-bot · 2024-03-03T03:43:19Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/2222

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Unrelated Failure

As of commit eb3a381 with merge base 2a42737 ():

NEW FAILURE - The following job has failed:

pull / unittest / linux (buck2) / linux-job (gh)
RuntimeError: Expected to find "executorch_exir_dialects_edge__ops_aten_relu_default" but did not find it

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

Lint / lintrunner / linux-job (gh)
>>> Lint for sdk/inspector/_inspector.py:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

facebook-github-bot · 2024-03-03T03:43:26Z

This pull request was exported from Phabricator. Differential Revision: D54447700

Summary: X-link: pytorch/pytorch#121088 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Differential Revision: D54447700

facebook-github-bot · 2024-03-04T14:44:55Z

This pull request was exported from Phabricator. Differential Revision: D54447700

Summary: X-link: pytorch/pytorch#121088 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Differential Revision: D54447700

facebook-github-bot · 2024-03-04T15:03:36Z

This pull request was exported from Phabricator. Differential Revision: D54447700

Summary: X-link: pytorch/pytorch#121088 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Differential Revision: D54447700

facebook-github-bot · 2024-03-04T17:38:16Z

This pull request was exported from Phabricator. Differential Revision: D54447700

Summary: X-link: pytorch/pytorch#121088 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Differential Revision: D54447700

facebook-github-bot · 2024-03-04T17:41:11Z

This pull request was exported from Phabricator. Differential Revision: D54447700

Summary: X-link: pytorch/pytorch#121088 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Differential Revision: D54447700

Summary: X-link: pytorch/executorch#2222 ## Context This changeset updates Vulkan SPIR-V codegen to introduce a global SPIR-V shader registry and register shaders dynamically at static initialization time. This change makes it possible to define and link custom shader libraries to the ATen-Vulkan runtime. Before: * `gen_vulkan_spv.py` generated two files, `spv.h` and `spv.cpp` which would contain the definition and initialization of Vulkan shader registry variables. After: * Introduce the `ShaderRegistry` class in `api/`, which encapsulates functionality of the `ShaderRegistry` class previously defined in the generated `spv.h` file * Introduce a global shader registry (defined as a static variable in the `api::shader_registry() function` * Define a `ShaderRegisterInit` class (taking inspiration from `TorchLibraryInit`) that allows for dynamic shader registration * `gen_vulkan_spv.py` now only generates `spv.cpp`, which defines a static `ShaderRegisterInit` instance that triggers registration of the compiled shaders to the global shader registry. Benefits: * Cleaner code base; we no longer have `ShaderRegistry` defined in a generated file, and don't need a separate implementation file (`impl/Registry.*`) to handle shader lookup. All that logic now lives under `api/ShaderRegistry.*` * Makes it possible to compile and link separate shader libraries, providing similar flexibility as defining and linking custom ATen operators Test Plan: CI Differential Revision: D54447700

facebook-github-bot · 2024-03-04T18:25:58Z

This pull request was exported from Phabricator. Differential Revision: D54447700

facebook-github-bot · 2024-03-05T03:52:08Z

This pull request has been merged in 6c9880c.

Align `OperatorRegistry` with the style of `ShaderRegistry` in #2222 This means - Improve comments and comment formatting. - Use snake case, even if it deviates from the original registry I was following. Snake case is more consistent with the Vulkan backend code. https://www.internalfb.com/code/fbsource/[a97f9ed1a715231bb61b05942273f1e8f8631503]/fbcode/executorch/runtime/kernel/operator_registry.h?lines=208%2C213 - Move `using` declarations and member variables to top of class definition. - Place static `OperatorRegistry` instance declaration in a global function `operator_registry()` instead of in member function `getInstance()`. - Use macros to wrap `OperatorRegistry` functions instead of global functions. - For simplicity, remove unneeded ctor and assignment operator deletion/hiding. Note users can now create their own non-static `OperatorRegistry` instance and we can consider hiding this again later. Differential Revision: [D54640160](https://our.internmc.facebook.com/intern/diff/D54640160/) [ghstack-poisoned]

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) [ghstack-poisoned]

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) ghstack-source-id: 217857140 Pull Request resolved: #2305

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) [ghstack-poisoned]

Pull Request resolved: #2305 This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. ghstack-source-id: 217867140 @exported-using-ghexport Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/)

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) [ghstack-poisoned]

Pull Request resolved: #2305 This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. ghstack-source-id: 217871298 @exported-using-ghexport Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/)

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) [ghstack-poisoned]

Align `OperatorRegistry` with the style of `ShaderRegistry` in #2222 This means - Improve comments and comment formatting. - Use snake case, even if it deviates from the original registry I was following. Snake case is more consistent with the Vulkan backend code. https://www.internalfb.com/code/fbsource/[a97f9ed1a715231bb61b05942273f1e8f8631503]/fbcode/executorch/runtime/kernel/operator_registry.h?lines=208%2C213 - Move `using` declarations and member variables to top of class definition. - Place static `OperatorRegistry` instance declaration in a global function `operator_registry()` instead of in member function `getInstance()`. - Use macros to wrap `OperatorRegistry` functions instead of global functions. - For simplicity, remove unneeded ctor and assignment operator deletion/hiding. Note users can now create their own non-static `OperatorRegistry` instance and we can consider hiding this again later. Differential Revision: [D54640160](https://our.internmc.facebook.com/intern/diff/D54640160/) [ghstack-poisoned]

This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/) [ghstack-poisoned]

Align `OperatorRegistry` with the style of `ShaderRegistry` in #2222 This means - Improve comments and comment formatting. - Use snake case, even if it deviates from the original registry I was following. Snake case is more consistent with the Vulkan backend code. https://www.internalfb.com/code/fbsource/[a97f9ed1a715231bb61b05942273f1e8f8631503]/fbcode/executorch/runtime/kernel/operator_registry.h?lines=208%2C213 - Move `using` declarations and member variables to top of class definition. - Place static `OperatorRegistry` instance declaration in a global function `operator_registry()` instead of in member function `getInstance()`. - Use macros to wrap `OperatorRegistry` functions instead of global functions. - For simplicity, remove unneeded ctor and assignment operator deletion/hiding. Note users can now create their own non-static `OperatorRegistry` instance and we can consider hiding this again later. Differential Revision: [D54640160](https://our.internmc.facebook.com/intern/diff/D54640160/) [ghstack-poisoned]

Pull Request resolved: #2305 This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. ghstack-source-id: 217884083 @exported-using-ghexport Differential Revision: [D54641117](https://our.internmc.facebook.com/intern/diff/D54641117/)

Summary: bypass-github-export-checks Pull Request resolved: #2304 Align `OperatorRegistry` with the style of `ShaderRegistry` in #2222 This means - Improve comments and comment formatting. - Use snake case, even if it deviates from the original registry I was following. Snake case is more consistent with the Vulkan backend code. https://www.internalfb.com/code/fbsource/[a97f9ed1a715231bb61b05942273f1e8f8631503]/fbcode/executorch/runtime/kernel/operator_registry.h?lines=208%2C213 - Move `using` declarations and member variables to top of class definition. - Place static `OperatorRegistry` instance declaration in a global function `operator_registry()` instead of in member function `getInstance()`. - Use macros to wrap `OperatorRegistry` functions instead of global functions. - For simplicity, remove unneeded ctor and assignment operator deletion/hiding. Note users can now create their own non-static `OperatorRegistry` instance and we can consider hiding this again later. ghstack-source-id: 217884084 exported-using-ghexport Reviewed By: SS-JIA Differential Revision: D54640160 fbshipit-source-id: 298e19b07e505f37326f216e6fa4eb8e6513fec6

Summary: bypass-github-export-checks Pull Request resolved: #2305 This change follows 1. in the footsteps of #2222 for static initialization and 2. the popular `TorchLibraryImpl` for wrapping with macros. https://www.internalfb.com/code/fbsource/[b6860acf0fd7a95224f2ed3f6fe48f699a9a45c0]/fbcode/caffe2/torch/library.h?lines=1004%2C1012-1026 Contributors can now write their operator and register them within the same file using `REGISTER_OPERATORS` + `VK_REGISTER_OP()`, as shown in `Arithmetic.h/cpp`. Typically in Linux/Android C++ environments, the symbols corresponding to `OperatorRegisterInit` static instances are discarded since they aren't used for anything other than static initialization. Hence, we need to `link_whole = True` for the `vulkan_graph_runtime` library. We update our Compute API tests to verify we can go through `OperatorRegistry` with proper static initialization. ghstack-source-id: 217884083 exported-using-ghexport Reviewed By: SS-JIA Differential Revision: D54641117 fbshipit-source-id: f7a01b3e028c05d258fdb1390cda31daed7c5f16

Pull Request resolved: pytorch/executorch#2304 Align `OperatorRegistry` with the style of `ShaderRegistry` in pytorch/executorch#2222 This means - Improve comments and comment formatting. - Use snake case, even if it deviates from the original registry I was following. Snake case is more consistent with the Vulkan backend code. https://www.internalfb.com/code/fbsource/[a97f9ed1a715231bb61b05942273f1e8f8631503]/fbcode/executorch/runtime/kernel/operator_registry.h?lines=208%2C213 - Move `using` declarations and member variables to top of class definition. - Place static `OperatorRegistry` instance declaration in a global function `operator_registry()` instead of in member function `getInstance()`. - Use macros to wrap `OperatorRegistry` functions instead of global functions. - For simplicity, remove unneeded ctor and assignment operator deletion/hiding. Note users can now create their own non-static `OperatorRegistry` instance and we can consider hiding this again later. ghstack-source-id: 217884084 @exported-using-ghexport Differential Revision: [D54640160](https://our.internmc.facebook.com/intern/diff/D54640160/)

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Mar 3, 2024

facebook-github-bot added the fb-exported label Mar 3, 2024

SS-JIA force-pushed the export-D54447700 branch from 63162f5 to c743f4e Compare March 4, 2024 14:44

SS-JIA force-pushed the export-D54447700 branch from c743f4e to 5bea4f5 Compare March 4, 2024 15:03

SS-JIA force-pushed the export-D54447700 branch from 5bea4f5 to 0c26339 Compare March 4, 2024 17:38

SS-JIA force-pushed the export-D54447700 branch from 0c26339 to e6af85e Compare March 4, 2024 17:40

SS-JIA force-pushed the export-D54447700 branch from e6af85e to eb3a381 Compare March 4, 2024 18:25

junpi3 approved these changes Mar 4, 2024

View reviewed changes

facebook-github-bot closed this in 6c9880c Mar 5, 2024

facebook-github-bot added the Merged label Mar 5, 2024

junpi3 mentioned this pull request Mar 7, 2024

[ET-VK][EZ] Clean up OperatorRegistry #2304

Closed

junpi3 mentioned this pull request Mar 7, 2024

[ET-VK] Enable dynamic operator registration #2305

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement global shader registry#2222

Implement global shader registry#2222
SS-JIA wants to merge 1 commit intopytorch:mainfrom
SS-JIA:export-D54447700

SS-JIA commented Mar 3, 2024 •

edited

Loading

Uh oh!

pytorch-bot bot commented Mar 3, 2024 •

edited

Loading

Uh oh!

facebook-github-bot commented Mar 3, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 5, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

SS-JIA commented Mar 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Uh oh!

pytorch-bot bot commented Mar 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/2222

❌ 1 New Failure, 1 Unrelated Failure

Uh oh!

facebook-github-bot commented Mar 3, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 4, 2024

Uh oh!

facebook-github-bot commented Mar 5, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SS-JIA commented Mar 3, 2024 •

edited

Loading

pytorch-bot bot commented Mar 3, 2024 •

edited

Loading