為何圖像和FPGA更配？揭秘背后的技術(shù)要素

　　背景

　　“No PP，No WAY”這是個眼見為實(shí)的世界，這是個視覺構(gòu)成的信息洪流的世界。大腦處理視覺內(nèi)容的速度比文字內(nèi)容快6萬倍，而隨著智能手機(jī)的普及，圖片、視頻的產(chǎn)生和分享已經(jīng)是人們在社交平臺上的基本交流方式。用戶通過手機(jī)、平板、電腦上傳和分享自己的圖片，而且這個趨勢是每年都在增長(參見圖1)。

　　圖1. 2016年KPCB統(tǒng)計(jì)報(bào)告[1]

　　每天QQ相冊、微信朋友圈上，用戶上傳的圖片數(shù)量有上億張，這些圖片被后臺服務(wù)器存儲下來，再通過網(wǎng)絡(luò)分發(fā)出去。如果每張圖片可以進(jìn)行壓縮，使得圖片存儲和傳輸分發(fā)的數(shù)據(jù)量越少，既節(jié)省了用戶帶寬，也提高了用戶下載圖片的速度，用戶體驗(yàn)更好。那么圖片是可以進(jìn)行壓縮的么?1948年，信息論學(xué)說的奠基人香農(nóng)曾經(jīng)論證：不論是語音或者圖片，由于其信號中包含很多的冗余信息，所以可以對其進(jìn)行壓縮。圖像壓縮算法有：JPEG、WEBP、H264(幀內(nèi)壓縮)、HEVC(幀內(nèi)壓縮)，壓縮能力是：JPEG < WEBP/H264(幀內(nèi)壓縮) < HEVC(幀內(nèi)壓縮)， 這個壓縮能力是通過計(jì)算復(fù)雜度的提高來實(shí)現(xiàn)，其中WEBP、HEVC的計(jì)算復(fù)雜度是 JPEG 壓縮的 10 倍以上。 目前在社交平臺上用戶上傳的大量圖片是JPEG格式，通過后臺服務(wù)器用更加復(fù)雜的算法如WEBP、HEVC(幀內(nèi)壓縮)，進(jìn)一步壓縮以節(jié)省存儲和帶寬， 所以對圖像的壓縮，從本質(zhì)上是通過提高計(jì)算算力來降低存儲和帶寬。同時更加復(fù)雜的算法也帶來計(jì)算算力的大量消耗和處理延時的增加。

　　從業(yè)務(wù)角度來看，對于離線業(yè)務(wù)，可以通過業(yè)務(wù)在波峰和波谷之間閑置的計(jì)算算力進(jìn)行圖片轉(zhuǎn)碼處理;但對于在線業(yè)務(wù)，圖片轉(zhuǎn)碼處理對于處理延時的要求就會有較高要求，為了滿足處理延時的要求，有時候會先進(jìn)行圖片轉(zhuǎn)碼處理，把轉(zhuǎn)碼好的圖片存儲下來，當(dāng)用戶需要的時候直接傳輸，這樣通過消耗存儲資源為代價來解決處理延時的要求。但是這又帶來一個新問題，用戶查看圖片的智能終端屏幕大小不一，如果都傳同樣大小的圖片，顯然不是最優(yōu)。最優(yōu)處理方法還是能夠通過計(jì)算算力，實(shí)時進(jìn)行圖片轉(zhuǎn)碼處理。

　　在數(shù)據(jù)中心里面，計(jì)算算力通常由x86 CPU來提供，以前的x86 CPU性能每18個月就能翻倍(眾所周知的“摩爾定律”)，但目前工業(yè)界的發(fā)展方向是摩爾定律已經(jīng)走到終點(diǎn)。例如，2016年3月24日，英特爾宣布正式停用“工藝年-架構(gòu)年(Tick-Tock)”處理器研發(fā)模式，未來研發(fā)周期將從兩年周期向三年期轉(zhuǎn)變。而國際半導(dǎo)體技術(shù)發(fā)展路線圖(International Technology Roadmap for Semiconductors，簡寫 ITRS)在維持了數(shù)十年，每兩年更新一次，為全世界半導(dǎo)體行業(yè)提供建議和規(guī)劃指南，也在2016年宣布不再做進(jìn)一步的更新。

