Trang này được dịch bởi Cloud Translation API.

Trình điều khiển API mạng thần kinh

Trang này cung cấp tổng quan về cách triển khai trình điều khiển API Mạng thần kinh (NNAPI). Để biết thêm chi tiết, hãy xem tài liệu có trong các tệp định nghĩa HAL trong hardware/interfaces/neuralnetworks . Việc triển khai trình điều khiển mẫu nằm trong frameworks/ml/nn/driver/sample .

Để biết thêm thông tin về API Mạng thần kinh, hãy xem API Mạng thần kinh .

Mạng thần kinh HAL

Mạng thần kinh (NN) HAL định nghĩa một khái niệm trừu tượng về các thiết bị khác nhau , chẳng hạn như bộ xử lý đồ họa (GPU) và bộ xử lý tín hiệu kỹ thuật số (DSP), nằm trong một sản phẩm (ví dụ: điện thoại hoặc máy tính bảng). Trình điều khiển cho các thiết bị này phải phù hợp với NN HAL. Giao diện được chỉ định trong các tệp định nghĩa HAL trong hardware/interfaces/neuralnetworks .

Quy trình chung của giao diện giữa khung và trình điều khiển được mô tả trong hình 1.

Luồng mạng thần kinh

Hình 1. Luồng mạng nơ-ron

Khởi tạo

Khi khởi tạo, khung truy vấn trình điều khiển về các khả năng của nó bằng cách sử dụng IDevice::getCapabilities_1_3 . Cấu trúc @1.3::Capabilities bao gồm tất cả các loại dữ liệu và biểu thị hiệu suất không tương ứng bằng cách sử dụng một vectơ.

Để xác định cách phân bổ tính toán cho các thiết bị có sẵn, khung sử dụng các khả năng để hiểu tốc độ và mức độ hiệu quả năng lượng mà mỗi trình điều khiển có thể thực hiện một thao tác. Để cung cấp thông tin này, trình điều khiển phải cung cấp số hiệu suất được tiêu chuẩn hóa dựa trên việc thực thi khối lượng công việc tham chiếu.

Để xác định các giá trị mà trình điều khiển trả về khi phản hồi IDevice::getCapabilities_1_3 , hãy sử dụng ứng dụng điểm chuẩn NNAPI để đo lường hiệu suất cho các loại dữ liệu tương ứng. Các mô hình MobileNet v1 và v2, asr_float và tts_float được khuyến nghị để đo hiệu suất cho các giá trị dấu phẩy động 32 bit và các mô hình lượng tử hóa MobileNet v1 và v2 được khuyến nghị cho các giá trị lượng tử hóa 8 bit. Để biết thêm thông tin, hãy xem Bộ kiểm tra máy học của Android .

Trong Android 9 trở xuống, cấu trúc Capabilities chỉ bao gồm thông tin về hiệu suất của trình điều khiển cho các tenxơ dấu phẩy động và lượng tử hóa và không bao gồm các loại dữ liệu vô hướng.

Là một phần của quá trình khởi tạo, khung có thể truy vấn thêm thông tin, sử dụng IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensions và IDevice::getNumberOfCacheFilesNeeded .

Giữa các lần khởi động lại sản phẩm, khung mong đợi tất cả các truy vấn được mô tả trong phần này luôn báo cáo các giá trị giống nhau cho một trình điều khiển nhất định. Nếu không, một ứng dụng sử dụng trình điều khiển đó có thể làm giảm hiệu suất hoặc hành vi không chính xác.

biên soạn

Khung xác định thiết bị nào sẽ sử dụng khi nhận được yêu cầu từ ứng dụng. Trong Android 10, các ứng dụng có thể khám phá và chỉ định các thiết bị mà khung chọn. Để biết thêm thông tin, hãy xem Khám phá và gán thiết bị .

Tại thời điểm biên dịch mô hình, khung sẽ gửi mô hình tới từng trình điều khiển ứng cử viên bằng cách gọi IDevice::getSupportedOperations_1_3 . Mỗi trình điều khiển trả về một mảng booleans cho biết hoạt động nào của mô hình được hỗ trợ. Trình điều khiển có thể xác định rằng nó không thể hỗ trợ một hoạt động nhất định vì một số lý do. Ví dụ:

Trình điều khiển không hỗ trợ loại dữ liệu.
Trình điều khiển chỉ hỗ trợ các hoạt động với các thông số đầu vào cụ thể. Ví dụ: một trình điều khiển có thể hỗ trợ 3x3 và 5x5, nhưng không hỗ trợ các thao tác tích chập 7x7.
Trình điều khiển có các ràng buộc về bộ nhớ ngăn không cho nó xử lý các biểu đồ hoặc đầu vào lớn.

Trong quá trình biên dịch, đầu vào, đầu ra và toán hạng bên trong của mô hình, như được mô tả trong OperandLifeTime , có thể có kích thước hoặc thứ hạng không xác định. Để biết thêm thông tin, hãy xem Hình dạng đầu ra .

Khung hướng dẫn từng trình điều khiển được chọn chuẩn bị thực hiện một tập hợp con của mô hình bằng cách gọi IDevice::prepareModel_1_3 . Mỗi trình điều khiển sau đó biên dịch tập hợp con của nó. Ví dụ: trình điều khiển có thể tạo mã hoặc tạo bản sao được sắp xếp lại các trọng số. Vì có thể có một lượng thời gian đáng kể giữa quá trình biên dịch mô hình và thực hiện các yêu cầu, nên không nên chỉ định các tài nguyên như khối lớn bộ nhớ thiết bị trong quá trình biên dịch.

