### Problem description:
In the original code, pointer arithmetic of gain_lut and the assignment of gain_lut[4 * interval + 3] could potentially lead to out-of-bounds array access.
On certain architectures (e.g., macOS ARM64), this out-of-bounds access causes the program to crash.
BUG=None, reported issue#2464
### Solution:
Increase the size of the gain_lut_storage array by 1 to provide an extra buffer and prevent overflow during the calculation within the loop.
### Risks and considerations:
Increasing the array size will slightly increase memory usage.
In extremely resource-constrained systems, alternative algorithm implementations may need to be considered.
The tensorflow-cpu package does not support MacOS or non-x86 hardware. Replacing the tensorflow-cpu python package requirement with the tensorflow meta package should enable the bazel build and the dependent python scripts to be used on those platforms.
BUG=#2367, #1781
The PythonOpsResolver and the utility TflmOpResolver are intended to support all built-in ops allow for models to be tested without code changes. This PR syncs those op resolvers with all available ops from the MicroMutableOpResolver, notably adding BatchMatMul and the Signal ops.
Additionaly, this PR sorts the list alphabetically for readability and adds an alias for the utility TflmOpResolver since it is used in both the benchmarking tool and the layer by layer debugging tool.
BUG=cleanup
The py_tflm_signal_library macro generates multiple targets, some of which are referenced by an internal subdirectory target. This PR adds a default visibility for the package for all targets to be visibile within the subpackage.
BUG=b/316963245
The targets for building the ops should depend on
"//third_party/tflite_micro/python/tflite_micro/signal/utils:util Instead of just their unit tests.
BUG=315941833
Pass a few environmental variables into the bazel build and test of the
tflite_micro package whl during the containerized build for PyPI. By default,
bazel cleans the environment.
Recent changes (presumably) to the package wrapt, installed as a dependency of
the package tensorflow, cause the containerized build of the package
tflite_micro for PyPI targeting Python 3.11 to fail. During wrapt's
installation, setuptools calls pathlib to determine the user's home directory.
pathlib tries HOME in the environment, but falls back on reading the Unix
password database for itself if necessary. This fallback is why
non-containerized environments don't exhibit the failure despite bazel cleaning
HOME from the environment. In the PyPI build container, however, the password
database doesn't contain the invoking user, and pathlib's fallback fails.
To fix, set HOME and pass it through to the action environment of the bazel
build and test. Also pass through a couple of other variables which were also
intended to affect the build and test (in minor ways, such as cache location
and cleaning up a warning).
BUG=fixes #2257
Add mechanism and scripts for building and uploading the Python distribution
package `tflite_micro` to PyPI. These scripts are intended mainly for use by CI
when generating packages for distribution via for PyPI, and won't be used by
most developers. Building a package for local use is still done via a normal
Bazel build.
Heavily comment the scripts with rationale and technical details of the
implementation.
Make significant updates to python/tflite_micro/README.md which explain
building, installing, and uploading the package to PyPI. Leave some cleanup of
the existing text for later.
Add a build setting `--//python/tflite_micro:compatibility_tag` for setting
:whl's platform compatibility tag. Unfortunately, it cannot derived
automatically from the execution environment by the current implementation of
@rules_python.
BUG=part of #1484
`Implementation preserve_all_tensors and getTensor features in TFLM interpreter`
[Design Doc](https://docs.google.com/document/d/13CB93tffg_dDnZYy1QkY3u88yJev4PtZeRY0MLH6n_w/edit?resourcekey=0-htWqjXWneKLXcD6o2SVNJw#heading=h.x9snb54sjlu9)
* PreserveAllTensors is a flag / option being added to the TFLM interpreter that guarantees that post invocation all tensors will be available post invocation with there data untouched.
* GetTensor() is an api being added to the interpreter that allows users to access any tensor in a model by providing the right index but this api is only available when the PreserveAllTensors flag is being used (all the data is guaranteed to be valid and untouched)
*additionally this cl adds functionality for users to instantiate MicroAllocators with LinearMemoryPlanners vs the the default GreedyMemoryPlanner for MicroAllocator create methods that don't currently take a MemoryPlanner as an input
[google3 cl](https://critique.corp.google.com/cl/543518092)
BUG=[b/288141725](https://b.corp.google.com/288141725)
`port c++ PCAN op to open source in tflm_signal`
-port PCAN op and corresponding to new open source location for C++
BUG=[b/294387385](https://b.corp.google.com/issues/294387385)
Add a Bazel target `//python/tflite_micro:whl.publish` that publishes the
Python distribution package to PyPI. Require an authorization token in
the environment. See code comments for usage.
BUG=part of #1484
Use Bazel's workspace status mechanism, designed for "stamping" builds with
identifying information from the build environment, to dynamically generate the
version label of the Python distribution package. Generate stamps when Bazel
runs via the --workspace_status_command option and command script. Then use
these stamps in the version label.
Guidelines for Python version labels are given in [PEP 440][]. TFLM does not
currently tag and publish what PEP 440 calls "final releases". Instead,
distribution packages will periodically be published from the tip of the main
branch, and users will be expected to use the latest version or pin to a
historical version of their choice. To facilitate such use, the build system
needs to generate a unique, ascending version label for each commit on the main
branch.
Guided by [PEP 440][], use developmental version labels of the form
*major[.minor].dev<time>*, for example:
0.dev20090103181505
Use a release segment with a major number of 0 (via the standard Bazel
BUILD_EMBED_LABEL stamp), because TFLM does not currently tag and publish
releases. This leaves room in the version space for making semver-style final
releases in the future. Add a developmental release segment with a date and
time stamp.
Packages should be traceable to the exact source from which they were built.
[PEP 440][] does not allow Git hashes in version labels published to PyPI;
however, the Git hash can be embedded in the package's runtime-visible
attribute `tflite_micro.__version__`, and in the package's description, which
is displayed on PyPI.
[PEP 440]: https://peps.python.org/pep-0440
BUG=part of #1484
Add the build configuration and integrated test to generate a Python
distribution package named `tflite_micro` for publishing the tflm interpreter
as a Python module with a native extension.
Use the build tools provided in @rules_python, augmented by a custom rule
`py_namespace` for the reasons documented in `python/py_namespace.bzl`.
Provide an integration test at `//python/tflite_micro:whl_test`. Use a .tflite
model copied from the hello_world example. (Copied to avoid creating a
dependency.)
BUG=part of #1484
Functionality to use the rest of the Signal Library OPs directly from python.
Test with `bazel run python/tflite_micro/signal:stacker_op_test` and `bazel run python/tflite_micro/signal:filter_bank_ops_test`
BUG=[287346710](http://b/287346710)
We this PR, you can use these ops directly from python, including in TF graphs.
Test with `bazel run python/tflite_micro/signal:framer_op_test`, etc.
BUG=[287346710](http://b/287346710)
Extends the Signal Library Delay OP to be usable from python.
Can test via `bazel run python/tflite_micro/signal:delay_op_test`
BUG=[287346710](http://b/287346710)
This PR adds additional FFT op functionality in the Signal library, namely adding the FFT Auto Scale operation.
Testing added in the original `fft_test.cc` and `fft_ops_test.py`.
BUG=[287346710](http://b/287346710)
`port c++ energy op to open source in tflm_signal`
-port energy op and corresponding to new open source location for C++
BUG=[b/289422411](https://b.corp.google.com/issues/289422411)
`port c++ stacker op to open source in tflm_signal`
-port stacker op and corresponding to new open source location for C++
BUG=[b/289298641](https://b.corp.google.com/issues/289298641)
`port c++ delay op to open source in tflm_signal`
-port delay op and corresponding to new open source location for C++
BUG=[b/289296081](https://b.corp.google.com/issues/289296081)
`port c++ Overlapp_Add op to open source in tflm_signal`
-port Overlapp_Add op and corresponding to new open source location for C++
BUG=[b/289291202](https://b.corp.google.com/issues/289291202)
`port c++ framer op to open source in tflm_signal`
-port framer op and corresponding to new open source location for C++
BUG=[b/288965505](https://b.corp.google.com/288965505)
This is needed to properly build all the ops together. Since we are calling into a singular utils function to load the ops, if it checks for any other ops, it would break before this.
Now we make it build all ops everytime utils.py is built.
BUG=[288938993](http://b/288938993)
Second OP for the TFLM Signal library, Real-Valued Fast Fourier Transform.
The RFFT OP provides three resolutions: `FLOAT, INT16, INT32`
Similar usage as to previous Window OP:
* `op_resolver.AddRfft()` (which will add all resolutions, and determine the type at runtime)
* `op_resolver.AddRfftFloat()`, `op_resolver.AddRfftInt16()`, `op_resolver.AddRfftInt32()` for a specific resolution type.
* or via python as can be seen in `fft_ops_test.py`
3 testing options are provided:
* Micro(C++): bazel run signal/micro/kernels:fft_test
* Tensorflow/Micro(Python): bazel run python/tflite_micro/signal:fft_ops_test
* Makefile(C++): make -f tensorflow/lite/micro/tools/make/Makefile test_kernel_fft_test
BUG=[287346710](http://b/287346710)
To package the module `runtime` as `tflite_micro.runtime`, put `runtime` under
a directory representing the Python namespace package `tflite_micro`. For
organization's sake, move it all to the top-level directory `python/`. Adjust
tests and docs to match.
Some code outside of the Python extension module has come to depend on
`python/tflite_micro:python_ops_resolver` as a replacement for
`all_ops_resolver` (e.g.:`t/l/m/integration_tests/seanet/add/integration_tests.cc`).
`python_ops_resolver` is intended to be a private implementation detail of the
Python extension module. For now, grandfather in the dependent code by updating
its references to the resolver's location; however, soon the dependent code
should be migrated away to a different resolver. (#2033,
https://issuetracker.google.com/286508251)
BUG=part of #1484
We have some name clash issues with the current Window OP name.
We will be changing it from "Window"->"SignalWindow" until the names clashes are resolved and revert back afterwards.
This is an internal implementation detail, so user level API has no change from current usage, i.e. still use (op_resolver.AddWindow() and window_op.window)
BUG=[286250473](http://b/286250473)
First Op for the TFLM Signal Processing Ops library.
Doc linked in bug.
The Window OP is a custom signal processing OP similar to what is found in tf.signal library, but specific for integer (int16) purposes.
You can directly use this as a builtin op via the op resolver as:
* `op_resolver.AddWindow()`
* or via python as shown in `window_op_test.py`
3 testing options are provided:
* Micro(C++): `bazel run signal/micro/kernels:window_test`
* Tensorflow/Micro(Python): `bazel run python/tflite_micro/signal:window_op_test`
* Makefile(C++): `make -f tensorflow/lite/micro/tools/make/Makefile test_kernel_window_test`
BUG=[259145369](http://b/259145369)
Alpha BAO