Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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

Trình điều khiển Neural Networks API

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

Để biết thêm thông tin về Neural Networks API, hãy xem Neural Networks API.

Lớp trừu tượng phần cứng (HAL) cho mạng nơron

HAL Mạng Neural (NN) định nghĩa bản tóm tắt về nhiều thiết bị khác nhau, chẳng hạn như đơn vị xử lý đồ hoạ (GPU) và bộ xử lý tín hiệu kỹ thuật số (DSP), có trong một sản phẩm (ví dụ: điện thoại hoặc máy tính bảng). Yếu tố thúc đẩy cho những chiến dịch này các thiết bị phải tuân thủ NN HAL. Giao diện được chỉ định trong HAL tệp định nghĩa 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 nơron

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

Khởi chạy

Khi khởi chạy, khung này sẽ truy vấn trình điều khiển về các khả năng của khung 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 đơn giản bằng cách sử dụng vectơ.

Để xác định cách phân bổ các phép tính cho các thiết bị có sẵn, Khung này sử dụng các khả năng để nắm được tốc độ và cách thức hiệu quả mà mỗi trình điều khiển có thể thực hiện. Để cung cấp thông tin này, trình điều khiển phải cung cấp số liệu về hiệu suất được chuẩn hoá dựa trên quá trình 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ề để phản hồi IDevice::getCapabilities_1_3, dùng ứng dụng điểm chuẩn NNAPI để đo lường hiệu suất của các kiểu dữ liệu tương ứng. MobileNet v1 và v2, asr_float, và các mô hình tts_float nên dùng để đo lường hiệu suất cho phiên bản 32 bit các giá trị dấu phẩy động và mô hình lượng tử hoá MobileNet v1 và v2 được khuyên dùng cho các giá trị lượng tử hoá 8 bit. Để biết thêm thông tin, hãy xem Bộ kiểm tra công nghệ học máy dành cho Android.

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

Trong quá trình khởi chạy, khung có thể truy vấn thêm thông tin, đang 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 sẽ yêu cầu tất cả các truy vấn được mô tả trong để luôn báo cáo cùng một giá trị cho một trình điều khiển nhất định. Nếu không, một ứng dụng việc 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 dịch

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

Tại thời điểm biên dịch mô hình, khung này sẽ gửi mô hình cho từng đề xuất bằng cách gọi IDevice::getSupportedOperations_1_3. Mỗi trình điều khiển trả về một mảng boolean cho biết các toán tử của mô hình được hỗ trợ. Người lái xe có thể xác định rằng mình 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 này.
Trình điều khiển chỉ hỗ trợ các thao tác có tham số đầu vào cụ thể. Cho ví dụ: một trình điều khiển có thể hỗ trợ 3x3 và 5x5, nhưng không hỗ trợ tích chập 7x7 các toán tử.
Trình điều khiển có các hạn chế về bộ nhớ ngăn không cho xử lý các tệp lớn đồ thị hoặc dữ liệu đầu vào.

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

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

Khi thành công, người lái xe trả về một @1.3::IPreparedModel tên người dùng. Nếu trình điều khiển trả về một mã lỗi khi đang 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 biên dịch khi ứng dụng khởi động, người lái xe có thể cấu phần phần mềm biên dịch bộ nhớ đệm. Để biết thêm thông tin, hãy xem phần Tổng hợp Lưu vào bộ nhớ đệm.

Thực thi

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

Lệnh gọi thực thi đồng bộ giúp cải thiện hiệu suất và giảm phân luồng mức hao tổn cao hơn so với các lệnh gọi không đồng bộ vì quyền kiểm soát được trả về cho lệnh gọi quá trình xử lý ứng dụng chỉ 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 để thông báo cho quy trình của ứng dụng rằng đã hoàn tất quá trình thực thi.

Với phương thức execute_1_3 không đồng bộ, quyền kiểm soát sẽ trả về quá trình ứng dụng sau khi quá trình thực thi đã bắt đầu, đồng thời 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, bằng cách sử dụng @1.3::IExecutionCallback.

Tham số Request được truyền đến phương thức thực thi sẽ liệt kê dữ liệu đầu vào và đầu ra toán hạng được 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 hàng, trong đó thứ nguyên đầu tiên lặp lại chậm nhất và không có thứ nguyên nào khoảng đệ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, xem Toán hạng.

