240 likes | 364 Views
2012/12/05. 嵌入式視頻處理的硬體任務排程器 A Hw task scheduler for embedded video processing. 指導教授 :周 哲 民 學 生 :陳 佑 銓 CAD Group Department of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C. 大綱. 介紹 硬體任務排程器 評估框架 實驗結果 結論. 介紹 (1/3).
E N D
2012/12/05 嵌入式視頻處理的硬體任務排程器A Hwtask scheduler for embedded video processing 指導教授 :周 哲 民 學 生 :陳 佑 銓 CAD Group Department of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C
大綱 • 介紹 • 硬體任務排程器 • 評估框架 • 實驗結果 • 結論
介紹(1/3) • 現代嵌入式應用,在相同面積中需要具有更高的效能。 • 為了提高效能,嵌入式晶片通常分散在多核心架構的特定區域。 • 在許多情況下,嵌入式多核心晶片的每個核心上運行一個相對獨立的應用程式(如音訊,視頻,3D圖形),只需要與其他核心進行少量的同步與通信。 • 然而,如果一個應用程式,超出了一個獨立核心的計算能力,應用程式可能會被切分成數個任務,並運行於多個核心上. • 在數個內核上運行一個應用程式,必須進行任務的創建、即時排程、映射到正確的核心以及同步化。 • 任務排程與核心映射 • 在編譯時完成稱為靜態完成; • 在運行時完成稱為動態完成。
介紹(2/3) • 我們的論文的主要的重點是嵌入式視頻應用(例如:H.264視訊壓縮),具有可變的執行時間和任務間的相依關係。 • 圖1左顯示出了一個5x5從H.264視頻解碼器的每個巨集塊(marcoblock)的視頻frame,會與兩個巨集塊有相依的關係。這樣的相依關係,在所有的巨集塊中重複地出現,如此稱之重複的相依型樣(pattern). • 由此型樣我們可以構建完整的任務關係圖,如圖.1右所示 圖1(左)H.264的相依型樣 圖1(右)對應的任務圖
介紹(3/3) • 我們的論文貢獻包括以下三點: • 一種重複的相依型樣的識別,來作為有效加速硬體式任務管理的基礎 • 硬體任務排程器Hardware Task Scheduler(HTS)的結構,能夠作細粒度任務的創建、排程、映射和同步; • 即時執行H.264視頻解碼,根據小HTS減少所需的核心的數量來評估多核心效能密度增益。
硬體任務排程器(1/12) • 硬體任務排程器Hardware Task Scheduler(HTS)的主要目的是加速在硬體中的任務管理。 • 平行程式根據相依型樣和迴圈邊界來初始化HTS,根據這兩樣,我們可以創建一個任務的相依圖。 • 當HTS準備在核心上執行可用的任務,同時也逐步地去建立任務圖。 • 當一個任務完成時,核心會不斷去要求新任務,並且通知HTS。 • 當任務圖執行完畢,HTS會發送信號到所有核心。 • 奴隸(slave)核心會從HTS中將任務拉出來,如果任務數超過可用的處理器核心數目,核心將會循序執行多個任務。 • 對於具有數個HTSs的大型系統,每個HTS可以利用他的主介面從另一個HTS竊取工作(steal jobs)。 • HTS與核心進行溝通的API實現在Memory Mapped Input/Output(MMIO)之上的讀取和寫入,因此,他們不需要進行ISA的擴展和編譯器的修改。
硬體任務排程器(2/12) 圖.2:SoC由幾個同質化的核心、共用記憶體和連接到每個核心的HTS所組成
硬體任務排程器(3/12) 3.1程式設計模型(Programming Model) • 映射一個應用程式(如H.264影像解碼)到一個具有HTS的多核心系統需要三個步驟: • 平行內核的隔離 • 在第一步驟中,程式者標識出應用於不同陣列元素的內核 • 重複的任務間相依型樣的識別 • 我們檢查在圖3的內核函數,發現每個圖像的macroblock(X,Y)的值取決於macroblock(x-1,y)和macroblock(x +1,y-1)這兩個macroblock的值。 圖3:循序內核Process_MB()程式
硬體任務排程器(4/12) • HTS初始化和開始 • 移除巢狀迴圈(nested loop),改由HTS初始化代碼取而代之。 • HTS的初始化代碼包括HTS所通過的相依型樣(DependencyX和DependencyY)、函數指標(wrapper_p),迴路索引(loop indices)(ImageHeight和ImageWidth)。 • 在我們的例子中,陣列中的DependencyX和DependencyY將分別包含(-1,+1)和(0,-1)的值。核心函數會在一個特殊介面的HTS函數(wrapper_p)中準備好,這HTS函數會從HTS中要求可用的任務,並開始執行核心在HTS所獲得的獨立變數。TaskSchdulerInitALL()函數也將啟動HTS。
硬體任務排程器(5/12) • 介面程式在第5行讀取HTS狀態,如果有一個準備好的任務,我們將啟動剛剛讀出X和Y參數的內核。 • 如果HTS狀態為:任務圖已經完成(line 11),如此介面程式將會跳出。 • 存取到HTS的hts_read(),hts_write()指令均為MMIO的載入和存儲。 圖.5:介面程式的結構
硬體任務排程器(6/12) • 最初,多核心系統的引導裝載(boot loader)程式觸發奴隸核心去載入slave程式。然後,此slave程式要求一個函數指標,在每次HTS開始時去平行化內核。 圖.6:The slave program
硬體任務排程器(7/12) 3.2架構 圖.7HTS的結構
硬體任務排程器(8/12) • slave0 to slaveN:slave埠連接到所有的核心和其他作用與核心類似的外部HTS。 • Master Port:允許從其他的HTS中竊取任務。 • Control Unit:編排整體HTS操作。 • Floating Ready Task FIFO:保存執行的任務 ready訊號,但不分配給slave埠。 • Slave Ready Task FIFOs:包含執行的任務 ready訊號且分配給slave埠。 • Slave Candidate Buffers:在一項持續的任務中存儲任務的候選者。 • Synchronization Buff :在最後完成的任務中存儲任務的候選者。 • Repetitive Dependency Pattern Buffer:保存重複相依型樣中X和Y的相對坐標。
硬體任務排程器(9/12) • 典型的HTS操作順序 • 主核心執行應用程式的循序部分和遇到平行段HTS程式。 • 主核心寫入內核的函數指標,重複的相依型樣和任務圖的邊界到HTS。 • 該Control Unit把相依模式儲存於Repetitive Dependency Pattern Buffer,並提交第一個任務到Slave Ready Task FIFOs。 • 同時,Control Unit計算所有可能的候選者,這些候選者可以開始執行任務,一旦第一個任務完成時,並將它們儲存到適當的 Slave Candidate Buffers。 • 候選者可以由相依型樣逆推而來。 • 例如,相對於正在執行的任務(x,y),的相依關係為(-1,+2),將會產生任務候選者(X +1,Y-2)。 • 當任務位於的任務圖的邊界上可能會產生一或零個的候選者。因此,由圖.3的相依型樣,一個新的任務將可以產生2個候選者,此候選者依然將會有兩個相依任務。
Hardware Task Scheduler(10/12) • 當一個Slave介面發送出父(parent)任務已執行完成的訊號時,Control Unit試圖把對應的Slave Candidate Buffer的候選者任務,提升到一個Slave Ready Task FIFO。該控制單元在每週期讀取一個候選者和檢查以下兩個條件: • 1.如果所有的候選者的父(parent)任務已經完成; • 2.如果沒有提升其他重複的候選者任務。 • 這兩個檢查取決於Synchronization Buffer中所得到的任務狀態。 • 在剛開始,所有任務都是UNPROCESSED。 • 當一個任務被提升到Slave Ready Task FIFO時,其狀態更改為“PENDING”。 • 當任務完成後,其狀態變為FINISHED。 • 如果我們的候選者的父狀態是FINISHED,則第一個檢查通過。 • 如果我們的候選者的狀態是UNPROCESSED,則第二個檢查為true。 • 如果兩個檢查均通過,然後候選者移動到Slave Ready Task FIFO,並更新其Synchronization的狀態。
硬體任務排程器(11/12) • 利用圖.7中的full cross-bar,Control Unit可以映射候選者任務到任意的Slave Ready FIFOs。 • HTS的任務到核心的映射方法是基於文獻中[12]的Tail Submit principle。 • Tail Submit 提高了資料的快取局部性,藉由子任務映射到父(parent)核心,在這個映射的過程,資料快取中可能已經包含了一些子任務所需的資料。 • 如果有多個子任務是準備在父任務完成之後才執行,我們把相同Y軸的任務,映射到父核心,和其他的子任務到Floating Ready Task FIFO。 • 如果專用的Slave Task FIFO為空,任何閒置的處理器可以從floating FIFO中接受一個任務。
硬體任務排程器(12/12) • 表1顯示各種不同配置HTS的面積和功率,使用CMOS 45 nm worst-case TSMC library在Register Transfer Level(RTL)合成的HTS.。在一般情況下,HTS的面積和功率均比TriMedia TM3270核心[21]還少5%。 3.3實施
評估框架 • 我們在TTIsim模擬器中來塑造一個HTS • 每個核心擁有64 KB資料快取耦合到其他內核的快取和通過MESI快取一致性協定來共享記憶體。 • 我們分別評估了H.264視頻解碼的HTS效能,在Quad HD(QHD)3840x2160、Full HD(FHD)1920×1080這兩個序列中。 • 我們在每個序列中模擬了25 frames。 • 對照組為使用CARBON[14]的硬體Task Scheduling Unit(TSU)與使用Task Pool(TP)的軟體模型,並比較有無施加Tail Submit的差異。 • Tail Submit的優化,可減少任務創建的開銷
圖8和圖9顯示出在不同核心數量對H.264解碼FHD輸入流的增速圖8和圖9顯示出在不同核心數量對H.264解碼FHD輸入流的增速
圖10和圖11顯示出在不同核心數量對H.264解碼FHD輸入流的增速圖10和圖11顯示出在不同核心數量對H.264解碼FHD輸入流的增速
實驗結果(3/4) • 圖8和圖10是實驗在MESI快取一致性記憶體 • M(Modified)E(Exclusive)S(Shared)I(Invalid) • 圖9和圖11是實驗在理想化的記憶體 • 並比較TP與TSU有無使用Tail Submit 的差異, • 圖8中可發現有使用Tail Submit優化的TP與TSU,效能約提升了26%與14% • 但不論有無Tail Submit優化,HTS仍然具有比較好的效能增速 • 在MESI中約快了1.17倍 • 在理想化的記憶體中約快了1.05倍
實驗結果(4/4) • 如圖.12所示,在滿足即時的H.264FHD與QHD影像解碼 • HTS在FHD需要3個核心,而QHD需要14個核心 • 使用TailSubmit優化的TSU在FHD需要4個核心,而QHD需要16個核心
結論 • HTS可以快速地對任務進行創建、即時排程、同步化和映射到核心。 • 不同於軟體需要數百週期用於任務排程,HTS只需15個週期來排程和同步。 • 在一般情況下,在HTS優化一個16核心平行Quad HD H.264視頻解碼處理器,比與用軟體實現任務排程和同步的方式速度增速了1.173倍。此外,由於完全的加速任務間的同步,HTS優於使用CARBON硬體任務佇列,增速達1.169倍。 • 硬體任務排程程式允許減少所需的核心的數量,如此可減少矽面積達12.5%。