为什么任务管理器可以查看GPU温度但不能查看CPU温度

直接的原因是，GPU温度有驱动标准要求提供。

有一个叫Windows Display Driver Model(WDDM)的东西，Windows显卡驱动模型，简单说就是一套驱动API标准。Windows要求显卡驱动必须支持一定版本的WDDM，不然一些特性无法使用，是一种保证操作系统的界面整个功能能正常使用的方法。

自从WDDM2.4开始加入了GPU Performance Extension，这一扩展要求能够以标准的方式提供包括显卡温度在内的一系列性能数据。这些数据显然是用来给系统和应用程序评估显卡的性能状态的，拿了一些放在任务管理器的性能页面里。

很显然，问题的另一边就是因为CPU并没有这种标准的驱动模型。

之所以没有这种模型，主要是因为其实CPU温度比GPU温度复杂得多，这个复杂度主要来自软件和硬件的发展历史。

GPU的温度简单，主要是因为NV和ATI长期以来都采取了较为保守的数据开放策略。最初主要是为了防止第三方修改硬件，比如通过加更大的散热器允许超频来搅乱高低端产品的区隔。长期以来，即便GPU内部有大量传感器，允许传给软件的数据量极少，这反而使得软件标准化实现变得简单了。

而CPU那边则很不同，在2000年前后，很多消费级CPU就开始装置温度传感器了，但同时代服务器端产品已经有了传感器阵列。而这两者间的实现是不同的，而且较为混乱。有的传感器是主板负责提供的，有的传感器是CPU负责提供的，有的甚至是各种接口的扩展卡提供的，这个问题直到今天也存在。

实际上到现在很多平台上还能看到三个不同的CPU温度：主板在CPU底座上设置的温度传感器提供的，CPU在基板上的温度传感器提供的，CPU在芯片内的温度传感器提供的。这三个数据还往往可以由三种独立的硬件提供：主板的EC，CPU(和主板)的LPC Super I/O，CPU的扩展指令。

很显然，使用同一套软件实现来兼容这么多种数据是很麻烦的，维护成本高稳定性堪忧，而且对用户来说解读数据更麻烦。

说回到Windows，因为这个复杂度所以Windows设计采用了兼容第三方数据的接口的方案，也就是WMI里面的TemperatureSensor类。但即便如此，这个数据类也对厂商很不友好。

对服务器产品产品来说，数据结构太简单了，特别是无法实现上下级数据关联和一次性更新大量传感器数据(一台服务器可能有四百多个温度传感器数据)，所以对用户来说没什么用。

而对消费级产品来说，数据字段太复杂了，驱动或者BIOS很难填上足够多的有意义的数据，看起来空空荡荡的。

最终就是现在如果你用消费级产品会看到这些数据或者是空白或者干脆就没有，而服务器产品则会有有效但残缺的数据。很显然，这样的数据没法整合到任务管理器里面。