CPU、GPU、DSP以及硬體加速器——如何實現最佳化?

車用晶片商一直在探討為先進駕駛輔助系統(ADAS)設計的SoC。但其他人呢?包括記者、分析師,以及最重要的——汽車製造商,我們該如何區別當今的各種ADAS SoC性能有什麼不同?

事實是,我們做不到。由於缺少科學工具和基準測試,讓我們幾乎別無選擇,只能採信供應商的說法。或者,我們可以依靠諸如每秒兆次運算(TOPS)之類的不完美測量方法,來比較英特爾(Intel)/Mobileye的EyeQ5以及Nvidia的Xavier——這真的很愚蠢……

為此,開發嵌入式硬體基準的產業聯盟EEMBC日前推出了自動駕駛基準測試套件——‘ADASMark’,現已可用於授權。

據EEMBC表示,新的工具套件有助於一線供應商和汽車製造商在設計自家ADAS系統時,用於最佳化其利用來自CPU、GPU和硬體加速器的運算資源。

The Linley Group資深分析師Mike Demler看好ADASMark,他說:「這不僅僅是一個抽象的性能指標,而且還使用了真正的工作負載。」Demler並表示,得力於加拿大工程設計服務公司AU-Zone Technologies以及恩智浦半導體(NXP Semiconductors)和德州儀器(TI)等晶片供應商的參與,使得EEMBC的測試比百度(Baidu)的通用DeepBench更有意義。

「架構」(framework)至關重要

《EE Times》有機會採訪了EEMBC總裁兼技術長Peter Torelli,針對汽車製造商在設計高度自動化汽車時面臨的挑戰發表看法。

無疑地,越來越多的汽車嵌入式系統都部署了多個核心。然而,正如Torelli指出的,「能夠利用其非對稱運算資源的架構(framework)仍然很少。如果沒有架構,編譯基準測試的每個實例都會因為硬體不同而產生顯著差異,而且也很難進行跨平台比較。透過架構有助於移植,而只需很少的修改。」他說,看看ADASMark Pipeline (下圖)就知道了。

ADASMark Pipeline (來源:EEMBC)

Torelli說:「該系統的基準性能可能會在管線中的所有階段都使用相同的CPU。但是,如果開發人員想要在最後階段更換成自定義的神經網路晶片呢?或者,他們也許想用專有的DSP進行色彩空間轉換?」

這便是架構得以發揮之處。

「如果沒有架構,開發人員就必須在基準測試和運算裝置(NN、DSP或GPU)之間插入程式碼。這相當耗時、複雜且容易出錯,並且很容易破壞基準測試的目的(或破壞結果)。」Torelli解釋,透過架構則有助於讓運算裝置更易於重新定位。

EEMBC最初審查了當今市場上可用的選項。Torelli說:「AMP和OpenAMP試圖解決這個問題,但它們是對稱多核心的規範,無法在這方面真正提供協助。我們也看過OpenCV和OpenVX,但他們對於製造商的支援力度也不足。」

這就是EEMBC為什麼開發基於新架構的ADASMark之故。

專注於成像管線

根據EEMBC,ADASMark Benchmark Suite的主要特色「包括一個OpenCL 1.2 Embedded Profile API,用於確保運算作業之間的一致性;由一系列微基準測試打造的應用流程,用於測量和回報處理電腦視覺、自動駕駛和行動成像任務的SoC性能;以及由Au-Zone Technologies提供的交通號誌辨識CNN推理引擎。」

由於ADAS需要運算密集型物件偵測和視覺分類功能,因此,ADASMark的重點在於成像管線。EEMBC解釋,它使用了「代表高度平行應用的實際工作負載,例如環繞視圖拼接、輪廓檢測和卷積神經網絡(CNN)交通號誌分類等。」

ADASMark的工作原理

那麼,ADASMark如何運作?

據EEMBC解釋,ADASMark著眼於物件辨識,結合使用了「車輛周圍的可見光譜廣角相機,以及準備影像供受訓練的CNN進行分類的影像處理系統。此外,分類器的輸出提供了額外的決策邏輯,例如轉向和煞車系統。這種安排需要大量的運算能力。」

確定可用資源的限制且知道如何有效利用它們並不是件簡單的事。

為了因應這一挑戰,EEMBC解釋,ADASMark基準測試將「應用用例與合成測試組合結合到一連串的微基準測試中,用於測量和報告處理電腦視覺、自動駕駛和行動成像任務的SoC性能與延遲。」

ADASMark Experimental Benchmarks 不同類型平台的測試結果。以經過DAG圖的最長路徑決定得分。每項元素(Element)的執行時間和記憶體開銷都會影響總分。(來源:EEMBC)

誰的比分最高?

因此,從上表來看,Device C顯示了最佳性能。Torelli說,Device C是其於開發基準測試時使用的雲端AWS Nvidia系統。至於Device A和Device B呢?Torelli說說:「很遺憾的是我不能說出前兩種元件是什麼,因為他們還不打算在此時公佈得分。」