Đối với trình điều khiển NN HAL 1.2 trở lên, khi có yêu cầu đã hoàn tất, trạng thái lỗi, hình dạng đầu ra và thông tin về thời gian được trả về vào khung. Trong quá trình thực thi, đầu ra hoặc toán hạng nội bộ của mô hình có thể có một hoặc nhiều phương diện chưa biết hoặc thứ hạng không xác định. Khi có ít nhất một dữ liệu đầu ra toán hạng có chiều 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 định kích thước một cách linh động.

Đối với trình điều khiển có NN HAL 1.1 hoặc thấp hơn, chỉ trạng thái lỗi được trả về khi đã hoàn tất. Kích thước cho toán hạng đầu vào và đầu ra phải đầy đủ được chỉ định để thực thi hoàn tất thành công. Toán hạng nội bộ có thể có một hoặc nhiều phương diện chưa biết, nhưng chúng phải được chỉ định thứ hạng.

Đố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 về dành riêng bộ nhớ trung gian và để sắp xếp trình tự lệnh gọi đến từng trình điều khiển.

Có thể khởi tạo nhiều yêu cầu song song trên cùng một thiết bị @1.3::IPreparedModel. Trình điều khiển có thể thực thi các yêu cầu song song hoặc chuyển đổi tuần tự các quá trình thực thi.

Khung này có thể yêu cầu người lái xe giữ lại nhiều mô hình đã chuẩn bị. Cho ví dụ: chuẩn bị mô hình m1, chuẩn bị m2, thực thi yêu cầu r1 trên m1, thực thi r2 trên m2, thực thi r3 trên m1, thực thi r4 trên m2, phát hành (như mô tả trong phần Dọn dẹp) m1 và phát hành m2.

Để tránh tình trạng quá trình thực thi lần đầu bị chậm có thể dẫn đến trải nghiệm không tốt cho người dùng (đối với ví dụ như gián đoạn khung hình đầu tiên), trình điều khiển sẽ thực hiện hầu hết các thao tác khởi chạy trong giai đoạn biên dịch. Khởi chạy trong lần thực thi đầu tiên phải được giới hạn trong 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ư dành riêng các vùng đệm tạm thời lớn hoặc tăng tốc độ xung nhịp của thiết bị. Những 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 khởi tạo chúng trong lần thực thi đầu tiên.

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

Để nhanh chóng cải thiện hiệu suất cho nhiều quá trình thực thi liên tiếp, trình điều khiển có thể giữ lại vùng đệm tạm thời hoặc tăng tốc độ xung nhịp. Tạo bộ đếm giờ phòng vệ bạn nên phát hành 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 mà một hoặc nhiều toán hạng đầu ra không có tất cả phương diện đã chỉ định, trình điều khiển phải cung cấp danh sách các hình dạng đầu ra có chứa thông tin về chiều cho mỗi toán hạng đầu ra sau khi thực thi. Để biết thêm thông tin về các phương diện, xem OutputShape.

Nếu quá trình thực thi không thành công do vùng đệm đầu ra có kích thước nhỏ, thì trình điều khiển phải cho biết toán hạng đầu ra nào không có đủ dung lượng bộ nhớ đệm trong danh sách hình dạng đầu ra và nên báo cáo nhiều thông tin thứ nguyên nhất có thể, sử dụng 0 cho các phương diện chưa biết.

Thời gian

Trong Android 10, ứng dụng có thể yêu cầu 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. Cho chi tiết, xem MeasureTiming và Khám phá và chỉ định thiết bị. Trong trường hợp này, Trình điều khiển NN HAL 1.2 phải đo lường thời lượng thực thi hoặc báo cáo UINT64_MAX (để cho biết rằng không có thời lượng) khi thực thi yêu cầu. Tài xế sẽ giảm thiểu mọi tác hại về hiệu suất do việc đo lường quá trình thực thi thời lượng.

Trình điều khiển báo cáo các thời lượng sau đây (tính bằng micrô giây) trong Timing cấu trúc:

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

Các thời lượng này phải bao gồm thời điểm tạm ngưng thực thi, đối với ví dụ: khi quá trình thực thi bị giành trước bởi các tác vụ khác hoặc khi quá trình đó chờ tài nguyên sẵn có.

Khi trình điều khiển chưa đượ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 lường quá trình thực thi thời lượng đó, thì ứng dụng này có thể báo cáo UINT64_MAX về thời gian trên thiết bị, theo thời gian trong trình điều khiển hoặc cả hai. Khi người lái xe báo cáo cả hai khoảng thời gian dưới dạng một giá trị không phải là UINT64_MAX, thời gian thực thi trong trình điều khiển phải bằng hoặc nhiều hơn thời gian trên thiết bị.

