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

Trang này cung cấp thông tin 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 tệp định nghĩa HAL trong hardware/interfaces/neuralnetworks . Việc triển khai trình điều khiển mẫu có 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

HAL của Mạng thần kinh (NN) xác định mức độ trừu tượng của 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 số (DSP), có 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 tuân theo NN HAL. Giao diện được chỉ định trong các tệp định nghĩa HAL trong hardware/interfaces/neuralnetworks .

Luồng 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 thần kinh

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 được giảm bớt bằng cách sử dụng 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 khi thực thi. Để cung cấp thông tin này, người lái xe 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 hiện 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 , hãy sử dụng ứng dụng điểm chuẩn NNAPI để đo 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_floattts_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 hiệu suất trình điều khiển cho dấu phẩy động và tensor lượng tử hóa, đồng thời không bao gồm các kiểu 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 bằng cách sử dụng IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensionsIDevice::getNumberOfCacheFilesNeeded .

Giữa các lần khởi động lại sản phẩm, khung yêu cầu 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, ứng dụng sử dụng trình điều khiển đó có thể bị giảm hiệu suất hoặc có hành vi không chính xác.

biên soạn

Khung này xác định thiết bị nào sẽ sử dụng khi nhận được yêu cầu từ mộ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à hệ thống chọn từ đó. Để biết thêm thông tin, hãy xem Khám phá và phân công thiết bị .

Tại thời điểm biên dịch mô hình, khung sẽ gửi mô hình đến từng trình điều khiển ứng 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 boolean 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 thao tác nhất định vì một số lý do. Ví dụ:

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

Trong quá trình biên dịch, các toán hạng đầu vào, đầu ra và nội bộ của mô hình, như được mô tả trong OperandLifeTime , có thể có thứ nguyên 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 này hướng dẫn mỗi trình điều khiển được chọn chuẩn bị thực thi 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ố. Bởi vì có thể có một khoả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 bộ nhớ thiết bị lớn trong quá trình biên dịch.

Nếu thành công, trình điều khiển sẽ trả về một thẻ đ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 biên dịch khi ứng dụng khởi động, trình điều khiển có thể lưu vào bộ nhớ đệm các thành phần 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 này sẽ gọi phương thức IPreparedModel::executeSynchronously_1_3 HAL theo mặc định để thực hiện thực thi đồng bộ trên 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 chắn ) hoặc được thực thi bằng cách sử dụng thực thi cụm .

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 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 cơ chế riêng để thông báo cho quy trình ứng dụng rằng quá trình thực thi đã hoàn tất.

Với phương thức execute_1_3 không đồng bộ, đ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 bằng cách 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ự hàng chính với chiều đầ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 yêu cầu được hoàn thành, trạng thái lỗi, hình dạng đầu rathô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 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ỉ trả về trạng thái lỗi khi yêu cầu hoàn tất. Kích thước của 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 nội bộ 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 trải rộng trên nhiều trình điều khiển, khung 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 thi.

Khung có thể yêu cầu trình điều khiển giữ nhiều mô hình đã chuẩn bị sẵn. 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 thi r3 trên m1 , thực thi r4 trên m2 , phát hành (được mô tả trong Cleanup ) m1 và phát hành m2 .

Để tránh quá trình thực thi lần đầu 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 phải 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 quá trình khởi tạo ở 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, máy khách có thể chọn sử dụng đối tượng cụm thực thi để giao tiếp giữa các quy trình của ứng dụng và trình điều khiển. Để biết thêm thông tin, hãy xem Thực thi hàng loạt 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ữ lại bộ đệm tạm thời hoặc tăng tốc độ xung nhịp. Nên tạo một chuỗi cơ quan giám sát để 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 thi. Để biết thêm thông tin về kích thước, hãy xem OutputShape .

Nếu quá trình thực thi không thành công do bộ đệm đầu ra có kích thước nhỏ, 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 chưa 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 MeasureTimingKhám phá và phân công 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 thi hoặc báo cáo UINT64_MAX (để cho biết rằng thời lượng đó không khả dụng) khi thực hiện yêu cầu. Người lái xe nên giảm thiểu mọi hình phạt về hiệu suất do việc đ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 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 trên driver: Bao gồm thời gian thực thi trên thiết bị.

Các khoảng thời gian này phải bao gồm thời gian khi việc thực thi bị tạm dừng, ví dụ: khi việc 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 sẵn sàng.

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 khoảng thời gian dưới dạng giá trị khác UINT64_MAX , thời gian thực hiện trong trình điều khiển phải bằng hoặc vượt quá thời gian trên thiết bị.

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