　　一方面處理器性能再無法按照摩爾定律進(jìn)行增長，另一方面數(shù)據(jù)增長對計(jì)算性能要求超過了按“摩爾定律”增長的速度。處理器本身無法滿足高性能計(jì)算(HPC：High Performance Compute)應(yīng)用軟件的性能需求，導(dǎo)致需求和性能之間出現(xiàn)了缺口(參見圖2)。

　　圖 2. 計(jì)算需求和計(jì)算能力的缺口發(fā)展形式

　　圖像處理解決方案

　　圖片服務(wù)支持的能力豐富多樣，基礎(chǔ)功能包括多種縮略剪裁方式、文字圖片水印、格式轉(zhuǎn)換、斷點(diǎn)續(xù)傳、鏡像存儲、防盜鏈等。我們結(jié)合當(dāng)前圖文時代的用戶需求，提供圖片的上傳、存儲、處理、分發(fā)的全方位一體化的解決方案。目前，互聯(lián)網(wǎng)圖片服務(wù)的解決方案中落地存儲和下載大部分圖片格式還是JPEG/WEBP，但隨著新的編碼標(biāo)準(zhǔn)HEVC的出現(xiàn)，在同等圖像質(zhì)量下，HEVC的壓縮效率會比JPEG/WEBP好30%~70%，可以節(jié)省大量的存儲和帶寬，但是HEVC的算法復(fù)雜度高導(dǎo)致CPU的編碼延遲和吞吐在線上環(huán)境中無法滿足，因此，我們開發(fā)了基于FPGA的新的解決方案。FPGA圖像處理方案可以很好的解決線上環(huán)境的需求，當(dāng)然，FPGA圖像處理解決方案也兼容當(dāng)前用戶線上系統(tǒng)的WEBP等其他圖像轉(zhuǎn)碼格式，可以很好的適應(yīng)不同用戶的需求，提供低延遲，高吞吐，低成本的解決方案。

　　我們以HEVC FPGA 圖像處理為例，來說明在互聯(lián)網(wǎng)業(yè)務(wù)中圖片上傳，存儲，處理和下載的架構(gòu)。

　　圖3. HEVC FPGA 圖片上傳存儲，處理，下載解決方案

　　如圖3所示，圖片HEVC FPGA轉(zhuǎn)碼的部署主要是落地存儲前以及下載前的轉(zhuǎn)碼服務(wù)器，使用FPGA做轉(zhuǎn)碼主要有以下優(yōu)勢：

　　FPGA轉(zhuǎn)碼落地存儲HEVC，可有效節(jié)省存儲成本。

　　1. FPGA轉(zhuǎn)碼服務(wù)器和CPU轉(zhuǎn)碼相比可以降低服務(wù)器成本。

　　FPGA轉(zhuǎn)碼HEVC圖片和CPU相比吞吐量可以大大提高。

　　在下載時實(shí)時生成HEVC圖片，使用FPGA進(jìn)行圖片轉(zhuǎn)碼加速，會大大降低轉(zhuǎn)碼延遲，提高用戶體驗(yàn)。

　　圖像編碼算法分析

　　在圖像和視頻編解碼算法中，各個模塊都是基于像素級運(yùn)算或者基于塊操作，而且針對各個像素或者圖像塊的操作是相同和重復(fù)的。早期的圖片壓縮標(biāo)準(zhǔn)JPEG和JPEG200，原始圖像首先經(jīng)過基于塊的DCT變換或者小波變換，變換后的系數(shù)經(jīng)過量化后再進(jìn)行熵編碼(包括Huffman編碼或者自適應(yīng)算術(shù)編碼)，進(jìn)而輸出壓縮后的碼流信息。在解碼端，通過反向操作，可將碼流信息進(jìn)行解碼。在JPEG2000中，DCT變換被小波變換替代，可以更好的消除圖像塊內(nèi)的冗余性，而且量化后的系統(tǒng)按照比特位平面進(jìn)行自適應(yīng)算術(shù)編碼，可以達(dá)到更好的壓縮性能。

