TIMBER 4.19 adds long-term thermal monitoring for AMD Radeon RX 7000- and RX 9000-series graphics cards, using the difference between GPU Edge temperature and GPU Hotspot temperature to flag a card whose cooling behavior changes over time. The practical value is not a new on-screen temperature readout: it is a way to detect a rising delta under comparable load before an owner concludes, from one hot gaming session, that a cooler or thermal paste has failed. Igor Wallossek’s August 2 report at Igor’sLAB describes the AMD addition as an extension of TIMBER’s earlier NVIDIA Blackwell work. The Radeon implementation deliberately gives up the spatial die analysis available on Blackwell hardware rather than synthesizing equivalent-looking sensor data from values AMD does not publish. That restraint is the right call, but it also defines what TIMBER can and cannot establish on a Radeon card.
AMD’s own ADLX documentation independently confirms that its performance-monitoring interface can expose GPU temperature, hotspot temperature, clock speed, fan speed, GPU usage, voltage, GPU power, VRAM clock speed, timestamps, and Total Board Power. AMD Software: Adrenalin Edition also exposes and logs GPU Current Temperature, GPU Junction Temperature, Total Board Power, utilization, clocks, and fan speed on supported Radeon systems. TIMBER is therefore working from telemetry AMD already makes available, not accessing undocumented die sensors.

RGB-lit gaming PC with a triple-fan GPU beside charts showing high temperatures, power, clock speed, and utilization.The measurement is the gap, not the headline temperature​

TIMBER’s Radeon model is straightforward:
Hotspot-to-Edge spread = GPU Hotspot temperature − GPU temperature
That distinction is more important than it may first appear. A single GPU temperature is affected by room temperature, case airflow, dust accumulation, fan curves, game workload, resolution, power limit, voltage tuning, clock behavior, and cooler design. It can tell an owner that a card is running hot, but it does not by itself explain whether the source is general cooling or a local change in heat transfer at the GPU package.
A hotspot that rises while Edge temperature stays nearly steady is a different pattern. Igor’sLAB offers an illustrative case where GPU temperature rises by 1 K but hotspot temperature climbs by 7 K, moving the spread from 19 K to 25 K. That does not prove paste pump-out or a damaged contact surface. It does identify a more concentrated thermal change than a uniform rise in both readings would.
The interpretation is sensible because AMD itself labels the hotter sensor as GPU Junction Temperature in Adrenalin. TIMBER calls it Hotspot, while the user-facing driver calls it Junction; for this purpose, they refer to the same basic signal: the driver-reported hottest area of the GPU die. Users comparing TIMBER logs with Adrenalin should not mistake a naming difference for a second independent sensor.
The more mundane alternative remains important. If both Edge and Hotspot rise together while their spread remains stable, the likely suspects are external to the die-to-cooler interface: higher ambient temperature, an altered fan curve, a dust-loaded heatsink, poorer intake airflow, or a changed power limit. TIMBER’s contribution is that it attempts to distinguish this broad shift from a local divergence, rather than treating every temperature increase as a repaste diagnosis.

Total Board Power is the safeguard against misleading 99% utilization​

The strongest part of the Radeon implementation is not the spread calculation; it is the decision to log the surrounding operating state. TIMBER records the temperature pair, calculated spread, timestamp, Total Board Power where available, GPU clock, utilization, fan speed and fan setting, plus memory temperature. This is what turns a useful formula into a potentially useful historical monitor.
A GPU reported at 99% utilization is not necessarily operating at an equivalent thermal condition from one session to the next. A frame cap, resolution change, game engine, driver revision, undervolt, clock limit, power limit, or different scene complexity can all leave utilization near 99% while materially changing watts through the board. The same 20 K spread at 100 W and 300 W is not a like-for-like result. Igor’sLAB makes that point explicitly, using a 280 W board-power point as more useful than utilization alone.
AMD’s ADLX interface supports that approach: it defines Total Board Power separately from GPU Power. The distinction is consequential. Board power includes more of the card’s operating load than an ASIC- or chip-level power number, including components such as memory and board power delivery. When TIMBER cannot retrieve Total Board Power and falls back to GPU or ASIC power, it should be treated as a different comparison class, even if the two readings happen to be numerically close.
The report says TIMBER identifies the source rather than mislabeling fallback data as Board Power. That is necessary, but the published description does not say whether a historical profile is automatically segmented or reset when the available power metric changes. It should be. A baseline built around total board watts should not silently become the reference for a later ASIC-power series, because the comparison would look more precise than it is.
This is a broader limitation for anyone monitoring a Radeon across months. A driver update, VBIOS update, replacement cooler, changed fan curve, undervolt profile, or even a different case can alter the inputs TIMBER uses to classify behavior. The report explains that profiles are per-card and that its original reference is not continuously overwritten, which prevents genuine gradual degradation from being absorbed into a moving baseline. But it does not state whether those system-level changes invalidate, annotate, or branch the baseline. That missing baseline-management policy is the most important operational question in TIMBER 4.19.