Trong Android 11, NNAPI cho phép các lệnh thực thi chờ danh sách các thẻ điều khiển sync_fence và tùy ý trả về một đố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 chuỗi 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 , hãy xem Khung đồng bộ hóa .

Trong quá trình thực thi có rào chắn, khung này gọi phương thức IPreparedModel::executeFenced để khởi chạy một quá trình thực thi không đồng bộ, có rào chắn trên một mô hình đã chuẩn bị sẵn với một vectơ hàng rào đồng bộ đang chờ. Nếu tác vụ không đồng bộ hoàn thành trước khi cuộc gọi quay trở lại, một đ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ề trạng thái và thời lượng lỗi.

Sau khi quá trình thực thi hoàn tất, hai giá trị thời gian sau đây đo thời lượng thực thi 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 từ khi tất 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 thao tác luồng điều khiển IFWHILE 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 đi 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 của nó, 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 ​​​​để thực thi để được hoàn thành. Để biết thêm thông tin, 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ô hình đã chuẩn bị, khung sẽ giải phóng tham chiếu của nó đến đối tượng @1.3::IPreparedModel . Khi đối tượng IPreparedModel không còn được tham chiếu nữa, 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 cần thiết nữa thì nó 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 .

mức 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 những phần mà nó không thể xử lý được cho khung và để khung xử lý phần còn lại.

Khung này 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ó hoạt động 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 so với việc 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.

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à macro bao quanh LOG của Android, chỉ ghi nhật ký 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 . Macro VLOG_IS_ON có thể được sử dụng để 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 giá trị sau:

    • Một chuỗi trống, biểu thị rằng không cần thực hiện việc 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.
    • Danh sách các thẻ, được phân cá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 , managermodel .
  • compliantWithV1_* : Trả về true nếu một đối tượng NN HAL có thể được chuyển đổi sang cùng loại của phiên bản HAL khác mà không làm mất thông tin. Ví dụ: gọi compliantWithV1_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 đối tượng NN HAL từ phiên bản này sang phiên bản khác. Cảnh báo sẽ đượ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ể thể hiện đầy đủ giá trị).

  • Khả năng: Các hàm updatenonExtensionOperandPerformance có thể được sử dụng để giúp xây dựng trường Capabilities::operandPerformance .

  • Truy vấn thuộc tính 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 hàm tiện ích để xác thực rằng một đối tượng NN HAL là hợp lệ theo thông số kỹ thuật của phiên bản HAL của nó.

  • validate* : Trả về true nếu đối tượng NN HAL hợp lệ theo đặc tả của phiên bản HAL của nó. Các loại OEM và các 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 macro để đơn giản hóa việc thêm thông tin hệ thống vào mã Mạng thần kinh. Để biết ví dụ, hãy xem 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 nhằm mục đích gỡ lỗi.

  • graphDump : Ghi bản trình bày của mô hình ở định dạng Graphviz ( .dot ) vào luồng được 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 một cách trực tiếp (không sử dụng khung), trong khi CTS thực hiện chúng một cách gián tiếp thông qua khung. Chúng 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 đối với 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 , là off-by-ba)

  • Boolean: khớp chính xác

Một cách CTS kiểm tra NNAPI là tạo ra các biểu đồ giả ngẫu nhiên cố định 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 việc triển khai tham chiếu NNAPI. Đối với các trình điều khiển có NN HAL 1.2 trở lên, nếu kết quả không đáp ứng tiêu chí về độ chính xác, CTS sẽ báo lỗi và lưu tệp thông số kỹ thuậ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.cppTestHarness.h .

Kiểm tra lông tơ

Mục đích của kiểm tra fuzz là tìm ra các sự cố, xác nhận, vi phạm bộ nhớ hoặc hành vi chung không xác định trong mã đang được kiểm tra do các yếu tố như đầu vào không mong muốn. Đối với thử nghiệm fuzz NNAPI, Android sử dụng các thử nghiệm dựa trên libFuzzer , phương pháp này có hiệu quả trong việc làm mờ vì chúng sử dụng phạm vi dòng 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ề thử nghiệm 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 trình điều khiển phải xác thực các đối số của cuộc gọi mà họ nhận được. Việc xác nhận 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ộ thử nghiệm học máy của 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 mô hình 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 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:

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 cỡ khác nhau, chạy trên một tập hợp con nhỏ (1500 hình ảnh) của Bộ dữ liệu hình ảnh mở v4.
  • MobileNetV2 float và u8 được lượng tử hóa ở các kích cỡ khác nhau, chạy trên một tập hợp con nhỏ (1500 hình ảnh) của Bộ dữ liệu hình ảnh mở v4.
  • Mô hình âm thanh dựa trên bộ nhớ ngắn hạn (LSTM) dành cho 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 bộ 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 tập 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 bài 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 nhiều hoặc trong các trường hợp phức tạp về hành vi của khách hàng.