　　除了JPEG這類對原始圖像直接變換的方法，還有一種是基于塊預(yù)測的方法。也就是對一個圖像塊先進(jìn)行預(yù)測，原始圖像塊和預(yù)測塊的殘差再進(jìn)行變換，量化和編碼。比較典型標(biāo)準(zhǔn)就是從H.264的幀內(nèi)預(yù)測發(fā)展而來的WebP。隨著新一代視頻編碼標(biāo)準(zhǔn)HEVC/H.265的推出，其幀內(nèi)編碼的壓縮性能，較上一代標(biāo)準(zhǔn)提升接近一倍[2]。因此，將HEVC的幀內(nèi)編碼用于圖像壓縮也成為一種趨勢。HEVC的幀內(nèi)編碼過程如圖4所示。

　　圖4. HEVC幀內(nèi)編碼的過程

　　在HEVC中，塊劃分的方式是基于非完全四叉樹結(jié)構(gòu)，這更適用于不同的圖像場景。每一個最終確定大小的塊只需要一個獨(dú)立的預(yù)測模式。圖5是HEVC圖片編碼中塊劃分和預(yù)測模式的一個例子?？梢钥闯霎?dāng)一個塊可以通過單獨(dú)的某一個角度進(jìn)行預(yù)測的時候，則不需要劃分為更小的塊。而場景信息較為復(fù)雜區(qū)域則需要劃分為較小的塊。編碼器的一項(xiàng)重要任務(wù)，就是尋找最佳的塊劃分方式和最優(yōu)的預(yù)測角度。

　　圖5. HEVC圖片編碼塊劃分及預(yù)測模式

　　圖6(a) 就是根據(jù)最終的塊劃分方式和預(yù)測模式得到的預(yù)測圖片。預(yù)測圖片和原始圖片的差值(殘差)通過DCT變換，量化之后，最終通過熵編碼器輸出。圖片預(yù)測的殘差如圖6(b)所示。在解碼器中，根據(jù)得到的殘差數(shù)據(jù)，并進(jìn)行和編碼器相同的預(yù)測，可以得到最終的重構(gòu)圖片，圖6(c)所示的就是重構(gòu)數(shù)據(jù)。由于編碼過程需要用到重構(gòu)數(shù)據(jù)作為參考數(shù)據(jù)，因此在編碼器也需要進(jìn)行重構(gòu)的過程。原始圖片如圖6(d)所示，可以看出，重構(gòu)的圖片和原始圖片損失非常小。

　　圖6. HEVC圖片編碼過程中的預(yù)測，殘差，重構(gòu)以及原始數(shù)據(jù)

　　在HEVC的幀內(nèi)編碼中，由于要進(jìn)行最佳編碼模式的搜索，造成編碼器的計(jì)算復(fù)雜度高。傳統(tǒng)的CPU無法達(dá)到理想的吞吐量?，F(xiàn)在的GPU雖然也大量應(yīng)用的圖片和視頻領(lǐng)域，然而GPU的并行化更適用的是各個像素點(diǎn)進(jìn)行相同操作，完成之后再進(jìn)行下一步的并行化操作。這并不利于HEVC圖片編碼各個模塊控制較為復(fù)雜的情況。在Nvidia的GPU中，圖片和視頻編解碼也采用的專用的芯片來處理。 而FPGA可以實(shí)現(xiàn)各個不同的模塊的流水化運(yùn)算，實(shí)現(xiàn)時間上的并行。 同時，由于只是進(jìn)行幀內(nèi)編碼，不同圖像之間是相互獨(dú)立的，在FPGA中也可以設(shè)計(jì)多路的編碼器，對不同的圖片進(jìn)行并行的編碼壓縮。