Khi thành công, trình điều khiển trả về một điều khiển @1.3::IPreparedModel . Nếu trình điều khiển trả về mã lỗi khi chuẩn bị tập hợp con của mô hình, khung sẽ chạy toàn bộ mô hình trên CPU.

Để giảm thời gian được sử dụng để biên dịch khi ứng dụng khởi động, trình điều khiển có thể tạo bộ nhớ cache cho quá trình biên dịch. Để biết thêm thông tin, hãy xem Bộ đệm biên dịch .

Chấp hành

Khi một ứng dụng yêu cầu khung thực thi một yêu cầu, khung sẽ gọi phương IPreparedModel::executeSynchronously_1_3 HAL theo mặc định để thực hiện thực thi đồng bộ trên một mô hình đã chuẩn bị. Một yêu cầu cũng có thể được thực thi không đồng bộ bằng cách sử dụng phương thức execute_1_3 , phương thức executeFenced (xem Thực thi có rào cản) hoặc được thực hiện bằng cách sử dụng thực thi liên tục.

Các lệnh gọi thực thi đồng bộ cải thiện hiệu suất và giảm chi phí phân luồng so với các lệnh gọi không đồng bộ vì quyền kiểm soát chỉ được trả lại cho quy trình ứng dụng sau khi quá trình thực thi hoàn tất. Điều này có nghĩa là trình điều khiển không cần một cơ chế riêng biệt để thông báo cho tiến trình ứng dụng rằng việc thực thi đã hoàn tất.

Với phương thức execute_1_3 không đồng bộ, quyền điều khiển sẽ quay lại quy trình ứng dụng sau khi quá trình thực thi bắt đầu và trình điều khiển phải thông báo cho khung khi quá trình thực thi hoàn tất, sử dụng @1.3::IExecutionCallback .

Tham số Request được truyền cho phương thức thực thi liệt kê các toán hạng đầu vào và đầu ra được sử dụng để thực thi. Bộ nhớ lưu trữ dữ liệu toán hạng phải sử dụng thứ tự chính của hàng với thứ nguyên đầu tiên lặp lại chậm nhất và không có phần đệm ở cuối bất kỳ hàng nào. Để biết thêm thông tin về các loại toán hạng, hãy xem Toán hạng .

Đối với trình điều khiển NN HAL 1.2 trở lên, khi một yêu cầu được hoàn thành, trạng thái lỗi, hình dạng đầu ra và thông tin thời gian sẽ được trả về khung. Trong quá trình thực thi, đầu ra hoặc toán hạng bên trong của mô hình có thể có một hoặc nhiều thứ nguyên không xác định hoặc thứ hạng không xác định. Khi ít nhất một toán hạng đầu ra có thứ nguyên hoặc thứ hạng không xác định, trình điều khiển phải trả về thông tin đầu ra có kích thước động.

Đối với trình điều khiển có NN HAL 1.1 trở xuống, chỉ có trạng thái lỗi được trả về khi hoàn thành yêu cầu. Các kích thước cho toán hạng đầu vào và đầu ra phải được chỉ định đầy đủ để quá trình thực thi hoàn tất thành công. Các toán hạng bên trong có thể có một hoặc nhiều thứ nguyên không xác định, nhưng chúng phải có thứ hạng được chỉ định.

Đối với các yêu cầu của người dùng mở rộng trên nhiều trình điều khiển, khung này chịu trách nhiệm dự trữ bộ nhớ trung gian và sắp xếp thứ tự các cuộc gọi đến từng trình điều khiển.

Nhiều yêu cầu có thể được bắt đầu song song trên cùng một @1.3::IPreparedModel . Trình điều khiển có thể thực hiện các yêu cầu song song hoặc tuần tự hóa các lần thực hiện.

Khung có thể yêu cầu trình điều khiển giữ nhiều hơn một mô hình đã chuẩn bị. Ví dụ: chuẩn bị mô hình m1 , chuẩn bị m2 , thực hiện yêu cầu r1 trên m1 , thực hiện r2 trên m2 , thực hiện r3 trên m1 , thực hiện r4 trên m2 , giải phóng (được mô tả trong Dọn dẹp ) m1 và giải phóng m2 .

Để tránh thực thi lần đầu tiên chậm có thể dẫn đến trải nghiệm người dùng kém (ví dụ: giật khung hình đầu tiên), trình điều khiển nên thực hiện hầu hết các lần khởi tạo trong giai đoạn biên dịch. Việc khởi tạo trong lần thực thi đầu tiên nên được giới hạn ở những hành động ảnh hưởng tiêu cực đến tình trạng hệ thống khi được thực hiện sớm, chẳng hạn như đặt trước bộ đệm tạm thời lớn hoặc tăng tốc độ xung nhịp của thiết bị. Các trình điều khiển chỉ có thể chuẩn bị một số lượng hạn chế các mô hình đồng thời có thể phải thực hiện khởi tạo chúng ở lần thực thi đầu tiên.

