Intel® Power Gadget is being deprecated

[inimaz]

• CodeCarbon version: any
• Python version: any
• Operating System: Windows/MacOs (any OS that uses Intel Power Gadget)

Description

Intel® Power Gadget will no longer be available after December 1, 2023, and will not be supported with any additional functional, security, or other updates

Source: Power Gadget page

They are proposing to use https://github.com/intel/pcm as a replacement.

Goal

Adapt IntelPowerGadget https://github.com/mlco2/codecarbon/blob/master/codecarbon/core/cpu.py#L49C7-L49C23
so it is able to either use the APIs of PCM (if available) or the old Intel® Power Gadget.

[benoit-cty]

PCM is not a suitable replacement for Power Gadget because it is really hard to install: https://github.com/intel/pcm/blob/master/doc/WINDOWS_HOWTO.md
I think it won't be installed by our user.

PCM is a great tool to use under Linux or Mac as it provides detailed infos.

I spend some times finding alternatives, the only one I find is https://github.com/LibreHardwareMonitor/LibreHardwareMonitor

[benoit-cty]

PyHardwareMonitor is now on PIP : https://pypi.org/project/HardwareMonitor/1.0.0/

[MathieuCiancone]

Hi there !
Do you know if the migration toward from intel power gadget to the suggested tool (Hardware Monitor) is planned soon ?

[benoit-cty]

Hello,
Sorry, nobody is working on it.

You could try to use the beta version 3 pip install codecarbon==3.0.0rc0 that rely on CPU load when no other method are available.

[benoit-cty]

Hello,
Sorry, nobody is working on it.

You could try to use the beta version 3 pip install codecarbon==3.0.0rc0 that rely on CPU load when no other method are available.

[benoit-cty]

Good news: there is now a better option than both PCM and LibreHardwareMonitor.

Since Windows 11, the OS kernel itself exposes RAPL data through the built-in Energy Meter Interface (EMI) — the same MSR-based package-energy counters we already read from /sys/class/powercap on Linux. This is what Firefox's power profiler switched to after Power Gadget was deprecated (Mozilla bug 1774844).

Why it beats the alternatives discussed here:

	PCM	LibreHardwareMonitor	EMI
Third-party kernel driver	yes	yes (WinRing0, CVE-listed)	no — built into Windows
Admin required	yes	yes (for power sensors)	no
Extra dependencies	native install	pythonnet + .NET 4.7	none — pure ctypes
Intel + AMD	Intel only	both	both
Data quality	measured	measured	measured (same RAPL counters)

The API surface is small: enumerate the GUID_DEVICE_ENERGY_METER device interface, CreateFile, then DeviceIoControl with IOCTL_EMI_GET_METADATA / IOCTL_EMI_GET_MEASUREMENT. It returns a cumulative energy counter (picowatt-hours) per channel (e.g. RAPL_Package0_PKG) that we delta over time — exactly the semantics of our existing IntelRAPL implementation.

Limitations, to be transparent:

• Windows 11 only (on Windows 10, EMI only reports on devices with physical metering hardware, e.g. Surface Book).
• Bare metal only — VMs won't expose it (same as RAPL on Linux, so no regression).
• Measures the whole CPU package, not per-process — same caveat as RAPL today.

Proposed plan:

1. New WindowsEMI backend (stdlib-only, ctypes) used by default on Windows 11 when available
2. Deprecate the Power Gadget path (it can no longer even be downloaded)
3. Keep CPU-load mode as the fallback for Windows 10 / VMs

I'm starting an implementation on the windows_support branch.