　　當(dāng)然，對于基于塊預(yù)測的圖像編碼方法，也存在一些限制FPGA并行化實(shí)現(xiàn)因素。但是，這些受到限制的部分，也可以通過FPGA設(shè)計(jì)的特點(diǎn)來解決。例如，如圖4所示，幀內(nèi)預(yù)測的參考點(diǎn)需要通過重構(gòu)的方法得到，這就增加了不同塊之間的依賴性，限制了塊之間的并行化，和流水化設(shè)計(jì)。在實(shí)際的FPGA設(shè)計(jì)中，可以在進(jìn)行預(yù)測模式初選時，用原始數(shù)據(jù)替代重構(gòu)數(shù)據(jù)作為參考，而在最終編碼時用重構(gòu)數(shù)據(jù)在作為參考數(shù)據(jù)[3]。在FPGA的實(shí)現(xiàn)過程中，也可以更改掃描順序，優(yōu)先處理那些有依賴關(guān)系的像素點(diǎn)。此外，在自適應(yīng)熵編碼部分，由于存在更新碼表和更新概率估計(jì)的過程，部分比特?cái)?shù)據(jù)進(jìn)行熵編碼時，也存在依賴關(guān)系。 在實(shí)際的FPGA設(shè)計(jì)過程中，可以通過將這些需要進(jìn)行編碼的數(shù)據(jù)進(jìn)行分組，將沒有依賴關(guān)系的數(shù)據(jù)分為一組，同時，通過數(shù)據(jù)緩存，可以預(yù)先判斷接下來的數(shù)據(jù)是否存在依賴關(guān)系，從而提高熵編碼的吞吐量[4]。

　　HEVC圖像編碼算法的FPGA實(shí)現(xiàn)

　　FPGA圖像編碼架構(gòu)

　　目前，我們圖片業(yè)務(wù)已經(jīng)實(shí)現(xiàn)WEBP和HEVC格式的FPGA硬件加速，下面以HEVC I幀圖像硬件加速舉例，說明圖像編碼在FPGA中是如何實(shí)現(xiàn)的。

　　FPGA的邏輯架構(gòu)主要包括平臺部分和HEVC編碼器IP部分，其中FPGA平臺主要包括PCIE DMA以及DDR總線相關(guān)邏輯，這部分邏輯主要實(shí)現(xiàn)和host CPU的數(shù)據(jù)通信以及和FPGA板卡上的DDR通信。如圖7所示，F(xiàn)PGA架構(gòu)上實(shí)例化了4個HEVC core(具體幾個是和FPGA資源有關(guān))，每一個HEVC core完成HEVC編碼算法的完整處理，這里4核心并行工作，也就是同一時刻，4個編碼任務(wù)可以并行工作，同時輸出4條HEVC碼流。

　　圖7. FPGA內(nèi)部邏輯架構(gòu)

　　FPGA內(nèi)部邏輯主要包括：

　　HEVC CORE 0-3:H265編碼器IP，實(shí)現(xiàn)HEVC的編碼算法;

　　PCIE/DMA:實(shí)現(xiàn)和host CPU進(jìn)行通信;

　　REGISTER RW/INT:寄存器讀寫以及中斷處理;

　　HEVC RW ARBITER:總線讀寫仲裁模塊;

　　AXI INTERCONNECT/DDRC/DDRY: 總線控制訪問DDR邏輯;

　　FPGA圖像編碼流程

　　FPGA HEVC core內(nèi)部算法處理流程如圖8所示：分為當(dāng)前圖像載入，intra預(yù)測初選，intra預(yù)測精選，CABAC編碼，碼流輸出。

　　圖8. HEVC core內(nèi)部算法處理流程

　　那么如何設(shè)計(jì)HEVC core實(shí)現(xiàn)算法功能呢?這里，編碼器模塊流水線設(shè)計(jì)成四級流水，如圖9所示，四級流水CURLD/PINTRA/SEL/CABAC處理性能設(shè)計(jì)接近，并行起來后，平均處理每個LCU需要8400個周期，如果按照1080p圖片一共510個LCU計(jì)算，單核理論上編碼可以達(dá)到編46 幀/s (FPGA電路實(shí)現(xiàn)頻率200M)，這樣4核并行能達(dá)到184幀/s。