Thực thi có bảo vệ

Trong Android 11, NNAPI cho phép các quá trình thực thi chờ một danh sách xử lý sync_fence và tuỳ ý 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 giúp giảm chi phí cho các mô hình trình tự và trường hợp sử dụng phát trực tuyến. Quá trình thực thi có bảo vệ cũng mang lại nhiều lợi ích hơn tương tác hiệu quả với các thành phần khác. Các thành phần này có thể ra tín hiệu hoặc chờ sync_fence. Để biết thêm thông tin về sync_fence, hãy xem Khung đồng bộ hoá.

Trong quá trình thực thi có hàng rào, khung này sẽ gọi IPreparedModel::executeFenced để khởi chạy quá trình thực thi không đồng bộ, có hàng rào trên một mô hình đã chuẩn bị bằng vectơ của hàng rào đồng bộ hoá cần chờ. Nếu tác vụ không đồng bộ đã hoàn tất trước đó lệnh gọi trả về, bạn có thể trả về một tên người dùng trống cho sync_fence. Một Bạn cũng phải trả về đối tượng IFencedExecutionCallback để cho phép khung để truy vấn thông tin về trạng thái lỗi và thời lượng.

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

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

Luồng điều khiển

Đối với các thiết bị chạy Android 11 trở lên, NNAPI bao gồm 2 hoạt động luồng điều khiển, IF và WHILE, sử dụng 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). Cho để biết thêm thông tin về cách triển khai quy trình này, hãy xem Kiểm soát quy trình.

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

Trong Android 11, NNAPI bao gồm việc cải thiện chất lượng của dịch vụ (QoS) 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 để chuẩn bị một mô hình, và lượng thời gian tối đa dự kiến để hoàn thành việc thực thi. Cho thông tin khác, xem Chất lượng dịch vụ.

Dọn dẹp

Khi một ứng dụng sử dụng xong mô hình đã chuẩn bị, khung này sẽ phát hành tham chiếu đến @1.3::IPreparedModel . Khi đối tượng IPreparedModel không còn được tham chiếu nữa, đối tượng đó tự động bị huỷ trong dịch vụ trình điều khiển đã tạo quảng cáo. Theo kiểu máy có thể lấy lại tại thời điểm này trong quá trình triển khai hàm khởi tạo. Nếu dịch vụ lái xe muốn đối tượng IPreparedModel là tự động bị huỷ khi không còn cần đến ứng dụng nữa, thì ứng dụng không được chứa mọi mục tham chiếu đến đối tượng IPreparedModel sau đối tượng IPreparedeModel đã được trả lại qua IPreparedModelCallback::notify_1_3.

Mức sử dụng CPU

Trình điều khiển sẽ sử dụng CPU để thiết lập các phép tính. Trình điều khiển không nên CPU để tính toán đồ thị vì việc này gây trở ngại cho khả năng phân bổ công việc chính xác của khung. Người lái xe sẽ báo cáo các phần mà khung đó không thể xử lý và để khung xử lý nghỉ ngơi.

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

Chiến lược phát hành đĩa đơn các thao tác được giới thiệu trong Android 10 (API cấp 29) chỉ có một quy trình triển khai CPU tham chiếu để xác minh các thử nghiệm CTS và VTS đều chính xác. Các phương pháp triển khai được tối ưu hoá trong công nghệ học máy trên thiết bị di động các khung được ưu tiên hơn so với việc triển khai bằng CPU NNAPI.

Hàm hiệu dụng

Cơ sở mã NNAPI bao gồm các hàm số hiệu dụng mà trình điều khiển có thể sử dụng luôn miễn phí.

Chiến lược phát hành đĩa đơn frameworks/ml/nn/common/include/Utils.h chứa nhiều hàm hiệu dụng, chẳng hạn như hàm 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 bọc xung quanh LOG của Android chỉ ghi lại thông báo nếu thẻ thích hợp được đặt trong debug.nn.vlog thuộc tính này. initVLogMask() phải được gọi trước mọi lệnh gọi đến VLOG. Macro VLOG_IS_ON có thể là dùng để kiểm tra xem VLOG hiện đã được bật hay chưa, cho phép ghi nhật ký phức tạp bỏ qua nếu không cần thiết. Giá trị của thuộc tính phải là một trong các lệnh sau:
- Một chuỗi trống cho biết không cần ghi nhật ký.
- Mã thông báo 1 hoặc all, cho biết rằng đã hoàn tất toàn bộ quá trình ghi nhật ký.
- Danh sách 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 cần thực hiện ghi nhật ký nào. Các thẻ này là compilation, cpuexe, driver, execution, manager và model.
compliantWithV1_*: Trả về true nếu có thể chuyển đổi đối tượng NN HAL thành cùng loại của phiên bản HAL khác mà không mất thông tin. Cho ví dụ: gọi compliantWithV1_0 trên V1_2::Model sẽ 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 đố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 sẽ được ghi lại nếu lượt chuyển đổi dẫn đến việc mất thông tin (tức là là, nếu phiên bản mới của loại không thể thể hiện đầy đủ giá trị).
Chức năng: nonExtensionOperandPerformance và update có thể dùng để giúp tạo Capabilities::operandPerformance .
Truy vấn thuộc tính thuộc các loại: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