值得注意的是,ADASMark僅用於處理Level 2 ADAS的一部份。正如Demler所指出的,「這不是批評,但ADASMark並未解決自動駕駛所需的更高階功能。辨識交通號誌在各個層級都很重要,因此它既有用又必要,但要用於Level3到Level 5的汽車還不夠。」

此外,如同EEMBC所說,「基準時間並不包括視訊檔案的主執行緒處理,或者是與分割資料串流到DAG不同邊緣相關的開銷。」

在針對汽車應用的新一代AI加速器著眼於繪圖運算(或某些類型)之際,一旦未來基準測試開始將「視訊檔案的主執行緒處理」或「與分割資料串流相關的開銷」納入考慮,ADASMark的分數是否會有所不同?

Torelli說:「或許如此,但這不是這項基準測試要測量的指標。」 他解釋說,「此處存在一些權衡,因為在已部署的系統中,核心將會更緊密地整合。為了緩解這種差異,該管線的某些階段並未納入評分。儘管在同一平台上的後續OpenCL裝置交換核心所需的時間納入評分,但它通常比該階段的工作負載執行更小幾個數量級。我們還計算記憶體緩衝的copy-in/copy-out函數,因為這是異質運算的一個重要部份。」

「第22條軍規」——進退維谷之境…

Torelli告訴我們,在開發ADASMark時讓他最驚訝的是「與測試人員的合作、在SoC開發人員之間移植我們的基準測試,暴露了評估異質運算系統的複雜性,以及每一種新策略都需要開發團隊工作的大量努力。」

他補充說:「目前大多數開發人員都處於最少任務的環境中,這反過來阻礙了他們評估其他設計的機會。這就是所謂的「第22條軍規」(Catch-22):顯然每家供應商的客戶都要求最佳化他們自已的堆疊,但太多的限制卻讓開發人員沒什麼找到可能更佳解決方案的餘地。」

更重要的是,Torelli觀察到,「從硬體的角度來看,在此節骨眼很難判斷好壞:運算需求每個月都會隨著機器學習的新學術研究進展而變化。」處理器產業通常跟不上學術研究的腳步,他說,「但是當今的機器學習/深度學習情況並非如此。所以,工程界的反應還不夠快。」

ADAS SoC對車輛安全的影響

《EE Times》最近在「不同車輛ADAS性能為何參差不齊?」一文中,報導了美國公路安全保險協會(IIHS)針對配備ADAS的車輛安全性能進行的評估測試結果。

20180904NT31P1 *IIHS檢視道路測試和試車場的駕駛輔助功能,並分享其測試結果*

ADAS SoC的性能與ADAS車輛的安全性能之間是否存在任何相關性?我們詢問Torelli個別ADAS晶片對於當今ADAS車輛性能的變化具有多大的影響力。

Torelli引用我們文中提到VSI Labs創辦人兼負責人Phil Magney的一句話:「由於硬體/軟體配置等多方面的因素,這些系統會出現許多性能差異。」Torelli認為,「這種說法過於保守!」

「在我們的案例中,基準測試並未擷取系統在視覺管線之上的響應時間,例如決策邏輯。」他指出,「除了輪廓檢測外,ADASMark的每一級管線都具有與輸入成正比的確定性執行時間。我認為決策邏輯和實體系統的響應時間都是問題所在。」

針對IIHS的測試結果,Torelli說,「它似乎與決策系統本身受演算法(而非硬體)的支配有關;實體響應系統(煞車、轉向等)則有各自不同的環境變量。」

他總結說,ADASmark是「一款有用的分析工具,可用於比較非對稱硬體的運算行為(很大程度上是確定性的)——這些硬體本身就是我們試圖解決的複雜任務。」

同時,針對ADAS SoC性能對於ADAS車輛安全的影響,Linley Group的Demler指出,IIHS的研究報告也進行了一連串的L2測試。

但他補充說,很難只指出一種硬體可能導致這種變化。「一開始,我會先看感測器和感測器處理軟體,然後再著眼到像某些汽車中使用的EyeQ3或DrivePX等處理器。」

基準感測器融合?

EEMBC目前的ADASMark專注於視覺。那麼,針對整合來自雷達、光達等感測器資料的SoC感測器融合,EEMBC打算如何進行基準測試?

Torelli說,「雷達和光達仍然是視覺(或類似視覺)管線。我不打算深入探索這些領域,因為我目前還沒有看到太多性能指標的變化。」但是,他補充說,「感測器融合和決策邏輯絕對是一個令人感興趣的領域,但我認為它跨越了一個不同的機器學習領域。至於我們的ADAS或機器學習團隊是否涵蓋這部份,目前還有待觀察。」

編譯:Susan Hong

(參考原文:ADAS SoC: Show Me Your Benchmark,by Junko Yoshida)