Stable SDK Upgrade Guide#

This guide outlines best practices for upgrading earlier versions of the SDK to version 1.0. Since earlier SDK releases were in “beta,” there are a few minor API changes that may require users to adjust their code.

Note

SDK 1.0 marks the beginning of Stable releases. From this version forward, MemryX will ensure backward compatibility in the APIs to avoid breaking existing applications. While new features may be added, we will strive to prevent disruptions to current apps.

In rare cases where an API change is unavoidable, we will provide a deprecation period to allow users time to transition to the new API.

Additionally, starting with SDK 1.0, all SDK releases (both pip and deb packages) will remain available for download even after a new SDK is released. This ensures that users can access an older version if necessary.

Upgrading to SDK 1.0#

The upgrade to SDK 1.0 involves two key steps: creating a new Python virtual environment and uninstalling older system packages. This is necessary due to the unified versioning introduced in SDK 1.0 for both pip dependencies and deb packages.

Step 1: Create a New Python Virtual Environment

To start, deactivate your existing virtual environment:

deactivate

If your previous virtual environment was named (mx), consider either deleting it or creating a new environment with a fresh name, like (mx1p0):

python3 -m venv ~/mx1p0
source ~/mx1p0/bin/activate

Next, follow the instructions for a fresh SDK installation in the Install Tools guide.

Step 2: Uninstall Existing Deb Packages

Starting with SDK 1.0, all runtime packages have unified versioning. The memx-drivers package is now versioned as 1.0.0, which may appear “older” than SDK 0.10 (e.g., 2.2.36).

To prevent conflicts, uninstall the old drivers and utilities:

sudo apt purge memx-*

After uninstalling, reboot your system. Once rebooted, follow the instructions in the Runtime Installation guide to complete the installation.

Runtime API Changes in SDK 1.0#

SDK 1.0 introduces two key changes to the C++ Runtime API, which may require minor modifications to your existing applications.

Manual-threading Class Separation

If your application uses the manual-threading mode in the C++ runtime, where send/recv functions run in separate threads (instead of the callback-based auto-threading mode), note that the class name has changed.

The manual-threading functionality has been moved to a new class called MxAcclMT. Previously, both manual and auto-threading were managed within MxAccl.

Update your code by adding MT to the class name, as shown below:

// Old
MxAccl *accl = new MxAccl();

should now become:

// New
MxAccl *accl = new MxAcclMT();
DFP Initialization via connect_dfp

In preparation for future SDK features allowing multiple DFP (Data Flow Plan) files, the initialization of DFPs has been moved out of the MxAccl/MxAcclMT constructors and into a separate function called connect_dfp.

While multiple DFPs can be swapped dynamically in the future, it is still best practice to compile all models into a single DFP when possible (see the Multi-Model section for more details).

Previously, DFP initialization looked like this:

MxAccl *accl = new MxAccl("/home/me/yolov9.dfp", 0);

Now, you will need to initialize the accelerator and call connect_dfp separately:

MxAccl *accl = new MxAccl();
accl->connect_dfp("/home/me/yolov9.dfp", 0);

For detailed function syntax, refer to the C++ API reference, and feel free to contact MemryX support if you need further assistance.

No Python API Changes#

There have been no changes to the Python APIs in SDK 1.0. Both the runtime and NeuralCompiler Python APIs remain unchanged, so no modifications are required for your Python applications.

On this page