Tất cả các thử nghiệm va chạm đều 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 quá trình kiểm tra, kiểm tra sẽ thất bại với lý do HANG và bộ kiểm tra sẽ chuyển sang kiểm tra tiếp theo.
  • Phát hiện sự cố máy khách NNAPI: Các thử nghiệm vẫn tồn tại sự cố máy khách và các thử nghiệm thất bại với lý do thất bại 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 cuộc gọi NNAPI. Lưu ý rằng có thể có sự cố trong quá trình trình điều khiển không gây ra lỗi NNAPI và không khiến quá trình kiểm tra 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 tăng tốc có sẵn: Các thử nghiệm được chạy dựa trên 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 : Thực thi hoàn tất không có lỗi.
  • FAILURE : Thực thi không thành công. Thường xảy ra do lỗi khi kiểm tra một mô hình, 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 kiểm tra không phản hồi.
  • CRASH : Quá trình kiểm tra bị lỗi.

Để biết thêm thông tin về kiểm tra sức chịu đựng và danh sách đầy đủ các kiểm tra sự cố, hãy xem platform/test/mlts/benchmark/README.txt .

Sử dụng MLTS

Để sử dụng MLTS:

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

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

Phiên bản HAL của mạng thần kinh

Phần này mô tả những thay đổi được giới thiệu trong 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 không dấu 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 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 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_V2QUANTIZED_16BIT_LSTM . Thao tác QUANTIZED_16BIT_LSTM không hỗ trợ toán hạng đã ký và bốn thao tác còn lại hỗ trợ lượng tử hóa đã ký nhưng không yêu cầu kết quả phải giống nhau.
  • Hỗ trợ 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 có rào chắn, không đồng bộ trên một mô hình đã chuẩn bị sẵn 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ợ điều khiển luồng. Thêm các phép toán IFWHILE , 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, hãy xem Kiểm soát luồng .
  • Chất lượng dịch vụ (QoS) được cải thiện vì các ứng dụng có thể cho biết mức độ ưu tiên tương đối của các mô hình của nó, 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 quá trình thực thi. Để biết thêm thông tin, xem Chất lượng dịch vụ .
  • Hỗ trợ các 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 truyền bộ nhớ gốc 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, hãy 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 kiểu dữ liệu bao gồm các kiểu dữ liệu vô hướng và thể hiện hiệu suất không được giải phóng bằng cách sử dụng vectơ thay vì các trường được đặt tên.
  • Các phương thức getVersionStringgetType 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à phân công thiết bị .
  • Phương thức executeSynchronously được gọi theo mặc định để thực hiện việ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 Thực thi .
  • Tham số MeasureTiming để executeSynchronously , 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 thi hay không. 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ợ các tiện ích mở rộng của nhà cung cấp, là tập hợp các hoạt động và kiểu dữ liệu do nhà cung cấp xác định. Trình điều khiển báo cáo các tiện ích mở rộng được hỗ trợ thông qua phương thức IDevice::getSupportedExtensions . Xem Tiện ích mở rộng của nhà cung cấp .
  • Khả năng đối tượng cụm kiểm soát một tập hợp thực thi cụm bằng cách sử dụng hàng đợi tin nhắn nhanh (FMQ) để liên lạc giữa các quy trình ứng dụng và trình điều khiển, 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 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ợ lưu vào bộ nhớ đệm của các tạo phẩm biên dịch để giảm thời gian sử dụng cho quá trình biên dịch khi ứng dụng khởi động. Xem Bộ đệm biên dịch .

Android 10 giới thiệu các loại toán hạng và thao tác sau.

  • 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ợ các tensor có thứ hạng khác 4 trong các hoạt động softmax và chuẩn hóa
  • Hỗ trợ cho các cuộn xoắn giãn nở
  • Hỗ trợ đầu vào có 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 chi tiết đầy đủ về các thay đổi, hãy xem OperationCode 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

Android 9

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 hoặc sẽ thực thi mô hình trong các cuộc gọi nhanh liên tiếp.
  • Chín thao tác 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 tính toán float 32 bit bằng cách sử dụng phạm vi float 16 bit và/hoặc độ chính xác bằng cách đặt Model.relaxComputationFloat32toFloat16 thành true . Cấu trúc Capabilities có trường bổ 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 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/ .