　　具體來說，CURLD完成當(dāng)前圖像的載入邏輯，PINTRA完成intra預(yù)測初選35種模式的遍歷，得到最優(yōu)的預(yù)測模式，這級流水算法上做了優(yōu)化，預(yù)測參考像素沒有像傳統(tǒng)方式選擇重構(gòu)像素，而是選擇當(dāng)前像素做參考像素，這樣優(yōu)化，使得intra預(yù)測初選可以單獨(dú)劃分為一級流水，和intra預(yù)測精選分開，使得編碼器整體處理性能增加一倍。SEL完成幀內(nèi)預(yù)測模式精選以及RDO模式選擇，預(yù)測塊大小支持32/16/8，由于涉及到變換量化等運(yùn)算量大的邏輯，這一級流水是整個編碼器的資源消耗大戶，設(shè)計(jì)上在算法上以及邏輯資源消耗上做了權(quán)衡;CABAC模塊完成頭信息的碼流生成以及每個LCU的語法元素和殘差的編碼，并完成碼流的打包輸出，這一級流水的主要問題在于CABAC的性能是否足夠快，從而應(yīng)對QP比較小編碼更多bin的處理及時。

　　圖9. 運(yùn)算模塊流水線

　　性能和收益

　　用FPGA完成JPEG格式圖片轉(zhuǎn)成HEVC格式圖片，圖片分辨率大小為1920x1080，F(xiàn)PGA處理延時相比CPU降低7倍，F(xiàn)PGA處理性能是CPU機(jī)器的10倍，F(xiàn)PGA機(jī)型單位性能成本是CPU機(jī)型的1/3(參見圖10)。

　　圖10.圖片轉(zhuǎn)碼FPGA和CPU對比

　　總之，圖片算法的FPGA實(shí)現(xiàn)，如果不考慮FPGA資源、硬件實(shí)現(xiàn)架構(gòu)和處理性能，CPU圖像壓縮算法可以完全在FPGA進(jìn)行“復(fù)制”實(shí)現(xiàn)，F(xiàn)PGA算法壓縮性能可以完全等同CPU。但是現(xiàn)實(shí)沒那么理想，F(xiàn)PGA算法實(shí)現(xiàn)要統(tǒng)一考慮FPGA性能，資源，算法實(shí)現(xiàn)復(fù)雜度等要素，只有聯(lián)合設(shè)計(jì)才能設(shè)計(jì)出最優(yōu)秀的方案，為了發(fā)揮FPGA硬件實(shí)現(xiàn)的速度優(yōu)勢，算法進(jìn)行優(yōu)化是必須要做的，綜合考慮各方面，我們在實(shí)際應(yīng)用中，往往FPGA的算法實(shí)現(xiàn)要做一些“讓步”。另外，某種型號的FPGA一旦被選定，它的運(yùn)算以及布線資源往往有個理論值，算法的實(shí)現(xiàn)同時要考慮FPGA資源的利用情況，如何能在相同的FPGA資源上實(shí)現(xiàn)最好的壓縮算法成為設(shè)計(jì)的難點(diǎn)。我們用FPGA進(jìn)行算法實(shí)現(xiàn)的目標(biāo)-----實(shí)現(xiàn)算法性能盡量接近CPU，圖片處理吞吐量，以及處理延遲讓CPU望其項(xiàng)背。

　　參考文獻(xiàn)：

　　[1]. KPCB：瑪麗·米克爾“互聯(lián)網(wǎng)女皇”-2016年互聯(lián)網(wǎng)趨勢報(bào)告

　　[2]. G. J. Sullivan, J. R. Ohm, W. J. Han and T. Wiegand, "Overview of the High Efficiency Video Coding (HEVC) Standard," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 22, no. 12, pp. 1649-1668, Dec. 2012.

　　[3].G. Pastuszak and A. Abramowski, "Algorithm and Architecture Design of the H.265/HEVC Intra Encoder," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 26, no. 1, pp. 210-222, Jan. 2016.

　　[4].D. Zhou, J. Zhou, W. Fei and S. Goto, "Ultra-High-Throughput VLSI Architecture of H.265/HEVC CABAC Encoder for UHDTV Applications," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 25, no. 3, pp. 497-507, March 2015.