Chiến lược phát hành đĩa đơn frameworks/ml/nn/common/include/ValidateHal.h tệp chứa các hàm hiệu dụng để xác thực rằng đối tượng NN HAL là hợp lệ theo thông số 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 không được xác thực. Ví dụ: validateModel trả về false nếu mô hình chứa toán tử tham chiếu đến chỉ mục toán hạng không tồn tại hoặc một thao tác không được hỗ trợ ở phiên bản HAL đó.

Chiến lược phát hành đĩa đơn frameworks/ml/nn/common/include/Tracing.h tệp chứa macro để đơn giản hoá việc thêm Thông tin systrasys (hệ thống) vào mã Neural Networks. Ví dụ: hãy xem các lệnh gọi macro NNTRACE_* trong phần tử trình điều khiển mẫu.

Chiến lược phát hành đĩa đơn frameworks/ml/nn/common/include/GraphDump.h tệp này chứa một hàm hiệu dụng để kết xuất nội dung của Model ở dạng đồ hoạ cho mục đích gỡ lỗi.

graphDump: Viết bản trình bày của mô hình trong Graphviz (.dot) thành luồng được chỉ định (nếu được cung cấp) hoặc thành logcat (nếu được cung cấp) không có luồng nào được cung cấp).

Xác nhận kết quả

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

Sau đây là các yêu cầu về độ chính xác trong CTS và VTS đối với NNAPI:

Dấu phẩy động: abs(dự kiến - thực tế) <= atol + rtol * abs(dự kiến); trong đó:
- Đối với FP32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
- Đối với thẻ SIM16, atol = rtol = 5.0f * 0.0009765625f
Được định lượng hoá: song song một (ngoại trừ mobilenet_quantized, CANNOT TRANSLATE
Boolean: khớp chính xác

Một cách CTS kiểm tra NNAPI là tạo các đồ thị giả ngẫu nhiên cố định được dùng để kiểm thử 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 người lái xe có NN HAL 1.2 hoặc cao hơn, nếu không đáp ứng các tiêu chí về độ chính xác, CTS sẽ báo cáo lỗi và kết xuất cho mô hình bị lỗi trong /data/local/tmp để gỡ lỗi. Để biết thêm thông tin chi tiết về tiêu chí về độ chính xác, hãy xem TestRandomGraph.cpp và TestHarness.h.

Kiểm thử mờ

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

Để thực hiện kiểm thử mờ nhằm xác thực việc triển khai trình điều khiển, hãy sửa đổi frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp trong tiện ích kiểm thử libneuralnetworks_driver_fuzzer được tìm thấy 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 thử mờ NNAPI, hãy xem frameworks/ml/nn/runtime/test/android_fuzzing/README.md.

Bảo mật

Vì các quy trình ứng dụng giao tiếp trực tiếp với quy trình của người lái xe, 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.

Người lái xe cũng phải đảm bảo rằng ứng dụng không được can thiệp vào khi sử dụng cùng một thiết bị.

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

Bộ kiểm thử học máy (MLTS) của Android là một điểm chuẩn NNAPI có trong CTS và VTS để xác thực độ chính xác của các mô hình thực trên thiết bị của nhà cung cấp. Chiến lược phát hành đĩa đơn điểm chuẩn đánh giá độ trễ và độ chính xác, đồng thời so sánh các trình điều khiển kết quả với kết quả bằng cách sử dụng TF Lite chạy trên CPU, cho cùng một mô hình và tập dữ liệu. Điều này đảm bảo rằng kém hơn so với cách 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 người lái xe.

Bạn có thể tìm thấy điểm chuẩn NNAPI 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à tập dữ liệu)

Mô hình và tập dữ liệu