Trong Android 10 trở lên, trong trường hợp nhiều lần thực thi với cùng một mô hình đã chuẩn bị được thực thi liên tiếp nhanh chóng, khách hàng có thể chọn sử dụng một đối tượng cụm thực thi để liên lạc giữa ứng dụng và quy trình trình điều khiển. Để biết thêm thông tin, hãy xem Thực thi liên tục và Hàng đợi tin nhắn nhanh .

Để cải thiện hiệu suất cho nhiều lần thực thi liên tiếp, trình điều khiển có thể giữ bộ đệm tạm thời hoặc tăng tốc độ xung nhịp. Bạn nên tạo chuỗi theo dõi để giải phóng tài nguyên nếu không có yêu cầu mới nào được tạo sau một khoảng thời gian cố định.

hình dạng đầu ra

Đối với các yêu cầu trong đó một hoặc nhiều toán hạng đầu ra không có tất cả các thứ nguyên được chỉ định, trình điều khiển phải cung cấp danh sách các hình dạng đầu ra chứa thông tin thứ nguyên cho từng toán hạng đầu ra sau khi thực hiện. Để biết thêm thông tin về kích thước, hãy xem OutputShape .

Nếu thực thi không thành công do bộ đệm đầu ra chưa đủ kích thước, thì trình điều khiển phải chỉ ra toán hạng đầu ra nào có kích thước bộ đệm không đủ trong danh sách các hình dạng đầu ra và phải báo cáo càng nhiều thông tin về chiều càng tốt, sử dụng số 0 cho các kích thước không xác định.

thời gian

Trong Android 10, ứng dụng có thể yêu cầu thời gian thực thi nếu ứng dụng đã chỉ định một thiết bị duy nhất để sử dụng trong quá trình biên dịch. Để biết chi tiết, hãy xem MeasureTiming thời gian và Phát hiện và gán thiết bị . Trong trường hợp này, trình điều khiển NN HAL 1.2 phải đo thời lượng thực hiện hoặc báo cáo UINT64_MAX (để cho biết thời lượng không khả dụng) khi thực hiện yêu cầu. Trình điều khiển nên giảm thiểu mọi hình phạt về hiệu suất do đo thời gian thực hiện.

Trình điều khiển báo cáo các khoảng thời gian sau tính bằng micro giây trong cấu trúc Timing :

Thời gian thực hiện trên thiết bị: Không bao gồm thời gian thực hiện trong trình điều khiển chạy trên bộ xử lý máy chủ.
Thời gian thực hiện trong trình điều khiển: Bao gồm thời gian thực hiện trên thiết bị.

Các khoảng thời gian này phải bao gồm thời gian khi quá trình thực thi bị tạm dừng, chẳng hạn như khi quá trình thực thi đã bị các tác vụ khác chiếm trước hoặc khi nó đang chờ tài nguyên có sẵn.

Khi trình điều khiển không được yêu cầu đo thời lượng thực thi hoặc khi có lỗi thực thi, trình điều khiển phải báo cáo thời lượng là UINT64_MAX . Ngay cả khi trình điều khiển đã được yêu cầu đo thời lượng thực thi, thay vào đó, trình điều khiển có thể báo cáo UINT64_MAX về thời gian trên thiết bị, thời gian trong trình điều khiển hoặc cả hai. Khi trình điều khiển báo cáo cả hai thời lượng dưới dạng giá trị khác với UINT64_MAX , thời gian thực thi trong trình điều khiển phải bằng hoặc lớn hơn thời gian trên thiết bị.

hàng rào thực hiện

Trong Android 11, NNAPI cho phép thực thi chờ danh sách xử lý sync_fence và tùy chọn trả về đối tượng sync_fence , được báo hiệu khi quá trình thực thi hoàn tất. Điều này làm giảm chi phí hoạt động cho các mô hình trình tự nhỏ và các trường hợp sử dụng phát trực tuyến. Việc thực thi có rào chắn cũng cho phép khả năng tương tác hiệu quả hơn với các thành phần khác có thể báo hiệu hoặc chờ sync_fence . Để biết thêm thông tin về sync_fence , xem Khung đồng bộ hóa .

Trong thực thi có rào chắn, khung gọi phương thức IPreparedModel::executeFenced để khởi chạy thực thi không đồng bộ, có rào chắn trên một mô hình đã chuẩn bị với một vectơ hàng rào đồng bộ để chờ. Nếu tác vụ không đồng bộ kết thúc trước khi cuộc gọi trả về, một thẻ điều khiển trống có thể được trả về cho sync_fence . Một đối tượng IFencedExecutionCallback cũng phải được trả về để cho phép khung truy vấn thông tin về thời lượng và trạng thái lỗi.

Sau khi thực hiện xong, hai giá trị thời gian đo thời lượng thực thi sau đây có thể được truy vấn thông qua IFencedExecutionCallback::getExecutionInfo .

timingLaunched : Khoảng thời gian từ khi executeFenced được gọi đến khi executeFenced báo hiệu syncFence được trả về.
timingFenced : Khoảng thời gian kể từ khi tất cả các hàng rào đồng bộ hóa mà quá trình thực thi chờ đợi được báo hiệu cho đến khi executeFenced báo hiệu syncFence được trả về.

Kiểm soát dòng chảy

Đối với các thiết bị chạy Android 11 trở lên, NNAPI bao gồm hai hoạt động luồng điều khiển, IF và WHILE , lấy các mô hình khác làm đối số và thực thi chúng theo điều kiện ( IF ) hoặc lặp lại ( WHILE ). Để biết thêm thông tin về cách triển khai điều này, hãy xem Luồng điều khiển .

