2018年7月24日 星期二

系統性動態電壓頻率調變。

近幾年的一項調查顯示,只有約四分之一的晶片設計者會考慮利用硬體層的資訊來進行動態電壓頻率調變(DVFS),其餘晶片設計者對硬體的動態電壓頻率調變操作,仰賴於軟體層或驅動程式的判斷。

例如Android提供了CPU的軟體監控模組,可以根據當下實際執行的應用程式的運算量和負載量,選擇CPU所需的最佳操作頻率和電壓。GPU存在相同狀況,事實上大多數包含處理器的子系統或硬體模組都已經採用了類似的動態電壓頻率調變機制。

因此與軟體層無關的晶片設計者選擇將重心放在把硬體設計得更具彈性,提供更精密、更多種的動態電壓頻率調變。換言之,單就從硬體層的控制角度來看,過去幾年幾乎可以說動態電壓頻率調變已死。


然而晶片設計者儘管實現了更具彈性的動態電壓頻率調變和不同程度的低功耗模式之類的機制,卻開始出現軟體無法對功耗更進一步最佳化的情況。

無論是為了功耗最佳化還是延長續航的使用需求,許多動態電壓頻率調變機制當前的問題是,大多數的軟體調控都只考慮到單一硬體或局部子系統的最佳化。專注於降低自身功耗,而不是改善整體系統效能。更糟糕的是,軟體調控幾乎各自獨立,常常發生彼此相互抵銷對方的功耗收益,致使事倍功半。

複雜度可說是由軟體進行系統性分析的最大阻礙,偏偏科技發展愈成熟,產品能支援的功能愈完善,需要功耗最佳化的硬體越來越多,軟體相對就更難以找到系統性的解決方案。

局部最佳化無疑不能和系統性最佳化直接畫上等號,像是想對CPU進行功耗改善時,不該只考慮到CPU自身的動態電壓頻率調變。縱使讓CPU執行再簡單的應用程式,起碼連動了cacheBUSmemory等相關硬體。只專注於CPU的調整而不改善整個系統,效果十分有限。

要突破如此困境倒也不甚難,說穿了只是需要一個新的概念:系統性動態電壓頻率調變。而此機制很可能要回到硬體層來實現,或至少也要硬體層的加速支援。

因為想得到一個系統性功耗最佳化方案,需要對每個硬體的行為特性都要有一定了解,同時也要能夠快速整合多個硬體模組的操作資訊,以及不同子系統之間的交互影響瞭若指掌,以作出滿足全系統最佳化的判斷。若再加上製程偏移和溫度變化等功耗影響因素,想在軟體層運行極複雜的評估顯然是不切實際的期待,勢必需要硬體的介入。

動態電壓頻率調變盡交由軟體或驅動程式的想法既過時且效果欠佳,取而代之的是透過驅動程式將諸多硬體模組的操作資訊收集到中央控制系統,由其仲裁或決策,在滿足所有硬體的系統層需求下進行功耗最佳化。

這種系統性動態電壓頻率調變的仲裁和控制範圍擴展到全系統下絕大部分的硬體,故能對全系統產生更大的影響。甚至會有想對甲硬體作功耗改善,其實對乙硬體進行動態電壓頻率調變將更有效果的現象出現。

有一點值得注意,我在前兩段額外提到了「系統層需求」這個名詞,單一硬體通常僅能考慮到自身與全系統間的單方面關係,過往常出現全系統為了滿足單一硬體需求而耗盡資源,間接害死其他硬體導致系統效能低落的慘況。

那還不如調整成對每個硬體皆只滿足其七八成需求,或者說滿足其「系統層需求」,反而能使系統效能維持在還不錯的程度。至於各個硬體的實際系統層需求到底是如何?對其他硬體的連動影響諸如此類的仲裁或決策,亦是一資訊完整的中央控制系統需要存在的原因。

又由於中央控制系統的框架建立於硬體層,能夠輕易作出更快速、更精確的判斷反應,使動態電壓頻率調變更具效率。

坦白說,對於晶片設計者而言,此中央控制系統的硬體設計一點都不難。真正具挑戰的點在於,設計晶片時是否能將自己的視野從硬體層拉抬到系統層。這也是我不斷強調過的觀點,硬體並非沒有未來,但沒有考慮到系統整合概念的硬體在未來確實備受挑戰。



沒有留言:

張貼留言

注意:只有此網誌的成員可以留言。