Điểm chuẩn NNAPI sử dụng các mô hình và tập dữ liệu sau đây.

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

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

Kiểm tra căng thẳng

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

Tất cả kiểm thử sự cố đều cung cấp các tính năng sau:

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

Tất cả kiểm thử sự cố đều có thể có 4 kết quả 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 xảy ra do lỗi khi thử nghiệm một mô hình, cho biết rằng 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: Quy trình kiểm thử đã gặp sự cố.

Để biết thêm thông tin về quy trình kiểm thử nghiêm ngặt và danh sách đầy đủ các bài kiểm thử sự cố, vui lòng xem platform/test/mlts/benchmark/README.txt.

Sử dụng MLTS

Cách sử dụng MLTS:

Kết nối một thiết bị mục tiêu với máy trạm của bạn và đảm bảo thiết bị đó tương thích có thể truy cập qua adb. Xuất thiết bị mục tiêu ANDROID_SERIAL biến môi trường 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 lần chạy phép đo điểm chuẩn, kết quả sẽ được trình bày dưới dạng trang HTML và được truyền đến xdg-open.

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

Phiên bản HAL (Lớp trừu tượng phần cứng) cho mạng Neural Networks

Phần này mô tả những thay đổi có trong Android và Neural Phiên bản HAL (Lớp trừu tượng phần cứng) cho mạng.

Android 11

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

Hỗ trợ lượng tử hoá 8 bit có dấu trong NNAPI. Thêm thuộc tính TENSOR_QUANT8_ASYMM_SIGNED loại toán hạng. Trình điều khiển có NN HAL 1.3 hỗ trợ các thao tác có lượng tử hoá chưa ký cũng phải hỗ trợ các biến thể đã ký của các phép toán đó. Khi chạy phiên bản đã ký và chưa ký của hầu hết các phiên bản phép toán lượng tử hoá, thì các trình điều khiển phải cho ra cùng kết quả đến giá trị bù là 128. Có 5 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. Toán tử QUANTIZED_16BIT_LSTM không hỗ trợ toán hạng có dấu và bốn toán tử còn lại hỗ trợ lượng tử hoá có dấu nhưng không yêu cầu kết quả giống nhau.
Hỗ trợ các quá trình thực thi có hàng rào, trong đó khung gọi hàm IPreparedModel::executeFenced để khởi chạy quá trình thực thi không đồng bộ, có hàng rào trên một mô hình đã chuẩn bị bằng vectơ của hàng rào đồng bộ hoá cần chờ. Để biết thêm thông tin, hãy xem Thực thi có bảo vệ.
Hỗ trợ cho quy trình điều khiển. Thêm các thao tác IF và WHILE, các thao tác này sẽ thực hiện các mô hình khác làm đối số và thực thi chúng theo cách có điều kiện (IF) hoặc lặp lại (WHILE). Để biết thêm thông tin, hãy xem Kiểm soát quy trình.
Chất lượng dịch vụ (QoS) được cải thiện vì các ứng dụng có thể cho biết các chỉ số mức độ ưu tiên của các mô hình, thời lượng tối đa dự kiến cho một mô hình cần chuẩn bị và thời gian tối đa dự kiến cho một thực thi được hoàn tất. Để biết thêm thông tin, hãy xem Chất lượng dịch vụ.
Hỗ trợ các miền bộ nhớ cung cấp giao diện trình phân bổ cho vùng đệm do người lái quản lý. Điều này cho phép truyền bộ nhớ gốc của thiết bị trên 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, hãy xem Miền bộ nhớ.

Android 10

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

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

Android 10 ra mắt các loại toán hạng sau và các toán tử.

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
Vận hành
- 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 ứng dụng hiện có các toán tử. Các bản cập nhật chủ yếu liên quan đến:

Hỗ trợ bố cục bộ nhớ NCHW
Hỗ trợ các tensor có thứ hạng khác 4 trong Softmax và toán tử chuẩn hoá
Hỗ trợ tích chập bị giãn
Hỗ trợ đầu vào có lượng tử hoá hỗn hợp trong ANEURALNETWORKS_CONCATENATION

Danh sách dưới đây liệt kê các thao tác được sửa đổi trong Android 10. Dùng cho toàn bộ thông tin chi tiết về những thay đổi, hãy xem Thao tác mã trong tài liệu tham chiếu 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

Android 9

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

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

Android 8.1

Neural Networks HAL (1.0) ban đầu được phát hành trong Android 8.1. Để biết thêm thông tin, xem /neuralnetworks/1.0/.