Chất lượng dịch vụ

Trong Android 11, NNAPI bao gồm chất lượng dịch vụ (QoS) được cải thiện bằng cách cho phép ứng dụng chỉ ra mức độ ưu tiên tương đối của các mô hình, lượng thời gian tối đa dự kiến để một mô hình được chuẩn bị và lượng thời gian tối đa dự kiến cho một lần thực thi được hoàn thành. Để biết thêm thông tin, hãy xem Chất lượng dịch vụ .

Dọn dẹp

Khi một ứng dụng hoàn tất việc sử dụng một mô hình đã chuẩn bị, khung sẽ giải phóng tham chiếu của nó tới đối tượng @1.3::IPreparedModel . Khi đối tượng IPreparedModel không còn được tham chiếu, nó sẽ tự động bị hủy trong dịch vụ trình điều khiển đã tạo ra nó. Các tài nguyên dành riêng cho mô hình có thể được lấy lại tại thời điểm này trong quá trình triển khai hàm hủy của trình điều khiển. Nếu dịch vụ trình điều khiển muốn đối tượng IPreparedModel tự động bị hủy khi máy khách không cần nữa, thì dịch vụ này không được giữ bất kỳ tham chiếu nào đến đối tượng IPreparedModel sau khi đối tượng IPreparedeModel đã được trả về thông qua IPreparedModelCallback::notify_1_3 .

sử dụng CPU

Trình điều khiển dự kiến sẽ sử dụng CPU để thiết lập tính toán. Trình điều khiển không nên sử dụng CPU để thực hiện tính toán biểu đồ vì điều đó cản trở khả năng phân bổ công việc chính xác của khung. Trình điều khiển nên báo cáo các phần mà nó không thể xử lý cho khung và để khung xử lý phần còn lại.

Khung cung cấp triển khai CPU cho tất cả các hoạt động NNAPI ngoại trừ các hoạt động do nhà cung cấp xác định. Để biết thêm thông tin, hãy xem Tiện ích mở rộng của nhà cung cấp .

Các hoạt động được giới thiệu trong Android 10 (API cấp 29) chỉ có triển khai CPU tham chiếu để xác minh rằng các thử nghiệm CTS và VTS là chính xác. Việc triển khai được tối ưu hóa có trong khung máy học di động được ưu tiên hơn triển khai CPU NNAPI.

Các chức năng tiện ích

Cơ sở mã NNAPI bao gồm các chức năng tiện ích có thể được sử dụng bởi các dịch vụ trình điều khiển.

Tệp frameworks/ml/nn/common/include/Utils.h chứa các chức năng tiện ích khác nhau, chẳng hạn như các chức năng được sử dụng để ghi nhật ký và để chuyển đổi giữa các phiên bản NN HAL khác nhau.

VLogging: VLOG là một macro trình bao xung quanh LOG của Android chỉ ghi lại thông báo nếu thẻ thích hợp được đặt trong thuộc tính debug.nn.vlog . initVLogMask() phải được gọi trước bất kỳ lệnh gọi nào tới VLOG . Có thể sử dụng macro VLOG_IS_ON để kiểm tra xem VLOG hiện có được bật hay không, cho phép bỏ qua mã ghi nhật ký phức tạp nếu không cần thiết. Giá trị của tài sản phải là một trong những điều sau đây:
- Một chuỗi trống, cho biết rằng không cần ghi nhật ký.
- Mã thông báo 1 hoặc all , cho biết rằng tất cả việc ghi nhật ký sẽ được thực hiện.
- Một danh sách các thẻ, được phân tách bằng dấu cách, dấu phẩy hoặc dấu hai chấm, cho biết việc ghi nhật ký nào sẽ được thực hiện. Các thẻ là compilation , cpuexe , driver , execution , trình manager và model .
compliantWithV1_* : Trả về true nếu một đối tượng NN HAL có thể được chuyển đổi thành cùng loại của một phiên bản HAL khác mà không làm mất thông tin. Ví dụ: gọi điện compliantWithV1_0 thủWithV1_0 trên V1_2::Model trả về false nếu mô hình bao gồm các loại hoạt động được giới thiệu trong NN HAL 1.1 hoặc NN HAL 1.2.
convertToV1_* : Chuyển đổi một đối tượng NN HAL từ phiên bản này sang phiên bản khác. Một cảnh báo được ghi lại nếu chuyển đổi dẫn đến mất thông tin (nghĩa là nếu phiên bản mới của loại không thể biểu thị đầy đủ giá trị).
Khả năng: Các hàm update và nonExtensionOperandPerformance có thể được sử dụng để giúp xây dựng trường Capabilities::operandPerformance .
Thuộc tính truy vấn của các loại: isExtensionOperandType , isExtensionOperationType , nonExtensionSizeOfData , nonExtensionOperandSizeOfData , nonExtensionOperandTypeIsScalar , tensorHasUnspecifiedDimensions .

Tệp frameworks/ml/nn/common/include/ValidateHal.h chứa các chức năng tiện ích để xác thực rằng một đối tượng NN HAL là hợp lệ theo đặc điểm kỹ thuật của phiên bản HAL.

