設計指南
此電腦熱管理設計指南提供如何判斷「太熱」和「太冷」的電腦溫度值的相關資訊。
做出這些決定是提供良好電腦使用者體驗之設計的重要需求。 此外，這些臨界值也有助於針對位於多個熱區域的電腦群組件，選擇要採取的第一個緩和動作。
設計溫度閾值
變數和假設
下列因素會影響電腦的熱行為：
硬體設計
良好硬體設計的重要性無法過度壓力。 如需詳細資訊，請參閱 硬體熱模型化和評估。
環境
這些是造成系統熱行為的外部因素。 軟體只能藉由通知使用者熱條件約束是問題來影響環境，例如，藉由顯示熱故障到開機標誌。 使用者必須移至不同的環境，這些因素才能變更：
氣氣氣
影響螢幕或系統任何部分之檢測的強度和角度。
周圍溫度
環境的溫度。
氣流
具有或不含空氣迴圈。 風力或電腦案例中。
溼度
幹或水水。
工作負載和耗電量
此處的假設是工作負載和耗電量彼此成正比。 換句話說，電腦或元件所執行的工作越多，耗用的電力越多，產生的熱度就越高。 雖然這在所有情況下都可能不成立，但此簡化模型在這裡已足夠或不足。 這是軟體風險降低的所在位置。 藉由減少工作負載，會產生較少的熱度，而且電腦會持續運作。
設計硬體並建立硬體模型時，請將上述清單中所述的參數納入考慮。 請針對環境使用最差值。 可由軟體直接控制的唯一參數是工作負載。
熱基礎
當電腦執行常數工作負載時，請考慮電腦的熱行為。 當工作負載啟動時，電腦的硬體元件，例如 CPU 和 GPU 會產生熱度並增加溫度。 當溫度相對於環境溫度增加時，電腦會開始更快速地去除熱度，直到最終產生熱度等於熱力迴圈，溫度達到穩定狀態為止。 對於這個常數工作負載的整個持續時間，因為沒有涉及節流，所以效能和輸送量是固定的。
下圖顯示未涉及節流時，熱產生、溫度和效能之間的關聯性。 請注意，電腦的溫度會維持在熱信封內，如同環境溫度和節流溫度所系結。
現在，當電腦執行另一個工作負載時，其熱行為也會持續但需要大量資源。 當此工作負載執行時，產生的熱度遠高於系統能夠散發到環境環境，因此溫度會穩定增加。 若沒有被動冷卻，溫度會繼續增加，直到系統最終變得太熱且對終端使用者的緩和和安全性造成負面影響。 硬體可能也會在高溫度下損毀。 熱節流有助於確保電腦不會達到這些高溫度。 當溫度在預先定義的節流溫度行程點上增加時，系統會開始節流效能。 因此，熱度產生會降低並逐漸減少，並在熱產生和調節相等之後，系統溫度達到穩定狀態。
下圖顯示當效能節流以降低熱度產生時，熱產生、溫度和效能之間的關聯性。
在上圖所示的這兩種情況下，工作負載必須在熱信封內運作，以確保系統溫度不會超過安全限制。 信封以環境溫度開頭，並以節流溫度結束。 此外，在這兩種情況下，熱度產生和壓力最終會達到平衡狀態，而且系統溫度會穩定。
定義熱信封
設計良好的電腦應該盡可能擁有大量的熱信封，為使用者提供長期、無風險降低的體驗。 如上圖所示，熱信封具有環境溫度所決定的下限。 其受到節流溫度的限制。 雖然環境溫度不是系統設計工具可以控制的變數，但高限可以透過良好的硬體設計來推高。 如需詳細資訊，請參閱 硬體熱模型化和評估。 但即使假設硬體不是主要限制，定義熱封時也必須考慮其他重要因素。
所需的作業範圍應該盡可能大，而不需對這些限制因素進行擷取：
安全
系統的溫度必須先確保使用者不會遭受使用系統的任何傷害。 這項需求大部分適用于面板溫度感應器。
硬體防護
溫度應該防止系統元件「中」或造成熱損。 這項需求大部分適用于元件溫度感應器，例如位於處理器頂端的感應器。
政府法規
所有系統都應該符合適用的業界標準 (，例如 IEC 62368) 消費者電子安全。
硬體熱模型化和評估
軟體作為硬體設計的補充
設計硬體時，請務必記住熱管理。 選取低電源元件、將熱元件放在離彼此遠的距離，並併入熱力感應器只是一些硬體如何大幅改善熱度體驗的範例。 這些方法無法在軟體中取代。 因此，軟體解決方案只會做為整體熱體驗中硬體設計的補充。
硬體目標
一般工作負載不應該需要任何形式的軟體熱降低功能來執行。 硬體熱設計應該能夠自行分散這些工作負載的熱度。
模型化
模型化是一種反復程式，可達成先前所述的硬體目標。 在此程式中，請勿考慮任何軟體防護功能。 僅依賴硬體功能，並視需要進行調整。
定義一般工作負載。 根據系統的平臺，從電話到伺服器，每個系統都應該有一組標準的一般工作負載。 這些不應該是密集的工作負載，例如 HD 視訊會議，而是更平均的工作負載，例如流覽網頁或聆聽音樂。
一般工作負載上的模型系統和個別元件耗電量，因為熱度不會統一分散在底座上。 請特別注意耗用大部分電源的元件，例如處理器。
根據工作負載耗電量估計，建立元件和麵板溫度隨時間增加的模型。
調整系統的機械設計，以確保元件溫度在硬體安全限制內，以及所有環境溫度的使用者緩和限制。 解決機械設計問題的一些方法如下：
- 藉由新增更佳的熱度材質來改善熱力消耗能力。
- 藉由新增隔離層，增加面板與內部溫度之間的差異溫度。
重複步驟 1 到 4，直到滿足為止。
建置硬體並評估。
評估
針對每個硬體修訂，必須針對代表性工作負載執行溫度和電源測量，以評估熱行為，並視需要修改機械設計。
建議您執行下列步驟來執行這類熱評估：
定義熱測量測試矩陣：
- 矩陣應該同時涵蓋正常和最大環境溫度。
- 矩陣應該包含識別為熱模型一部分的所有一般工作負載，而且針對每個工作負載，應該至少擷取一小時的資料。
- 矩陣應該多次在多部電腦上執行，以產生一致的結果。
針對測試矩陣中定義的每個工作負載，擷取下列資料：
- 系統和元件耗電量資料。
- 環境、內部元件和麵板溫度資料。
- 用來偵測熱節流、效能計量和處理器使用率的軟體追蹤。
面板和元件溫度資料會直接指出系統可能到達的最大面板溫度，以及此溫度是否可接受。 請考慮系統在重大關機之前可能擁有多少熱力清理。 效能計量資料有助於判斷系統是否正在傳遞所需的效能。 熱節流軟體所記錄的追蹤資料會顯示熱節流百分比。 耗電量資料和 CPU 使用率資料有助於判斷哪些因素會影響溫度變更。
下表提供下列組態的電腦這類資料收集範例：
Configuration
- 機器名稱：熱測試-1
- 平均環境溫度：23oC
- 熱區域車程點 (_PSV) ：80oC
| 類別 | 子類別 | 影片串流 | 隨意遊戲 | 魚缸 | 3D 遊戲 | Tdp |
|---|---|---|---|---|---|---|
| 工作負載設定 | 透過 Wi-Fi 進行全螢幕 720p H.264 視訊串流 | 遊戲名稱 CPU 使用率 |
具有 100 個魚的傳統 IE | 遊戲名稱 CPU 使用率 |
CPU 和 GPU 100% | |
| 耗電量 | 系統電源 | |||||
| SoC 電源 | ||||||
| 顯示電源 | ||||||
| 反光燈電源 | ||||||
| 溫度 | 最大 SoC 溫度 | |||||
| 最大面板溫度 | ||||||
| 效能計量 | 平均畫面播放速率 | 平均畫面播放速率 | 平均畫面播放速率 | 平均畫面播放速率 |
Windows 熱管理架構
Windows 熱管理架構提供軟體熱管理的完整解決方案。 下列範例示範如何實作熱管理。 使用適當的熱模型化、驗證和有效的熱機械設計，所有系統都應該能夠在大部分目標環境溫度上提供順暢的使用者體驗。 需要熱降低功能的地方，Windows 會提供有效且可延伸的熱管理架構。
Windows 熱管理支援主動和被動冷卻。 使用主動冷卻時，風扇會開啟以冷卻空氣，並協助冷卻系統。 使用被動冷卻，裝置可降低裝置效能，以回應過度熱狀況。 降低效能會降低耗電量，因而產生較少的熱度。
Windows 熱管理架構依賴系統設計工具所指定的原則，在系統上強制執行熱管理。 概括而言，設計工具必須指定從每個熱感應器取得的讀數如何受到每個元件的影響。 如果沒有這些規格，Windows 就無法熱地管理系統。 因此，每個系統設計工具的責任都是以熱方式描述其系統，以達到良好的熱設計。
雖然系統不需要使用 Windows 熱管理架構，但它是建議的解決方案，因為它與作業系統緊密整合。 不過，無論使用的熱管理解決方案為何，所有新式待命電腦都必須遵守 HCK 需求以進行診斷。
熱管理架構
Windows 熱管理架構是以 熱區域的ACPI 概念為基礎。 ACPI 熱區域模型需要韌體、作業系統和驅動程式之間的合作。 此模型會透過定義完善的介面，從中央熱管理元件擷取感應器和冷卻裝置。 熱管理增強功能是以 ACPI 5.0 規格的第 11 章為基礎。 Windows 熱管理架構會實作本章中所述功能的子集。
模型的基本元件包括：
- 透過韌體向 Windows 描述的平臺 熱區域 定義。 熱區域是具有相關聯溫度值的抽象實體。 作業系統會監視此溫度，以便將熱風險降低套用至區域內的裝置。 區域包含一組可產生熱度的功能裝置，以及可藉由調整效能來控制熱度產生之裝置的子集。
- 代表區域溫度的 溫度感應器 。 感應器必須實作讀取溫度介面，才能從韌體或 Windows 溫度驅動程式擷取區域的溫度。
- 熱 冷卻介面 ，可讓熱區域內裝置的驅動程式實作被動冷卻動作。 每個 Managed 驅動程式都必須有冷卻介面，才能參與 Windows 熱基礎結構。
- 集中式 熱管理員 ，可藉由解譯熱區定義並在必要時間叫用介面，來協調冷卻。 熱管理員是在 Windows 核心中實作，不需要系統設計工具執行任何工作。
下列區塊圖是 Windows 熱管理架構的概觀。 主要元件是熱管理員、熱區域、受管理驅動程式和溫度感應器。 熱區域會根據熱管理員所提供的條件約束，指定其受管理裝置的節流行為。 熱管理員所使用的演算法會使用感應器的溫度讀數做為其輸入參數。
系統中的熱區域必須在 ACPI 韌體中描述，並透過 ACPI 向熱管理員公開。 使用設定資訊時，熱管理員知道需要管理多少熱區域、何時開始節流每個熱區域，以及哪些裝置是區域的一部分。 為了監視溫度，系統設計工具在 ACPI 韌體中提供熱通知的支援。
當熱管理員在列舉區域中收到熱事件的通知時，它會開始定期評估區域的溫度，並判斷熱節流效能百分比，以套用至熱區域中的裝置。 這項評估是由 ACPI 規格中所述的熱節流演算法所完成。 然後，熱管理員會通知區域中的所有裝置以特定百分比來節流效能，而設備磁碟機會將節流百分比轉譯為裝置類別特定的動作，以降低效能。 當熱區域溫度低於節流臨界值溫度時，定期評估和節流將會停止，而且不需要再進行節流。
意見反應迴圈
另一種考慮熱管理架構的方式是輸入、原則主管和受管理的裝置。 在下列區塊圖中，意見反應迴圈的輸入是溫度和電力目前。 這些輸入可用來判斷要實作的熱原則。 熱管理員完全依賴溫度輸入，而原則驅動程式可能會使用所需的任何輸入。 然後，熱區域會將該原則套用至其受管理驅動程式。 套用原則之後，感應器會更新其值並關閉迴圈。
下圖顯示熱回應模型的三個階段。 來自溫度和電力目前感應器的輸入提供資訊，以協助判斷要套用的熱原則。 此原則會套用至 Managed 驅動程式，然後會影響感應器上的讀數。 此程式會在意見反應迴圈中重複。
系統實作者的責任
如上所述，需要一些元件才能有完整的 Windows 熱解決方案。 熱架構的架構是特別設計，以便分隔硬體廠商和系統整合者的責任。
合作夥伴實作的必要元件如下：
感應器
溫度感應器驅動程式應該由硬體廠商提供。 假設溫度感應器不需要瞭解依賴它們的熱區域，其功能應該是不同平臺設計的標準。 原則驅動程式的自訂感應器，例如目前的感應器，也是硬體廠商的責任。
熱區域
熱區域可由硬體廠商和/或系統整合者定義。 如果支援) ，所有系統都必須有至少一個熱區域，以實作重大關機溫度 (和休眠溫度，這可由硬體廠商或系統整合者完成。 不過，對於監視特定裝置或面板溫度以降低的其他熱區域，系統整合者通常會更明確地瞭解系統的熱行為。 因此，系統整合器通常會實作這些熱區域。
設備磁碟機的熱冷卻介面
撰寫要進行熱管理之裝置的驅動程式的開發人員也應該是實作冷卻介面的驅動程式。 設備磁碟機會使用此介面來加入宣告熱管理架構。 設備磁碟機具有其裝置功能的特定知識。 這些相同的驅動程式必須實作熱冷卻介面，以便正確解譯熱區域所要求的動作。
感應器
感應器會提供輸入，以判斷熱原則應該是什麼。 Windows 僅支援溫度感應器作為熱管理員的輸入。 不過，原則驅動程式可以額外取得來自自訂驅動程式的輸入，例如目前的感應器驅動程式。
溫度感應器
溫度感應器提供下列功能模式：
- 持續監視溫度變更，而不需熱管理員或熱區域介入。
- 當溫度超出_PSV、_HOT或_CRT所定義的臨界值時，通知熱管理員。
- 回應溫度查詢並傳回目前的溫度值。
下圖顯示節流期間溫度監視的運作方式。 ACPI 韌體或溫度感應器驅動程式應該會在溫度達到預先定義的閾值時通知熱管理員，例如_PSV、_HOT或_CRT，然後回應來自熱管理員的目前溫度定期查詢。 溫度查詢的期間是由_TSP所定義。
為了確保溫度超過臨界值時，熱管理員一律會收到通知，即使系統處於新式待命狀態且 SoC 處於低電源狀態) ，溫度感應器中斷也應該永遠能夠喚醒 (。 如果溫度感應器中斷不一定能夠喚醒，則至少應將中斷設定為觸發層級，以避免潛在的中斷中斷中斷。
熱感應器可以由多個熱區域使用，不過熱區域中不能有一個以上的熱感應器。
建議感應器硬體精確到 +/- 2oC。
_TMP或溫度感應器驅動程式所報告的溫度可能是感應器的實際值，或根據數個感應器推斷的值。
這通常是由硬體廠商提供。 Windows 支援兩個監視溫度的實作：
- 溫度感應器驅動程式
- ACPI 型
實作 1：溫度感應器驅動程式
溫度感應器驅動程式只會報告感應器的溫度。 ACPI 驅動程式會向感應器驅動程式發出一個未處理的 IOCTL，以偵測其中一個車程點的交叉。 此外，ACPI 可能會發出一個 IOCTL，沒有逾時來讀取目前的溫度。 感應器驅動程式應該處理讀取 IOCTL 的取消，如果在等候逾時到期時取消。 溫度感應器必須實作下列介面：
typedef struct _THERMAL_WAIT_READ {
ULONG Timeout;
ULONG LowTemperature;
ULONG HighTemperature;
} THERMAL_WAIT_READ, *PTHERMAL_WAIT_READ;
#define IOCTL_THERMAL_READ_TEMPERATURE\
CTL_CODE(FILE_DEVICE_BATTERY, 0x24, METHOD_BUFFERED, FILE_READ_ACCESS)
下表描述溫度讀取介面的輸入和輸出參數。
| 參數 | 描述 |
|---|---|
| 逾時 | 在傳回溫度資料之前等待的時間，以毫秒為單位。 0 表示應該立即讀取溫度，而不需等候。 -1 表示讀取不應該逾時。 |
| LowTemperature | 傳回新溫度的下限。 一旦溫度低於低溫度閾值，驅動程式就應該完成 IOCTL。 如果溫度已經低於低溫度，應該立即完成 IOCTL。 |
| HighTemperature | 傳回新溫度的上限臨界值。 一旦溫度高於高溫度閾值，驅動程式應該就會完成 IOCTL。 如果溫度已經高於高溫度，應該立即完成 IOCTL。 |
| IOCTL 傳回值 | ULONG 大小的輸出緩衝區，會傳回目前溫度，以 Kelvin 的十分之一度為單位。 |
一個溫度感應器可以由一個熱區域或多個熱區域使用。 若要指定應該用於熱區域的溫度感應器，熱_DSM應該在熱區域上指定，而且應該實作函式 2。 (為了回溯相容性，溫度感應器驅動程式可以載入熱區域堆疊頂端。不過，慣用的實作是讓感應器驅動程式與熱區域堆疊分開。) 此_DSM的定義如下：
引數Arg0： UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1： Revision = 0 Arg2： 函式 = 2 Arg3： 空套件 傳回 將傳回熱區域的裝置單一參考。
熱區域也必須指定具有_DEP之溫度感應器裝置的相依性。 以下是_DSM感應器裝置實作的簡單範例。
Device(\_SB.TSEN) {
Name(_HID, "FBKM0001") // temperature sensor device
}
ThermalZone(\_TZ.TZ01) {
Method(_DSM, 0x4, NotSerialized){
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 2 (bits 0 and 2) are supported
Return (Buffer() {0x5})
}
Case (2) {
Return ("\_SB.TSEN")
}
}
}
}
}
Method(_DEP) {
Return (Package() {\_SB.TSEN})
}
// Other thermal methods: _PSV, etc.
}
如需詳細資訊，請參閱 Microsoft 熱延伸模組的裝置特定方法。
實作 2：ACPI 型
ACPI 韌體應該支援_TMP和通知0x80，如 ACPI 規格中所定義。 此方法的優點是不需要在系統上安裝任何其他驅動程式。 不過，此方法僅限於與可透過 ACPI 作業區域存取的資源互動。
熱原則控制
熱區域
熱區域是個別熱節流實體。 它有自己的熱節流特性，例如車程點、節流取樣率，以及節流方程式常數。 一個熱區域可能包含多個熱節流裝置，每個裝置都可能導致溫度在熱區域中增加。 相同熱區域中的所有裝置都必須遵循套用至熱區域的相同條件約束。
為了確保正確定義熱區域及其參數，系統設計工具應該：
- 識別系統底座中的熱點，並判斷這些熱點如何將熱度散發至溫度感應器。 (理想情況下，熱感應器位於系統上的熱點，但面板溫度感應器除外。)
- 描述系統的溫度關聯性。 將溫度感應器讀數對應至元件溫度和麵板溫度。
Overthrottle 閾值
從Windows 10開始，稱為熱區域狀態的新功能已引進 Windows 熱管理，以及一種狀態：過度旋轉。 當熱區域超過裝置設計節流等級時，熱管理員會通知作業系統元件系統已過度旋轉。 此通知可讓系統減少工作負載，以改善熱狀態。
熱管理員會維護處於超限狀態的熱區域數目全域計數。 當計數增加至零 (0) 時，熱管理員會將 Windows 通知設備 (WNF) 通知傳送給系統，指出其已過度分散。 當超流量區域數目傳回零 (0) 時，熱管理員會將另一個 WNF 通知傳送給系統，指出沒有過度分散的區域。
若要指定熱區域的過度分配臨界值，應該在熱區域上指定熱_DSM，並實作函式 3。 此_DSM的定義如下：
引數Arg0： UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1： Revision = 0 Arg2： 函式 = 3 Arg3： 空白套件 傳回 整數值，其目前過度分配閾值，以百分比表示。
以下是一個範例_DSM，指出區域在節流層級為 0% 到 49% 時遭到過度限制。
ThermalZone (TZ4) {
Name (_HID, "QCOM24AE")
Name (_UID, 0)
Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
Method(_PSV) { Return (3530) }
Name(_TC1, 1)
Name(_TC2, 1)
Name(_TSP, 1)
Name(_TZP, 0)
// _DSM - Device Specific Method
// Arg0: UUID Unique function identifier
// Arg1: Integer Revision Level
// Arg2: Integer Function Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Method(_DSM, 0x4, NotSerialized) {
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 3 (bits 0 and 3) are supported
Return (Buffer() {0x9})
}
Case (3) {
Return (50) // overthrottled below 50%
}
}
}
}
}
} // end of TZ4
當收到參考熱區域的通知 (0x81) 時，將會重新讀取過度分配閾值。
實作 ACPI 物件
下表列出必須在 ACPI 韌體中實作的所有 ACPI 物件，以定義熱區域。
| 類別 | Control 方法 |
|---|---|
| 識別區域內所包含的裝置 |
|
| 指定必須採取動作的熱臨界值 |
|
| 描述被動冷卻行為 |
|
| 描述作用中冷卻行為 |
|
| 設定主動/被動冷卻原則 |
|
| 最小節流限制 |
|
| 報告溫度 |
|
| 通知熱管理員 |
|
| 指定溫度感應器裝置 |
|
最小節流限制
最小節流限制是 Microsoft 熱延伸模組_DSM方法，為節流裝置要求_PSV建立下限。 換句話說，它會決定熱區域會限制其所控制裝置的效能。 如果存在，則會在開機時讀取最小節流_DSM，而熱區域隨時都會收到 ACPI 通知 (0x81) 。 在被動冷卻演算法的每個反復專案上，下列專案是用來計算熱管理員套用至區域中裝置的效能限制變更 (DP) ：
DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) 我們接著使用下列方法來計算實際效能限制：
Pn = Pn₋₁ – DP：實作的最小節流限制 (MTL) ，此第二個方程式會變更為：
Pn = 最大 (Pn₋₁ – DP、MTL) 若要指定熱區域的最小節流限制，熱_DSM應在熱區域上指定，並實作函式 1。 此_DSM的定義如下：
引數Arg0： UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1： Revision = 0 Arg2： Function = 1 Arg3： 空套件 傳回 具有目前最小節流限制的整數值，以百分比表示。
以下是_DSM限制節流不超過 50% 的簡單範例。
ThermalZone(\_TZ.TZ01) {
Method(_DSM, 0x4, NotSerialized) {
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 1 (bits 0 and 1) are supported
Return (Buffer() {0x3})
}
Case (1) {
Return (50)
}
}
}
}
}
核心中的熱管理員
Windows 熱管理員會實作為 Windows 核心的一部分。 它會監視所有熱區域的溫度，並適當地套用熱節流。
每次熱管理員查詢 ACPI 驅動程式的目前溫度時，它都會對熱節流效能百分比執行計算，其應該套用至熱區域的所有熱節流裝置。 當超過被動冷卻臨界值 (_PSV) ，而且在每個溫度取樣間隔 (_TSP) ，直到溫度低於溫度且熱限制傳回 100% 時，會評估並套用熱限制。 硬體必須偵測超過_PSV，而且必須透過硬體 ACPI 事件通知發出訊號。
熱節流演算法
熱節流演算法會使用下列方程式，其定義于 ACPI 規格中：
DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt) where
Tn = 溫度感應器的目前溫度讀數，以 Kelvin 的十分之一度為單位的熱區域。 Tn₋₁ = 上一個讀數的溫度。 Tt = 以十分之一度為單位的目標溫度 Kelvin (_PSV) 。 DP = 需要效能變更。 這是介於 0 (完全節流) 和 100% (未中斷) 之間的線性值，這要套用至區域中的每個冷卻裝置。 此方程式描述溫度變更與節流效能之間的意見反應迴圈。 在迴圈的每個反復專案中，目前和先前溫度讀數之間的溫度差異需要效能 P 減少百分比。 DP 值是要套用的 熱節流 數量。 許多冷卻裝置沒有冷卻防護功能的線性熱回應。 在這些裝置中，熱限制是裝置的提示，指出需要多少冷卻。 每個冷卻裝置都有自己的線性值對應到裝置特定的熱防護功能。 節流裝置效能可降低耗電量和熱度產生，這會導致溫度降低。
這兩個常數_TC1和_TC2，可控制在此意見反應迴圈中套用熱節流的方式。 _TC1愈大，使用更積極熱節流來維持穩定的溫度。 較大的_TC2是，使用更積極熱節流來將溫度推送到車程點附近。
下表提供熱管理員如何計算及套用 DP 的範例。 此範例使用下列參數值：
Configuration
- _PSV = 325oK
- _TC1 = 2
- _TC2 = 3
- _TSP = 5000 毫秒
- 假設溫度會每隔 5 秒持續增加 1 度。
下表中最右邊的資料行 (標示為 P) 指出強制執行這些參數所指定條件約束所產生的節流效能等級。
| 反覆運算 | Time | Tn | DP | P |
|---|---|---|---|---|
| 1 | 0 秒 | 326oK | = 2 × 1 + 3 × 1 = 5% | 95% |
| 2 | 5 秒 | 327oK | = 2 × 1 + 3 × 2 = 8% | 87% |
| 3 | 10 秒 | 328oK | = 2 × 1 + 3 × 3 = 11% | 76% |
| 4 | 15 秒 | 320oK | = 2 × 1 + 3 × 4 = 14% | 62% |
| 5 | 20 秒 | 330oK | = 2 × 1 + 3 × 5 = 17% | 45% |
| ... |
原則驅動程式
根據預設，用來判斷 ACPI 規格所指定節流百分比的演算法會用於所有熱區域。 如先前所述，此演算法僅以附加至熱區域的溫度感應器為基礎，可加以限制。
如果偏好使用不同的演算法，系統設計工具可以實作原則驅動程式來模擬慣用的演算法。 原則驅動程式位於其所控制區域的熱區域堆疊之上。 在此區域中，原則驅動程式的演算法可用來取代熱管理員中的 ACPI 演算法。 原則驅動程式的演算法能夠考慮任何可做為輸入存取的資訊。 驅動程式所做的原則決策會傳遞至熱管理員，以記錄資訊並將其傳遞至熱區域以執行。
針對熱區域使用原則驅動程式表示原則驅動程式，而不是 ACPI，而不是作業系統，完全負責決定何時要節流區域和多少。
如果原則驅動程式存在，則會完全忽略所有車程點、所有熱常數、最小節流限制等等。 作業系統無法深入瞭解熱區域在目前節流層級設定的原因。 有些優點隨附于使用原則驅動程式，而不是屬性解決方案。 原則驅動程式會利用節流裝置的內建程式。 熱區域可以執行任何動作來提供熱降低功能，都可以由原則驅動程式完成。 此外，系統會自動繼承 Windows 熱管理的診斷。
熱原則介面已更新，以包含新的參數，以指出區域是否已過度旋轉。 此參數會初始化為 FALSE。 舊的原則驅動程式不會察覺新的參數，而新的驅動程式在偵測到原則版本為 '2' 時，就會知道支援新的參數。
#define TZ_ACTIVATION_REASON_THERMAL 0x00000001
#define TZ_ACTIVATION_REASON_CURRENT 0x00000002
#define THERMAL_POLICY_VERSION_1 1
#define THERMAL_POLICY_VERSION_2 2
typedef struct _THERMAL_POLICY {
ULONG Version;
BOOLEAN WaitForUpdate;
BOOLEAN Hibernate;
BOOLEAN Critical;
ULONG ActivationReasons;
ULONG PassiveLimit;
ULONG ActiveLevel;
BOOLEAN OverThrottled;
} THERMAL_POLICY, *PTHERMAL_POLICY;
原則驅動程式可以藉由完成 將 OverThrottled 參數設定為 TRUE 的原則 IOCTL，來指出熱區域已過度旋轉。 當熱條件改善時，熱原則驅動程式接著可以使用 OverThrottled 重設為 FALSE 來完成 IOCTL，以指出熱區域已復原。 設定 overthrottle 旗標時，Windows 不需要原則驅動程式進行節流。
熱管理裝置
熱區域會透過其核心模式驅動程式控制受管理裝置的熱行為。 一個熱節流裝置可能位於多個熱區域。 當多個熱區域要求不同的熱節流效能百分比時，熱管理員會挑選最小的熱節流效能百分比，以套用至熱節流裝置。
許多冷卻裝置沒有冷卻防護功能的線性熱回應。 在這些情況下，熱限制是所需冷卻程度裝置的提示。 每個冷卻裝置都有自己的線性值對應到其特定的熱防護功能。
載入每個設備磁碟機時，ACPI 會查詢熱冷卻介面，並將每個回應裝置註冊為冷卻裝置。 稍後，當被動冷卻正在進行中，且區域的熱限制已變更時，ACPI 會在該區域中的每個冷卻裝置上呼叫此介面。 冷卻裝置接著會將提供的熱限制對應到其特定的冷卻特性，並實作適當的冷卻防護功能。 請注意，如果冷卻裝置出現在多個熱區域中，限制裝置最 (的熱限制，則會將最低百分比) 傳遞給裝置。
注意 Windows 提供處理器、回光和 ACPI 控制方法電池的熱節流內建實作。
熱冷卻介面
Windows 提供擴充點，讓設備磁碟機註冊為熱節流裝置，並接收熱節流百分比要求。 接著，裝置會負責將該百分比轉譯為本身有意義的動作。
想要新增為熱節流裝置的裝置應該先將_HIDs新增到熱區域熱裝置清單中，然後實作下列一組介面。 載入每個設備磁碟機時，ACPI 會查詢此介面，並將每個回應裝置註冊為冷卻裝置。 稍後，當被動冷卻正在進行中，且區域的熱限制已變更時，ACPI 會在該區域中的每個冷卻裝置上呼叫此介面。 冷卻裝置接著會將提供的熱限制對應到其特定的冷卻特性，並實作適當的冷卻防護功能。 請注意，如果冷卻裝置出現在多個熱區域中，限制裝置最 (的熱限制，則會將最低百分比) 傳遞給裝置。
//
// Thermal client interface (devices implementing
// GUID_THERMAL_COOLING_INTERFACE)
//
typedef
_Function_class_(DEVICE_ACTIVE_COOLING)
VOID
DEVICE_ACTIVE_COOLING (
_Inout_opt_ PVOID Context,
_In_ BOOLEAN Engaged
);
typedef DEVICE_ACTIVE_COOLING *PDEVICE_ACTIVE_COOLING;
typedef
_Function_class_(DEVICE_PASSIVE_COOLING)
VOID
DEVICE_PASSIVE_COOLING (
_Inout_opt_ PVOID Context,
_In_ ULONG Percentage
);
typedef DEVICE_PASSIVE_COOLING *PDEVICE_PASSIVE_COOLING;
typedef struct _THERMAL_COOLING_INTERFACE {
//
// generic interface header
//
USHORT Size;
USHORT Version;
PVOID Context;
PINTERFACE_REFERENCE InterfaceReference;
PINTERFACE_DEREFERENCE InterfaceDereference;
//
// Thermal cooling interface
//
ULONG Flags;
PDEVICE_ACTIVE_COOLING ActiveCooling;
PDEVICE_PASSIVE_COOLING PassiveCooling;
} THERMAL_COOLING_INTERFACE, *PTHERMAL_COOLING_INTERFACE;
#define THERMAL_COOLING_INTERFACE_VERSION 1
處理器
對於處理器，熱管理員會將熱節流百分比傳達給處理器電源管理員， (PPM) 。 處理器的熱節流是 Windows 的內建功能。
處理器匯總工具
處理器匯總工具裝置允許 核心停 駐作為熱降低措施。 如果處理器匯總工具裝置是熱區域的成員，區域可以將核心駐留指定為熱防護功能。 不需要節流處理器，核心停駐就會發生。 此實作與 邏輯處理器識別碼 (LPI) 平行運作。 請注意，這仍受限於核心駐留的注意事項。 特別是，任何與駐留核心同構的工作都會造成核心執行。
Device(\_SB.PAGR) {
Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
Name(_TZD, Package() {"\_SB.PAGR"})
// Other thermal methods: _PSV, etc.
}
圖形
為了讓協力廠商圖形迷你埠驅動程式受到熱管理，它必須與 Windows 圖形埠驅動程式互動，Dxgkrnl.sys。 Dxgkrnl.sys具有熱冷卻介面，並將任何節流要求向下傳遞至迷你埠驅動程式。 迷你埠驅動程式負責將要求轉譯為其裝置特定的動作。
下列區塊圖顯示控制 GPU 的熱區域架構。
背光
減少回光可大幅改善行動平臺上的熱狀況。 Windows 建議在操作時，系統顯示器亮度永遠不會限制為小於 100 nit。
對於回光燈控制，熱管理員會將熱節流百分比傳達給監視驅動程式，Monitor.sys。 Monitor.sys會根據這個熱輸入和其他 Windows 中的輸入來決定實際的回光等級設定。 然後，Monitor.sys會透過 ACPI 或顯示器驅動程式套用倒光等級設定。
請注意，如果包含回光的熱區域溫度持續增加，要求的熱節流百分比最終可能會下降到零%。 ACPI 或顯示器驅動程式中的反光等級實作應該確保終端使用者仍可以看到效能控制項可用的最小亮度等級。
注意 在操作時，系統顯示器亮度永遠不會熱限制為小於 100 nit。
電池
系統中的另一個主要熱度來源是電池充電。 從使用者的觀點來看，充電應該降低，甚至完全在受限制的熱狀況下停止。 不過，在正常使用案例下，不應阻礙電池充電。
注意 建議您在系統 (1) 閒置且低於 35 o C 的環境溫度範圍內，或在環境溫度低於 25oC 的任何條件下 (2) ，但環境溫度低於 25oC 時，不會節流電池充電。
Windows Control 方法電池迷你類別驅動程式Cmbatt.sys直接使用熱冷卻介面，如上所述。 韌體負責在吸引充電時考慮目前的熱限制。 必須有新的 ACPI 控制方法，才能設定充電的熱限制。 此方法會實作為裝置特定方法 (_DSM) ，如 ACPI 5.0 規格第 9.14.1 節中所定義。
若要套用熱節流百分比，Cmbatt.sys會評估裝置特定方法 (_DSM) 控制方法，要求 ACPI 韌體設定充電的熱限制。 在_DSM控制方法中，會定義 GUID 來表示熱限制。
| 精 氨 酸# | 值 | 描述 |
|---|---|---|
| Arg0 | 4c2067e3-887d-475c-9720-4af1d3ed602e | UUID |
| Arg1 | 0 | 修訂版 |
| Arg2 | 1 | 函式 |
| Arg3 | 從 0 到 100 的整數值 | 電池充電的熱限制。 相當於計算的被動節流百分比。 |
| 傳回值 | N/A | 沒有傳回值 |
主動冷卻
從作業系統的觀點來看，平臺有兩種策略可用來實作風扇控制：
使用作用中車程點實作一或多個 ACPI 熱區域，以吸引/解除風扇。
Windows 熱架構支援非常基本層級的作用中冷卻裝置。 唯一支援的收件匣是 ACPI 風扇，而且只能使用開/關訊號來控制。
實作專屬解決方案，透過驅動程式、內嵌控制器等) 來控制風扇 (。
雖然 Windows 不會控制風扇專屬解決方案的行為，但 Windows 支援風扇通知給所有實作的熱管理員，包括內嵌控制器，以便收集診斷資訊和遙測。 因此，所有新式待命電腦都需要風扇暴露在作業系統上，強烈建議所有其他電腦使用。
請注意，主動冷卻的實作與先前討論的被動冷卻防護功能完全分開。
ACPI 熱區域的風扇控制
Windows 支援 ACPI 1.0 D 狀態型風扇定義。 (如需詳細資訊，請參閱 ACPI specification.) 因此，控制項僅限於 開啟 和 關閉。 風扇的驅動程式是在 Windows ACPI 驅動程式中提供，Acpi.sys。
- 溫度感應器會讀取溫度已超過車程點，併發出通知 (0x80) 的相關熱區域。
- 熱區域會使用_TMP控制方法讀取溫度，並將溫度與作用中車程點進行比較 (_ACx) ，以決定風扇是否需要開啟或關閉。
- 作業系統會將風扇裝置放在 D0 或 D3 中，這會導致風扇開啟或關閉。
下列區塊圖顯示由 ACPI 熱區域控制的風扇控制流程。
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
// additional methods to turn the fan on/off (_PR0, etc.)
}
ThermalZone(TZ0) {
Method(_TMP) {...}
Name(_AC0, 3200)
Name(_AL0, Package() {\_SB.FAN})
}
}
ACPI 中的多速度風扇
若要使用 ACPI 1.0 達到風扇的多個速度，有兩個選項：
- 當只有一個實體風扇存在時，熱區域可以包含多個「風扇」。 一次有更多「風扇」可轉譯為更快的風扇速度。 如需詳細資訊，請參閱 ACPI 5.0 規格中的第 11.7.2 節中的此選項範例。
- 風扇開啟時，可以決定其本身旋轉的速度。 例如，具有內嵌控制器的系統可以選擇此選項。
適用于風扇的專屬解決方案
Windows 必須能夠使用任一實作來偵測風扇活動。 當平臺使用 ACPI 熱模型時，Windows 會負責開啟和關閉風扇，因此已經知道其作用中時間。 使用專屬解決方案來控制風扇時，Windows 需要通知風扇正在執行。 若要啟用此功能，Windows 將支援 ACPI 4.0 風扇延伸模組的部分子集，如下表所列。
| 功能 | 描述 | 支援 |
|---|---|---|
| _FST | 傳回風扇的狀態。 | 是 |
| 通知 (0x80) | 表示風扇的狀態已變更。 | 是 |
| _FIF | 傳回風扇裝置資訊。 | 否 |
| _Fps | 傳回風扇效能狀態的清單。 | 否 |
| _FSL | 設定風扇效能狀態 (速度) 。 | 否 |
Windows 會使用 _FST 物件來判斷風扇是否在執行 (控制項欄位為非零) 或關閉 (控制項欄位為零) 。 Windows 也會在風扇裝置上支援通知 (0x80) ，指出_FST已變更，且需要重新評估。
實作_FST物件的風扇不需要位於熱區域的_ALx裝置清單中，但可以做為此清單。 此選項會啟用混合式解決方案，其中風扇通常是由協力廠商驅動程式控制，但如果未安裝協力廠商驅動程式，則可以由 OS 熱區域控制。 如果風扇位於_ALx裝置清單中，且熱區域 (放置於 D0) ，則_FST物件必須指出非零的 Control 值。
針對所有風扇，Windows 會使用下列演算法來決定風扇的狀態：
- 如果風扇在 D0 (，因為熱區域_ACx行程點被交叉) ，就會參與。
- 如果風扇位於 D3 中，且不支援 ACPI 4.0 擴充功能，則會解除連線。
- 如果風扇位於 D3 並支援 ACPI 4.0 擴充功能，則作業系統會檢查_FST的 [控制] 欄位是否有非零值，以查看風扇是否參與。
範例 1： 硬體風扇控制
在此範例中，風扇是由內嵌控制器控制。
- 內嵌控制器會根據自己的內部演算法決定啟動或停止風扇。
- 啟動或停止風扇之後，內嵌控制器會在風扇裝置上發出通知 (0x80) 。
- 作業系統會評估_FST，並讀取風扇的新狀態。
下列區塊圖顯示內嵌控制器所控制之風扇的控制流程。
下列 ASL 範例會定義「風扇」裝置，以通知作業系統在風扇狀態中的變更：
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
Name(_FST, Package() {0, 0, 0xffffffff})
// \_SB.FAN.SFST called by EC event handler upon fan status change
Method(SFST, 1) {
// Arg0 contains the new fan status
Store(Arg0, Index(_FST, 1))
Notify(\_SB.FAN, 0x80)
}
}
// Omitted: EC event handler
}
範例 2： 驅動程式風扇控制項
在此範例中，協力廠商驅動程式正在控制風扇。
- 驅動程式會根據自己的內部演算法決定啟動或停止風扇。
- 驅動程式會修改風扇的狀態，並在其熱裝置上評估 SFST) (自訂控制方法。
- 熱設備控制方法會更新風扇裝置的_FST內容，併發出通知風扇裝置上的 (0x80) 問題。
- 作業系統會評估_FST，並讀取風扇的新狀態。
下列區塊圖顯示協力廠商驅動程式所控制的風扇控制流程。
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
Name(_FST, Package() {0, 0, 0xffffffff})
}
Device(THML) {
Name(_HID, "FBKM0001")
Method(SFST, 1) {
// Arg0 contains the new fan status
Store(Arg0, Index(\_SB.FAN._FST, 1))
Notify(\_SB.FAN, 0x80)
}
}
}
風扇存在
平臺表示系統上有風扇，方法是在 ACPI 命名空間中包含風扇裝置 (PnP ID PNP0C0B) 。 Windows 會將此裝置顯示為系統具有風扇，而沒有此裝置表示系統沒有風扇。
新式待命特有的指引
Windows 熱管理架構是核心的一部分，隨附于所有 Windows 系統。 因此，上述材料適用于所有電腦。 不過，不同類型的機器需要新式待命更特定的其他指引。
新式待命會將智慧型手機電源模型帶入電腦。 它會提供使用者手機上預期使用者體驗的立即開啟、立即關閉。 就像在手機上一樣，新式待命可讓系統隨時保持最新、最新狀態，並在有適當的網路可用時連線。 Windows 10支援符合特定 Windows 認證需求的低電源平臺上的新式待命。
新式待命電腦是具有精簡且淺色尺寸的高度行動裝置。 此外，新式待命電腦一律處於 ACPI S0 狀態。 為了提供健全且可靠的客戶體驗，整個系統—從機械設計到韌體和軟體實作，都必須以對熱特性的重要注意進行設計。 因此，所有新式待命電腦都必須遵守熱需求。
新式待命需求
所有新式待命電腦都必須通過下列 HCK 測試：
- 所有新式待命電腦都必須至少有一個熱區域，其中定義了重大關機溫度 (_CRT) 。 針對 x86 系統，建議您定義重要的休眠溫度 (_HOT) ，以觸發儲存使用者資料。 _HOT必須低於_CRT，_CRT應該低於韌體安全熱行程點。
- 每個熱區域都必須報告感應器的實際溫度 (_TMP) 。 測試會在電腦上執行不同的工作負載，而且溫度預期會變更。
此外，我們建議每部電腦至少包含一個 SoC 溫度感應器。
主動冷卻需求
使用風扇的新式待命電腦必須遵守下列額外需求，這些需求是在 HCK 中測試：
- 風扇必須公開至作業系統。 如需詳細資訊，請參閱 風扇存在。
- 作業系統必須隨時知道風扇是否開啟或關閉。 即使在新式待命中的閒置復原中，風扇活動中的任何變更都必須喚醒 SoC 以更新狀態。 如需實作風扇通知的詳細資訊，請參閱 ACPI 熱區域的風扇控制。
- 當電腦處於新式待命狀態時，風扇不得開啟。 使用新式待命期間的實際工作負載，每當螢幕關閉時，風扇就不能開啟。
從使用者的觀點來看，當電腦處於新式待命狀態時，電腦似乎會關閉。 使用者預期新式待命中的電腦的行為就像處於系統「睡眠」狀態一樣。 因此，使用者預期風扇永遠不會開啟，就像在睡眠期間的傳統電腦一樣。 如果風扇出現，使用者可能會聽到它，/或感覺熱空氣流動，並認為電腦無法正常運作。 因此，在新式待命中，風扇不應該開啟。 如需必要行為的詳細資訊，請參閱 新式待命電腦的 HCK 測試需求。
這些需求表示當螢幕開啟時，冷卻原則可能需要與螢幕關閉時不同。 當螢幕開啟時，電腦可能會使用主動冷卻，但必須只在螢幕關閉時依賴被動冷卻。 當螢幕開啟時，風扇的作用中車程點可能會比關閉時還低很多。 針對 ACPI 實作，_ACx必須在新式待命專案上更新。 針對專屬解決方案，請務必在內嵌控制器中更新原則。
處理器節流
PPM 會將最大、所需且最少的效能等級傳達至 PEP。 在熱節流條件下，最大效能等級應該等於熱管理員所要求的節流效能。 PEP 接著會根據 PPM 的效能等級需求來設定 CPU 的實體電壓和頻率。
風扇雜訊訊號
從Windows 11開始，裝置可以將風扇雜訊訊號傳送給作業系統，以用於資源管理決策，目標是為使用者提供非經常性且無訊息的體驗。 此加入宣告介面可讓韌體將風扇 RPM 資訊以從 0 (風扇關閉的值傳送至 OS，) 傳送至最大 RPM，OS 可以在資源管理決策中視需要將裝置冷卻。 這會產生兩個主要優點：
- 無訊息使用者體驗： 風扇雜訊和熱空氣風扇是客戶不滿意的重要來源。 當使用者不預期有大量風扇活動時，尤其如此，例如當裝置執行少量工作或沒有前景工作時。
- 改善的電池使用時間： 較高的風扇速度會導致更多的電源使用量，這會導致 DC 上的電池耗盡速度，而在 AC 上較慢的充電速度。
目前，此訊號可用來管理搜尋索引子工作，而且有計劃讓其他背景工作使用這個訊號。
下圖摘要說明如何將風扇雜訊訊號從韌體傳送到軟體的層中。
風扇雜訊訊號的運作方式
ACPI 介面詳細資料
以下是用來支援此功能的裝置特定方法 (_DSM、UUID：A7611840-99FE-41ae-A488-35C75926C8EB) 的四個功能。 如需有關_FST (風扇狀態) 的資訊，請參閱ACPI 規格的 11.3.1.4 節和範例 1：熱管理裝置的硬體風扇控制
下圖摘要說明如何使用這些函式的流程。
下列區塊圖顯示內嵌控制器所控制的風扇控制流程，包括 Notify (0x80) 控制方法。
注意
風扇雜訊訊號不會控制風扇 RPM，而是通知 OS 有需要從背景工作移動 CPU 資源才能完成優先順序工作的風扇雜訊。
列舉函式 (函式 0)
若要讓作業系統與平臺互動，ACPI 裝置必須透過命名空間公開。 此裝置必須包含包含 EISAID (「PNP0C0B」) 的 _CID 物件。 此裝置的範圍必須包含下列_DSM定義，指出裝置支援的_DSMs。
| UUID | 修訂版 | 函式 | 描述 |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
0 |
列舉函式 |
返回： 為了指出上述函式 0 到 3 的支援，列舉函式函式 (函式 0) 應該會傳回0xF。 如需詳細資訊，請參閱 ACPI 規格 的 9.1.1 節。
取得風扇車程點支援函式 (函式 1)
硬體會告知 OS 在 RPM 方面所支援的內容。
| UUID | 修訂版 | 函式 | 描述 |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
1 |
取得風扇車程點支援 |
引數
Arg0： UUID：A7611840-99FE-41ae-A488- 35C75926C8EB
Arg1：修訂：0
Arg2： 函式：1
Arg3： 空的套件
返回： 整數值，包含 RPM 中風扇車程點所支援的資料細微性。 如果不是零，OS 可能會選取屬於多個通知細微性的車程點。 例如，若資料細微性為 200，OSPM 將允許選取位於 0、200、400、600 等的車程點。Rpm。 值為 0 表示不支援車程點。
設定風扇車程點函式 (函式 2)
OS 會與硬體通訊，也就是下一個通知車程點;硬體會在發生時通知 OS。
| UUID | 修訂版 | 函式 | 描述 |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
2 |
取得風扇車程點 |
引數
Arg0： UUID：A7611840-99FE-41ae-A488-35C75926C8EB
Arg1： 修訂：0
Arg2： 函式：2
Arg3： 包含下層和上行點的套件。 (2 個專案 int。索引 0 的下層、索引 1 上層)
OSPM 只會選取在函式 1 中指定的車程點資料細微性倍數的車程點。 當風扇的實際速度高於或低於上/下層車程點時，平臺應該會在風扇裝置上發出通知 (0x80) 。 OSPM 接著會評估_FST (風扇狀態) ，以判斷目前的風扇速度。 如果設定車程點時風扇速度已經超出指定的車程點，平臺應該會立即發出通知 (0x80) 。
上行點會是資料細微性的倍數。 下層車程點會 (多個資料細微性，) + 1 (下行點 < 上行點) 。 當 RPM 為 0 時，OS 會將較低的車程點設定為 0，並將上行點設定為 1。
返回： 沒有。
取得風扇作業範圍函式 (函式 3)
RPM 之間的對應 – > 影響。 請注意，只有一個風扇 (最接近 SoC) 的風扇可以實作此介面，它必須實作 ACPI 規格 9.1.1 節 中的所有 3 個函式加上函式 0。
| UUID | 修訂版 | 函式 | 描述 |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
3 |
取得風扇作業範圍 |
引數
Arg0： UUID：A7611840-99FE-41ae-A488-35C75926C8EB
Arg1： 修訂：0
Arg2： 函式：3
Arg3： 空的 Package。
返回： 包含下列格式的套件：
Package () {
Impact1MaxRPM, // Integer (DWORD)
Impact2MaxRPM, // Integer (DWORD)
Impact3MaxRPM, // Integer (DWORD)
MaxRPM // Integer (DWORD)
}
| 欄位 | 格式 | 描述 |
|---|---|---|
Impact1MaxRPM |
整數 (DWORD) |
風扇影響範圍 1 的最大RPM。 |
Impact2MaxRPM |
整數 (DWORD) |
風扇影響範圍 2 的最大RPM。 必須是 >= Impact1MaxRPM。 |
Impact3MaxRPM |
整數 (DWORD) |
風扇影響範圍 3 的最大RPM。 必須是 >= Impact2MaxRPM。 |
MaxRPM |
整數 (DWORD) |
風扇可以運作的最大 RPM。 必須是 >= Impact3MaxRPM。 |
下表用來衍生每個風扇影響等級的 RPM 範圍：
| 影響分數 | 較低的 RPM 值 | 高 RPM 值 |
|---|---|---|
1 |
1 |
Impact1MaxRPM |
2 |
Impact1MaxRPM + 1 |
Impact2MaxRPM。 |
3 |
Impact2MaxRPM + 1 |
Impact3MaxRPM |
4 |
Impact3MaxRPM + 1 |
MaxRPM |
例如，如果平臺未使用影響範圍 (，如果風扇直接從影響範圍 2 轉換到影響範圍 4) ，則可以藉由將未使用影響範圍的最大 RPM 設定為等於較低影響範圍的最大 RPM 來表示。
範例對應
| 傳送至 OS 的值 | 風扇 RPM | 使用者體驗 | RPM 上限 |
|---|---|---|---|
0 – 低 |
1-4000 RPM (<=25 dBA) |
風扇未開啟或開啟，但無問題 |
Impact1MaxRPM = 4000 |
1 – 中 |
4001-5000 RPM (25-30 dBA) |
使用中度令人不滿意的風扇開啟 |
Impact2MaxRPM = 5000 |
2 – Medium-High |
5001-6000 RPM (30-36 dBA) |
使用中高擾度開啟風扇 |
Impact3MaxRPM = 6000 |
3 – 高 |
6001+ RPM (36+ dBA) |
使用高Noyance 的風扇開啟 |
MaxRPM = 9000 |
範例 ASL 程式碼
...
// _DSM - Device Specific Method
// Arg0: UUID Unique function identifier
// Arg1: Integer Revision Level
// Arg2: Integer Function Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Method(_DSM, 0x4, NotSerialized) {
If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 through 3 are supported
Return (Buffer() {0xf})
}
Case(1) {
// Report 200 RPM granularity for trip points
Return (\_SB.FAN0.GRAN)
}
Case(2) {
// Save lower RPM trip point
Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
// Save upper RPM trip point
Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
// Configure hardware for the trip points, Tell EC to set fan speed trip point.
\_SB.FAN0.CRNF()
Return (0)
}
Case(3) {
Return (Package(4) {
4000, // 1-4000 RPM is impact score 1
5000, // 4001-5000 RPM is impact score 2
6000, // 5001-6000 RPM is impact score 3
9000})// 6001-9000 RPM is impact score 4
}
Default {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
}
Else {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
} // end of FAN0
}
測試和追蹤
請參閱下列步驟，以收集Windows 效能分析器 (WPA) 中的記錄和檢視：
- 設定 - 搜尋 Windows - >> 進階搜尋索引子設定 - > 進階 - > 刪除和重建索引 (重建)
- wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
- 重新開機系統
- 檢查 [設定] 的索引狀態 - > 搜尋 Windows (確定裝置與 AC 電源來源連線。)
- 當索引完成時，請停止追蹤：wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (取消追蹤而不儲存：wpr -boottrace –cancel)
- 透過Windows 效能分析器 (WPA 開啟AcpiFanNoiseImpact.etl) 。
下載 位於AcpiFanNoiseImpact.zip Or 的檔案，複製下列內容並儲存為 AcpiFanNoiseImpact.wprp
<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
<Profiles>
<!-- BufferSizes are in KB in WPRP -->
<!-- System Collectors -->
<SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</SystemCollector>
<!-- Event Collectors -->
<EventCollector Id="MyEventCollector" Name="User Session Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</EventCollector>
<!-- System Providers for collecting kernel events. -->
<SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
<Keywords Operation="Add">
<Keyword Value="Loader" />
<Keyword Value="Power" />
<Keyword Value="ProcessThread" />
</Keywords>
</SystemProvider>
<!-- System Providers for collecting kernel events. -->
<!---->
<EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
<Keywords>
<Keyword Value="0x2" />
</Keywords>
<CaptureStateOnStart>
<Keyword Value="0x0" />
</CaptureStateOnStart>
<CaptureStateOnSave>
<Keyword Value="0x0" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
<Keywords>
<Keyword Value="0xffffffff" />
</Keywords>
<CaptureStateOnSave>
<Keyword Value="0xffffffff" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
<EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
<CaptureStateOnSave>
<Keyword Value="0xFFFFFFFFFFFFFFFF" />
</CaptureStateOnSave>
</EventProvider>
<Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
<Collectors>
<SystemCollectorId Value="MySystemCollector">
<SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
</SystemCollectorId>
<EventCollectorId Value="MyEventCollector">
<EventProviders>
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
<EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
</EventProviders>
</EventCollectorId>
</Collectors>
</Profile>
</Profiles>
<TraceMergeProperties>
<TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
<DeletePreMergedTraceFiles Value="true" />
<FileCompression Value="true" />
<CustomEvents>
<CustomEvent Value="ImageId" />
<CustomEvent Value="BuildInfo" />
<CustomEvent Value="VolumeMapping" />
<CustomEvent Value="EventMetadata" />
<CustomEvent Value="PerfTrackMetadata" />
<CustomEvent Value="WinSAT" />
<CustomEvent Value="NetworkInterface" />
</CustomEvents>
</TraceMergeProperty>
</TraceMergeProperties>
</WindowsPerformanceRecorder>
下圖是範例 WPA 圖形，顯示當風扇大聲時，搜尋索引子會回復。
有一個層級的風扇會讓搜尋索引在最高 (完全回復，這應該會影響分數 4) ，但所有其他的風扇層級都應該減少活動，而不是暫停。 例如，如果 ACPI 在函式 3 中宣告 Impact3MaxRPM = 4000 RPM (取得風扇作業範圍函式) ，則當風扇 RPM > 4000 (4100RPM、4500RPM) 時，我們會看到SearchIndexer.exe，並暫停SearchProtocalHost.exe CPU 使用量。
注意
若要查看 CPU 使用量，您可以使用 wpr -start power -filemode 來收集執行時間使用量。 使用 wpr -stop fan_noise.etl 停止收集記錄。
下圖顯示範例 WPA 圖形，其中顯示SearchIndexer.exe和 SearchProtocolHost 的暫停