Radeon support does not reproduce Blackwell’s sensor model​

TIMBER’s original Blackwell analysis used multiple internal temperature points to infer a more spatially resolved picture of the die. On Radeon, the public ADL and ADLX interfaces do not provide an equivalent matrix of direct die-temperature sensors. TIMBER therefore works with two primary temperature values: general GPU temperature and hotspot temperature.
That means the AMD feature cannot identify whether an abnormal hotspot has shifted from one area of the die to another, identify a specific edge or corner of the package, or map an emerging local pattern across the silicon. It has one maximum-temperature signal and one general-temperature signal. A rising gap is useful, but it cannot diagnose where the transfer problem lies.
This is also why the software’s wording matters. A persistent increase in hotspot-to-edge spread under comparable conditions is consistent with deteriorating local thermal transfer. It may be associated with thermal paste pump-out, paste hardening, uneven application, reduced mounting pressure, cooler deformation, package movement, or another contact issue. It is not proof of any one failure mode.
Owners should resist the urge to convert a flagged trend directly into “bad paste” or a warranty claim. Before opening a card, test the finding against the obvious variables: return Adrenalin tuning to a known profile, clean the cooler, verify fan behavior, use the same game or repeatable workload, maintain a similar power target, and allow the case to reach a stable internal temperature. A repeatable, load-dependent rise in spread after those checks is more meaningful than an isolated peak during a heat wave or after a driver tweak.

The stated thresholds are alerts, not Radeon-wide limits​

According to Igor’sLAB, TIMBER’s Radeon evaluation treats changes of roughly 1.5 K in GPU temperature and spread as stable, values up to roughly 3 K as a slight deviation, and changes of up to roughly 5 K in Edge temperature or 6 K in spread as increased deviation. Larger changes are classified as strong deviations.
Those thresholds should not be read as universal “safe” or “unsafe” Radeon limits. They are change-from-baseline thresholds, not thermal specifications for an RX 7900 XTX, RX 9070, RX 9070 XT, or every board-partner design. A large triple-slot cooler, a compact dual-fan card, a liquid-cooled model, and an overclocked factory BIOS can all have different normal steady-state spreads.
The card-specific reference profile is therefore more defensible than comparing every owner against a community rule of thumb. An RX 7900 XTX should be compared to its own established behavior, as should an RX 9070 or RX 9070 XT. The usefulness of that baseline depends on it being created under enough stable, representative sessions to capture normal variation.
The published description gives no minimum learning duration, sample count, workload requirement, data-retention detail, or board-partner compatibility list. It also says sensor availability varies by card, BIOS, and driver. Those omissions do not make the tool invalid, but they mean a “supported RX 7000/RX 9000” label should not be mistaken for a guarantee that every card exposes every metric or that every installation will produce an equally strong comparison history.

User-mode operation lowers deployment friction, not diagnostic uncertainty​

TIMBER 4.19 runs in User Mode and, according to Igor’sLAB, installs no additional kernel driver. For Windows enthusiasts and managed environments wary of another privileged hardware-monitoring component, that is a practical advantage. The tool can consume Radeon telemetry through AMD’s exposed interfaces without asking users to accept a new kernel-level dependency.
It does not, however, mean TIMBER is independent of AMD’s driver behavior. The sensor coverage, labels, and availability still depend on the card, its VBIOS, and the installed Adrenalin stack. AMD’s own guidance notes that available controls and metrics can vary with system configuration, and that GPU Hotspot Temperature is available on Radeon VII and Radeon RX 5000-series-and-newer products. TIMBER’s RX 7000 and RX 9000 focus is a current-generation support boundary, not evidence that the underlying telemetry began there.
For Radeon owners, the immediate outcome is a better reason to keep logs than a one-time benchmark screenshot. TIMBER 4.19 can make a repeatable change in a card’s cooling behavior visible over weeks or months, provided its reference conditions remain comparable and its power-source data stays consistent. If the Hotspot-to-Edge spread keeps widening at the same approximate board power, fan setting, workload phase, and ambient conditions, that is the point to investigate the cooler—not when a single junction-temperature number happens to look alarming.

References​

  1. Primary source: igor´sLAB
    Published: 2026-08-02T03:30:57+00:00
  2. Related coverage: amd.com
  3. Related coverage: amd.com
  4. Related coverage: drivers.amd.com
  5. Related coverage: tomshardware.com
  6. Related coverage: tomshardware.com