validate* : Trả về true nếu đối tượng NN HAL hợp lệ theo thông số kỹ thuật của phiên bản HAL. Loại OEM và loại tiện ích mở rộng không được xác thực. Ví dụ: validateModel trả về false nếu mô hình chứa thao tác tham chiếu đến chỉ mục toán hạng không tồn tại hoặc thao tác không được hỗ trợ ở phiên bản HAL đó.

Tệp frameworks/ml/nn/common/include/Tracing.h chứa các macro để đơn giản hóa việc thêm thông tin lập hệ thống vào mã Mạng thần kinh. Để biết ví dụ, hãy xem các lệnh gọi macro NNTRACE_* trong trình điều khiển mẫu .

Tệp frameworks/ml/nn/common/include/GraphDump.h chứa hàm tiện ích để kết xuất nội dung của Model ở dạng đồ họa cho mục đích gỡ lỗi.

graphDump : Ghi một biểu diễn của mô hình ở định dạng Graphviz ( .dot ) vào luồng đã chỉ định (nếu được cung cấp) hoặc vào logcat (nếu không có luồng nào được cung cấp).

Thẩm định

Để kiểm tra việc triển khai NNAPI của bạn, hãy sử dụng các bài kiểm tra VTS và CTS có trong khung Android. VTS thực hiện các trình điều khiển của bạn trực tiếp (không sử dụng khung), trong khi CTS thực hiện chúng gián tiếp thông qua khuôn khổ. Những thử nghiệm này kiểm tra từng phương pháp API và xác minh rằng tất cả các hoạt động được trình điều khiển hỗ trợ đều hoạt động chính xác và cung cấp kết quả đáp ứng các yêu cầu về độ chính xác.

Các yêu cầu về độ chính xác trong CTS và VTS cho NNAPI như sau:

Dấu phẩy động: abs(dự kiến - thực tế) <= atol + rtol * abs(dự kiến); ở đâu:
- Đối với fp32, atol = 1e-5f, rtol = 5,0f * 1,1920928955078125e-7
- Đối với fp16, atol = rtol = 5,0f * 0,0009765625f
Lượng tử hóa: off-by-one (ngoại trừ mobilenet_quantized , off-by-ba)
Boolean: đối sánh chính xác

Một cách CTS kiểm tra NNAPI là tạo các biểu đồ giả ngẫu nhiên cố định được sử dụng để kiểm tra và so sánh kết quả thực thi từ mỗi trình điều khiển với triển khai tham chiếu NNAPI. Đối với trình điều khiển có NN HAL 1.2 trở lên, nếu kết quả không đáp ứng các tiêu chí về độ chính xác, CTS sẽ báo lỗi và kết xuất tệp đặc tả cho mô hình bị lỗi trong /data/local/tmp để gỡ lỗi. Để biết thêm chi tiết về tiêu chí chính xác, hãy xem TestRandomGraph.cpp và TestHarness.h .

thử nghiệm lông tơ

Mục đích của thử nghiệm fuzz là để tìm ra các sự cố, xác nhận, vi phạm bộ nhớ hoặc hành vi không xác định chung trong mã đang được thử nghiệm do các yếu tố như đầu vào không mong muốn. Đối với thử nghiệm làm mờ NNAPI, Android sử dụng các thử nghiệm dựa trên libFuzzer , có hiệu quả trong việc tạo mờ vì chúng sử dụng phạm vi bao phủ của các trường hợp thử nghiệm trước đó để tạo đầu vào ngẫu nhiên mới. Ví dụ: libFuzzer ưu tiên các trường hợp thử nghiệm chạy trên các dòng mã mới. Điều này làm giảm đáng kể lượng thời gian kiểm tra để tìm mã có vấn đề.

Để thực hiện kiểm tra fuzz nhằm xác thực việc triển khai trình điều khiển của bạn, hãy sửa đổi frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp trong tiện ích kiểm tra libneuralnetworks_driver_fuzzer có trong AOSP để bao gồm mã trình điều khiển của bạn. Để biết thêm thông tin về kiểm tra fuzz NNAPI, hãy xem frameworks/ml/nn/runtime/test/android_fuzzing/README.md .

Bảo vệ

Vì các quy trình của ứng dụng giao tiếp trực tiếp với quy trình của trình điều khiển, nên các trình điều khiển phải xác thực các đối số của lệnh gọi mà chúng nhận được. Xác thực này được xác minh bởi VTS. Mã xác thực nằm trong frameworks/ml/nn/common/include/ValidateHal.h .

Trình điều khiển cũng phải đảm bảo rằng các ứng dụng không thể can thiệp vào các ứng dụng khác khi sử dụng cùng một thiết bị.

Bộ kiểm tra máy học Android

Bộ kiểm tra máy học của Android (MLTS) là điểm chuẩn NNAPI có trong CTS và VTS để xác thực tính chính xác của các mô hình thực trên thiết bị của nhà cung cấp. Điểm chuẩn đánh giá độ trễ và độ chính xác, đồng thời so sánh kết quả của trình điều khiển với kết quả sử dụng TF Lite chạy trên CPU, cho cùng một kiểu máy và bộ dữ liệu. Điều này đảm bảo rằng độ chính xác của trình điều khiển không tệ hơn so với việc triển khai tham chiếu CPU.

Các nhà phát triển nền tảng Android cũng sử dụng MLTS để đánh giá độ trễ và độ chính xác của trình điều khiển.

Điểm chuẩn NNAPI có thể được tìm thấy trong hai dự án trong AOSP:

platform/test/mlts/benchmark (ứng dụng điểm chuẩn)
platform/test/mlts/models (mô hình và bộ dữ liệu)

Mô hình và bộ dữ liệu

Điểm chuẩn NNAPI sử dụng các mô hình và bộ dữ liệu sau.

MobileNetV1 float và u8 được lượng tử hóa ở các kích thước khác nhau, chạy trên một tập hợp con nhỏ (1500 hình ảnh) của Open Images Dataset v4.
MobileNetV2 float và u8 được lượng tử hóa ở các kích thước khác nhau, chạy trên một tập con nhỏ (1500 hình ảnh) của Open Images Dataset v4.
Mô hình âm thanh dựa trên bộ nhớ ngắn hạn dài (LSTM) dành cho tính năng chuyển văn bản thành giọng nói, chạy trên một tập hợp con nhỏ của tập hợp CMU Arctic.
Mô hình âm thanh dựa trên LSTM để nhận dạng giọng nói tự động, chạy trên một tập hợp con nhỏ của bộ dữ liệu LibriSpeech.

Để biết thêm thông tin, hãy xem platform/test/mlts/models .

Bài kiểm tra về áp lực

Bộ kiểm tra máy học của Android bao gồm một loạt các kiểm tra sự cố để xác thực khả năng phục hồi của trình điều khiển trong các điều kiện sử dụng nặng hoặc trong các trường hợp nghiêm trọng về hành vi của khách hàng.

Tất cả các thử nghiệm va chạm cung cấp các tính năng sau:

Phát hiện treo: Nếu máy khách NNAPI bị treo trong khi thử nghiệm, thì thử nghiệm đó không thành công với lý do HANG không thành công và bộ thử nghiệm sẽ chuyển sang thử nghiệm tiếp theo.
Phát hiện sự cố ứng dụng khách NNAPI: Thử nghiệm tồn tại sự cố ứng dụng khách và thử nghiệm không thành công với lý do thất bại là CRASH .
Phát hiện sự cố trình điều khiển: Các thử nghiệm có thể phát hiện sự cố trình điều khiển gây ra lỗi trong lệnh gọi NNAPI. Lưu ý rằng có thể có sự cố trong quy trình trình điều khiển không gây ra lỗi NNAPI và không khiến thử nghiệm không thành công. Để khắc phục loại lỗi này, bạn nên chạy lệnh tail trên nhật ký hệ thống để tìm các lỗi hoặc sự cố liên quan đến trình điều khiển.
Nhắm mục tiêu tất cả các trình điều khiển có sẵn: Các thử nghiệm được chạy đối với tất cả các trình điều khiển có sẵn.

Tất cả các thử nghiệm va chạm đều có bốn kết quả có thể xảy ra sau đây:

SUCCESS : Quá trình thực thi đã hoàn tất mà không có lỗi.
FAILURE : Thực thi không thành công. Thường do lỗi khi kiểm tra mô hình gây ra, cho biết trình điều khiển không thể biên dịch hoặc thực thi mô hình.
HANG : Quá trình thử nghiệm không phản hồi.
CRASH : Quá trình thử nghiệm bị lỗi.

Để biết thêm thông tin về thử nghiệm căng thẳng và danh sách đầy đủ các thử nghiệm va chạm, hãy xem platform/test/mlts/benchmark/README.txt .

Sử dụng MLTS

Để sử dụng MLTS:

Kết nối thiết bị mục tiêu với máy trạm của bạn và đảm bảo rằng thiết bị đó có thể truy cập được thông qua adb . Xuất biến môi trường ANDROID_SERIAL thiết bị đích nếu có nhiều thiết bị được kết nối.
cd vào thư mục nguồn cấp cao nhất của Android.
```
source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh
```
Khi kết thúc quá trình chạy điểm chuẩn, kết quả được trình bày dưới dạng trang HTML và được chuyển đến xdg-open .

Để biết thêm thông tin, hãy xem platform/test/mlts/benchmark/README.txt .

Các phiên bản HAL của Mạng nơ-ron

Phần này mô tả những thay đổi được giới thiệu trong các phiên bản HAL của Android và Mạng thần kinh.

Android 11

Android 11 giới thiệu NN HAL 1.3, bao gồm những thay đổi đáng chú ý sau.

