-
Notifications
You must be signed in to change notification settings - Fork 589
Initial framework of an ethos-u runtime backend #501
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
Conversation
Signed-off-by: Rob Elliott <[email protected]>
* basic build system amendments * toolchain file for baremetal platforms * use of ethos-u-core-driver submodule * some scripts to pull a compiler and test-build the backend Signed-off-by: Rob Elliott <[email protected]>
…M, this will be reworked as wrapped ethos buffers in .pte become available Signed-off-by: Rob Elliott <[email protected]>
* Added cmmss submodule dependency * Added command_stream.cpp into the build * Added the target to the build script Signed-off-by: Rob Elliott <[email protected]>
✅ Deploy Preview for resplendent-gnome-14e531 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
* vela binaries returned from preprocess * Included in PTE captured from arm_tosa_e2e * currently assumes vela is on path Signed-off-by: Rob Elliott <[email protected]>
Signed-off-by: Rob Elliott <[email protected]>
* added a scratch block in the vela_bin to preallocate it * added a vela_bin reading routine into ArmBackendEthosU * set pointers passed to vela based on vela_bin Signed-off-by: Rob Elliott <[email protected]>
Also helps with c++11 compliance if we have less c++20 code esp when we don't use it.
* fix to encode and decode of vela_bin_stream block sizes * hardcoded input/output population to check operation behaviour * use manual.h to init and register backend Signed-off-by: Rob Elliott <[email protected]>
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.
Feel free to ignore comments for now ;)
@@ -106,6 +116,10 @@ if(BUILD_SELECTIVE_BUILD_TEST) | |||
option(SELECT_OPS_YAML "Register all the ops from a given yaml file" OFF) | |||
endif() | |||
|
|||
# Build Arm Baremetal backend | |||
option(EXECUTORCH_BUILD_ARM_BAREMETAL |
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.
Nice. If we are planning to have multiple delegate flavors - i.e. runtime logic - under arm
name then we can do something like,
EXECUTORCH_BUILD_ARM && EXECUTORCH_BUILD_ARM_<RUNTIME_FLAVOR>
option(EXECUTORCH_BUILD_ARM_BAREMETAL | |
option(EXECUTORCH_BUILD_ARM |
ET_SWITCH_REAL_TYPES_AND(Bool, b_type, ctx, "add", CTYPE_B, [&]() { | ||
ET_SWITCH_REAL_TYPES_AND(Bool, common_type, ctx, "add", CTYPE_IN, [&]() { | ||
ET_SWITCH_REAL_TYPES_AND(Bool, out_type, ctx, "add", CTYPE_OUT, [&]() { | ||
// ET_SWITCH_REAL_TYPES_AND(Bool, a_type, ctx, "add", CTYPE_A, [&]() { |
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.
Another alternative is that we can switch the CPU-only example to softmax
, while keeping the delegate example to add
so we don't have to deal with this.
Because there is no good short-term solution for this besides we write a custom add
op in ET which overwrites this Portable::Add
@@ -13,6 +13,7 @@ | |||
#include <cstring> | |||
#include <numeric> | |||
#include <type_traits> | |||
#include <cinttypes> |
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.
will be merged soon #558
kernels: | ||
- arg_meta: null | ||
kernel_name: torch::executor::acosh_out | ||
|
||
- op: add.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.
This is temp hack we can do better i.e. supply a new file with one op as oppose to delete rest of the ops in the default one - I was just lazy here :p
namespace torch { | ||
namespace executor { | ||
void manual_override(); | ||
void digant_add_out(torch::executor::KernelRuntimeContext & context, EValue** stack); |
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 was also for testing the manual.h
hack - we don't need this
|
||
/** | ||
* Case 2: A plain function pointer. | ||
* Case 1: A plain function pointer. |
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.
@@ -52,11 +52,9 @@ | |||
#define _ASSERT_PAL_INITIALIZED() \ | |||
({ \ | |||
if (!initialized) { \ | |||
fprintf( \ | |||
ET_LOG_OUTPUT_FILE, \ | |||
printf( \ |
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.
So this is because stderr
is patched to garbage value at link time when I link libexecutorch.a
- easiest solution is to copy this into core_platforms
"app" and overwrite this weak symbol.
Long term plan can be to have platform/target/ArmBaremetal.cpp
PAL layer.
|
||
tosaname = "out.tosa" | ||
flatbuffer = tosa_fb.serialize() | ||
f = open(os.path.join(tmpdir,tosaname), "wb") |
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.
nit: use with
for this resource
np_path = os.path.join(tmpdir,"output","out_sg0_vela.npz") | ||
blocks = b'' | ||
with np.load(np_path, allow_pickle=False) as data: | ||
# Emit the NPZ regions as: |
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.
OK for now but this should be refactored into its own function to emit_block
|
||
# Compilation warnings | ||
add_compile_options( | ||
# -Wall |
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.
we (ET runtime) want to enable these eventually (or at least be cool when someone enables them) but right now we are not ready I guess
Signed-off-by: Rob Elliott <[email protected]>
* Removed dependencies on aything but driver * moved to minimal invocation pattern Signed-off-by: Rob Elliott <[email protected]>
* currently assumes function signature * read relevant argument data from vela_bin Signed-off-by: Rob Elliott <[email protected]>
replaced by #595 |
Added shell of runtime Arm Backend for Ethos-U
./backends/arm/cmake/build.sh
will pull the appropriate compiler and build the ethos-u driver and delegate
This is yet to be linked into the executorch runtime
This also needs to be linked into a higher level app with the .pte in SRAM.
This is for early feedback - assuming some fairly heavy changes from here.