Hỗ trợ lượng tử hóa 8 bit đã ký trong NNAPI. Thêm loại toán hạng TENSOR_QUANT8_ASYMM_SIGNED . Trình điều khiển có NN HAL 1.3 hỗ trợ các hoạt động với lượng tử hóa chưa được ký cũng phải hỗ trợ các biến thể đã ký của các hoạt động đó. Khi chạy các phiên bản đã ký và chưa ký của hầu hết các hoạt động được lượng tử hóa, trình điều khiển phải tạo ra cùng một kết quả với độ lệch tối đa là 128. Có năm trường hợp ngoại lệ đối với yêu cầu này: CAST , HASHTABLE_LOOKUP , LSH_PROJECTION , PAD_V2 và QUANTIZED_16BIT_LSTM . QUANTIZED_16BIT_LSTM không hỗ trợ toán hạng có dấu và bốn phép toán khác hỗ trợ lượng tử hóa có dấu nhưng không yêu cầu kết quả giống nhau.
Hỗ trợ cho các thực thi có rào chắn trong đó khung gọi phương thức IPreparedModel::executeFenced để khởi chạy thực thi không đồng bộ, có rào chắn trên một mô hình đã chuẩn bị với một vectơ hàng rào đồng bộ để chờ. Để biết thêm thông tin, hãy xem Thực thi có rào chắn .
Hỗ trợ luồng điều khiển. Thêm các hoạt động IF và WHILE , lấy các mô hình khác làm đối số và thực hiện chúng theo điều kiện ( IF ) hoặc lặp lại ( WHILE ). Để biết thêm thông tin, hãy xem Luồng điều khiển .
Chất lượng dịch vụ (QoS) được cải thiện vì các ứng dụng có thể chỉ ra mức độ ưu tiên tương đối của các mô hình, lượng thời gian tối đa dự kiến để một mô hình được chuẩn bị và lượng thời gian tối đa dự kiến để hoàn thành việc thực thi. Để biết thêm thông tin, hãy xem Chất lượng dịch vụ .
Hỗ trợ miền bộ nhớ cung cấp giao diện cấp phát cho bộ đệm do trình điều khiển quản lý. Điều này cho phép chuyển bộ nhớ riêng của thiết bị qua các lần thực thi, ngăn chặn việc sao chép và chuyển đổi dữ liệu không cần thiết giữa các lần thực thi liên tiếp trên cùng một trình điều khiển. Để biết thêm thông tin, xem Miền bộ nhớ .

Android 10

Android 10 giới thiệu NN HAL 1.2, bao gồm những thay đổi đáng chú ý sau.

Cấu trúc Capabilities bao gồm tất cả các loại dữ liệu bao gồm các loại dữ liệu vô hướng và biểu thị hiệu suất không tương ứng bằng cách sử dụng một vectơ thay vì các trường được đặt tên.
Các phương thức getVersionString và getType cho phép khung truy xuất loại thiết bị ( DeviceType ) và thông tin phiên bản. Xem Khám phá và chỉ định thiết bị .
Phương executeSynchronously được gọi theo mặc định để thực hiện một thao tác thực thi một cách đồng bộ. Phương thức execute_1_2 yêu cầu khung thực hiện thực thi không đồng bộ. Xem Thi hành .
Tham số MeasureTiming để thực executeSynchronously bộ, execute_1_2 và thực thi liên tục chỉ định liệu trình điều khiển có đo thời lượng thực hiện hay không. Các kết quả được báo cáo trong cấu trúc Timing . Xem Thời gian .
Hỗ trợ thực thi trong đó một hoặc nhiều toán hạng đầu ra có thứ nguyên hoặc thứ hạng không xác định. Xem Hình dạng đầu ra .
Hỗ trợ cho các tiện ích mở rộng của nhà cung cấp, là tập hợp các loại dữ liệu và hoạt động do nhà cung cấp xác định. Trình điều khiển báo cáo các phần mở rộng được hỗ trợ thông qua phương thức IDevice::getSupportedExtensions . Xem Tiện ích mở rộng dành cho nhà cung cấp .
Khả năng cho một đối tượng cụm kiểm soát một tập hợp các đợt thực thi bằng cách sử dụng hàng đợi tin nhắn nhanh (FMQ) để giao tiếp giữa ứng dụng và các quy trình trình điều khiển, giúp giảm độ trễ. Xem Thực thi liên tục và Hàng đợi tin nhắn nhanh .
Hỗ trợ AHardwareBuffer để cho phép trình điều khiển thực hiện các thao tác mà không cần sao chép dữ liệu. Xem AHardwareBuffer .
Cải thiện hỗ trợ cho bộ nhớ đệm của các tạo phẩm biên dịch để giảm thời gian được sử dụng để biên dịch khi ứng dụng khởi động. Xem Bộ nhớ đệm biên dịch .

Android 10 giới thiệu các loại toán hạng và hoạt động sau đây.

Các loại toán hạng
- ANEURALNETWORKS_BOOL
- ANEURALNETWORKS_FLOAT16
- ANEURALNETWORKS_TENSOR_BOOL8
- ANEURALNETWORKS_TENSOR_FLOAT16
- ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
- ANEURALNETWORKS_TENSOR_QUANT16_SYMM
- ANEURALNETWORKS_TENSOR_QUANT8_SYMM
- ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL
hoạt động
- ANEURALNETWORKS_ABS
- ANEURALNETWORKS_ARGMAX
- ANEURALNETWORKS_ARGMIN
- ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
- ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
- ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
- ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
- ANEURALNETWORKS_CAST
- ANEURALNETWORKS_CHANNEL_SHUFFLE
- ANEURALNETWORKS_DETECTION_POSTPROCESSING
- ANEURALNETWORKS_EQUAL
- ANEURALNETWORKS_EXP
- ANEURALNETWORKS_EXPAND_DIMS
- ANEURALNETWORKS_GATHER
- ANEURALNETWORKS_GENERATE_PROPOSALS
- ANEURALNETWORKS_GREATER
- ANEURALNETWORKS_GREATER_EQUAL
- ANEURALNETWORKS_GROUPED_CONV_2D
- ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
- ANEURALNETWORKS_INSTANCE_NORMALIZATION
- ANEURALNETWORKS_LESS
- ANEURALNETWORKS_LESS_EQUAL
- ANEURALNETWORKS_LOG
- ANEURALNETWORKS_LOGICAL_AND
- ANEURALNETWORKS_LOGICAL_NOT
- ANEURALNETWORKS_LOGICAL_OR
- ANEURALNETWORKS_LOG_SOFTMAX
- ANEURALNETWORKS_MAXIMUM
- ANEURALNETWORKS_MINIMUM
- ANEURALNETWORKS_NEG
- ANEURALNETWORKS_NOT_EQUAL
- ANEURALNETWORKS_PAD_V2
- ANEURALNETWORKS_POW
- ANEURALNETWORKS_PRELU
- ANEURALNETWORKS_QUANTIZE
- ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
- ANEURALNETWORKS_RANDOM_MULTINOMIAL
- ANEURALNETWORKS_REDUCE_ALL
- ANEURALNETWORKS_REDUCE_ANY
- ANEURALNETWORKS_REDUCE_MAX
- ANEURALNETWORKS_REDUCE_MIN
- ANEURALNETWORKS_REDUCE_PROD
- ANEURALNETWORKS_REDUCE_SUM
- ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
- ANEURALNETWORKS_ROI_ALIGN
- ANEURALNETWORKS_ROI_POOLING
- ANEURALNETWORKS_RSQRT
- ANEURALNETWORKS_SELECT
- ANEURALNETWORKS_SIN
- ANEURALNETWORKS_SLICE
- ANEURALNETWORKS_SPLIT
- ANEURALNETWORKS_SQRT
- ANEURALNETWORKS_TILE
- ANEURALNETWORKS_TOPK_V2
- ANEURALNETWORKS_TRANSPOSE_CONV_2D
- ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
- ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

Android 10 giới thiệu các bản cập nhật cho nhiều hoạt động hiện có. Các bản cập nhật chủ yếu liên quan đến những điều sau đây:

Hỗ trợ bố trí bộ nhớ NCHW
Hỗ trợ cho các tenxơ có thứ hạng khác 4 trong các hoạt động softmax và chuẩn hóa
Hỗ trợ cho các kết cấu giãn nở
Hỗ trợ đầu vào với lượng tử hóa hỗn hợp trong ANEURALNETWORKS_CONCATENATION

Danh sách bên dưới hiển thị các thao tác được sửa đổi trong Android 10. Để biết đầy đủ chi tiết về các thay đổi, hãy xem Mã thao tác trong tài liệu tham khảo NNAPI.

ANEURALNETWORKS_ADD
ANEURALNETWORKS_AVERAGE_POOL_2D
ANEURALNETWORKS_BATCH_TO_SPACE_ND
ANEURALNETWORKS_CONCATENATION
ANEURALNETWORKS_CONV_2D
ANEURALNETWORKS_DEPTHWISE_CONV_2D
ANEURALNETWORKS_DEPTH_TO_SPACE
ANEURALNETWORKS_DEQUANTIZE
ANEURALNETWORKS_DIV
ANEURALNETWORKS_FLOOR
ANEURALNETWORKS_FULLY_CONNECTED
ANEURALNETWORKS_L2_NORMALIZATION
ANEURALNETWORKS_L2_POOL_2D
ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
ANEURALNETWORKS_LOGISTIC
ANEURALNETWORKS_LSH_PROJECTION
ANEURALNETWORKS_LSTM
ANEURALNETWORKS_MAX_POOL_2D
ANEURALNETWORKS_MEAN
ANEURALNETWORKS_MUL
ANEURALNETWORKS_PAD
ANEURALNETWORKS_RELU
ANEURALNETWORKS_RELU1
ANEURALNETWORKS_RELU6
ANEURALNETWORKS_RESHAPE
ANEURALNETWORKS_RESIZE_BILINEAR
ANEURALNETWORKS_RNN
ANEURALNETWORKS_ROI_ALIGN
ANEURALNETWORKS_SOFTMAX
ANEURALNETWORKS_SPACE_TO_BATCH_ND
ANEURALNETWORKS_SPACE_TO_DEPTH
ANEURALNETWORKS_SQUEEZE
ANEURALNETWORKS_STRIDED_SLICE
ANEURALNETWORKS_SUB
ANEURALNETWORKS_SVDF
ANEURALNETWORKS_TANH
ANEURALNETWORKS_TRANSPOSE

android9

NN HAL 1.1 được giới thiệu trong Android 9 và bao gồm những thay đổi đáng chú ý sau.

IDevice::prepareModel_1_1 bao gồm tham số ExecutionPreference . Người lái xe có thể sử dụng điều này để điều chỉnh quá trình chuẩn bị của mình, biết rằng ứng dụng muốn tiết kiệm pin hơn hoặc sẽ thực hiện mô hình trong các cuộc gọi liên tiếp nhanh chóng.
Chín hoạt động mới đã được thêm vào: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
Một ứng dụng có thể chỉ định rằng có thể chạy các phép tính float 32 bit bằng cách sử dụng phạm vi float và/hoặc độ chính xác 16 bit bằng cách đặt Model.relaxComputationFloat32toFloat16 thành true . Cấu trúc Capabilities có trường bổ sung relaxedFloat32toFloat16Performance để trình điều khiển có thể báo cáo hiệu suất thoải mái của nó cho khung.

Android 8.1

Mạng thần kinh đầu tiên HAL (1.0) đã được phát hành trong Android 8.1. Để biết thêm thông tin, hãy xem /neuralnetworks/1.0/ .