Intel Graphics Driver With Linux 6.12 Will Finally Report Fan Speeds

[phoronix]

Phoronix: Intel Graphics Driver With Linux 6.12 Will Finally Report Fan Speeds

Intel has submitted more kernel graphics driver changes for the upcoming Linux 6.12 cycle. Following the pull requests to DRM-Next last week to enable Lunar Lake Xe2 graphics and Battlemage by default, some more lingering feature patches were merged today. Most exciting with this last round of patches before Linux 6.12? Intel graphics card fan speed reporting is finally wired up for their Linux driver...

https://www.phoronix.com/news/Intel-GPU-Fan-Speed-Linux

[davidbepo]

https://i.giphy.com/media/v1.Y2lkPTc5MGI3NjExYnFpMnVlcnYzd29kZjAxaWVjbWM4M25xeGN2aWJrcDZnbjlmaG9iYiZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9dg/CvHALswPAA34FjihPs/giphy-downsized-large.gif

[Quackdoc]

now we need over and underclocking support

[emansom]

AND LET THE USERS CHANGE IT!!!!!!!!

Don't want my transcoding server to be blasting 51dB all the time.

[Jumbotron]

The delay probably comes from the fact that Intel is now doing worse under Pat Gelsinger than the CEO he replaced. Stock is down 60% to a level not seen since the 1970’’s….yeah…50 years. Market cap is below $100 billion which means they may be delisted from the Dow Jones. They just fired something like 16,000 people. Their 5nm process called 20A has been abandoned for even their own purposes and the industry is rejecting 18A 5nm+ even as we speak. Now word comes that Intel may sell off most of their MobilEye self driving division. Pat supposedly is presenting a rescue plan come the middle of this month.

Don’t invest in Intel. Invest in popcorn. Gonna be interesting.

https://www.zerohedge.com/markets/mobileye-hits-record-low-report-intel-may-offload-partial-stake-public-market

[emansom]

...

Don’t invest in Intel. Invest in popcorn. Gonna be interesting.

...

Or do. Long term it's gonna be fine, the real engineering happens at ASML anyway.

But yeah, don't expect crazy returns.

[Jumbotron]

I’m not so sure about Intel, actually . I made a prediction two years ago here that by 2030 50% of all PCs shipped ( I include Macs in that figure ) would be ARM based. When I say PCs I mean anything not handheld. So laptops and desktops, NUCs and Pi’s. Coupled that with phones, tablets, watches and IoT where does Intel fit in there other than big iron, HPC and servers? They can’t make competitive, cost effective CPUs. They can’t make even competitive GPUs. And their foundries have been having major process issues for 10 years.

Now on top of rumors that they may have to sell the foundry business after touting it so heavy and taking billions of subsidies and direct taxpayer dollars in the CHIPS Act and the rumors of them selling Mobileye, now comes rumors ARM itself may buy Intel’s PC Client design division. In the words of the Steve Austin at the beginning of “The Six Million Dollar Man”….” She’s Breaking Up, She’s Breaking Up !!”

https://www.theregister.com/2024/09/06/qualcomm_intel_rumors/

[pong]

Intel made linux a "supported platform" for their consumer level DGPUs but it's a cruel joke to call it that since 2 years after the ARC / Alchemist launch we still can't:

* fully update the card firmware; a third party DIY work-around workflow is the only present hope for that BASIC thing, and there have been several IMPORTANT volatile FW updates wrt. card functionality / performance / display functions.
(Remember to) Update your Intel Arc Firmware on Linux! - GPU - Level1Techs Forums

* monitor most sensors e.g. temperature, voltage, clocks at all; monitor ANY sensors via any supported / provided API / CLI / GUI.
Windows users get an advanced control center app and API / SDK to do these, LINUX gets nothing at all, not even the HW / register documentation or driver APIs or a library for FOSS DIY applications / kernel modules to use to write such things independent of intel.
The "fan speed monitoring" patch boils down to (surprise!) reading one MMIO register and scaling the value. If they're so backlogged to implement a couple dozen lines of driver patch to expose it to HWMON, why not AT LEAST publish a 1 page list of the fan / temperature / clock / voltage related sensor register properties and at least enable OSS developers to read the values and expose them to OSS sensor monitoring tools?
Intel themselves defined a cross-platform capable SDK/API based interface for GPU monitoring & management here, but the
cruel joke is that there's no LINUX back-end (i915, xe, library, ...) code to IMPLEMENT their OWN API back end functions so it's
useless. What cognitive dissonance to bother to create a portable API for "how this should work" and not even implement it on
all their DGPU supported platforms.

https://intel.github.io/drivers.gpu.control-library/

* Worse than the sensor / hardware monitoring there's no ability to control any of these for LINUX whereas there's the aforementioned GUI and API controls available on windows for clocks, fan speeds, display settings, etc.

* Control the card LEDs on even their own DGPU card models via the USB port they created for this purpose. After all the open source or at least linux supported USB drivers intel has made over the decades how could they not even provide the basic ability to turn the lights on / off for LINUX for their flagship consumer DGPUs? Again there's zero hardware / protocol documentation published about how to even DIY it in OSS and only an independent OSS project openrgb with no apparent assistance whatever from intel has offered any hope of even this basic control capability.

How even the most basic non-volatile firmware updating or sensor / setting monitoring & control to match even their OWN "standard library API" capability didn't make it on to the "minimum viable product" list for a "supported platform" is entirely mysterious.
Even 6 pages of open documentation or "gist" sample code could have been enough to enable the OSS community to fill in the gaps here but effectively they've been linux / oss hostile worse than NVIDIA / AMD in these basic respects which is incredibly dissonant with common sense since why otherwise open the "graphics related" driver code but fail so miserably at the foundational control / monitoring / administration / update side of things that's essential but also very simple in comparison?

So now 2 years after ARC launched and we're even less likely to get any of these updates as opposed to entirely incidental to what battlemage / celestial might get and it's more and more likely just going to be a half-baked abandoned DGPU generation that could and should have been much better supported in these ways at launch.

It reinforces my conclusion that DGPUs should largely just "die" and the compute / parallelism / memory bandwidth be implemented in the core "CPU" / "system" architecture so at least then we'll more likely have cross-platform first class toolchains / documentation etc. to enable full use of the core compute and administration capabilities and if there are graphic specific things (ray tracing, video codec, ...) things that somehow need disjoint engines we can at least hope for OSS libraries / code for those.

[Quackdoc]

Intel made linux a "supported platform" for their consumer level DGPUs but it's a cruel joke to call it that since 2 years after the ARC / Alchemist launch we still can't:

* fully update the card firmware; a third party DIY work-around workflow is the only present hope for that BASIC thing, and there have been several IMPORTANT volatile FW updates wrt. card functionality / performance / display functions.
(Remember to) Update your Intel Arc Firmware on Linux! - GPU - Level1Techs Forums

This is really annoying, why can't they just update it over fwupd? hughsie do you know if there was any work trying to enable stuff like this, or if intel has shown any willingness to play ball?

* monitor most sensors e.g. temperature, voltage, clocks at all; monitor ANY sensors via any supported / provided API / CLI / GUI.

we actually can measure clock speed, voltage/wattage, engine usage, memory usage via xpumanager, but it's been a massive pita to get working on arch so I just gave up, There was a script that monitored energy usage too, but it was reporting that my A380 has a power limit of 55w and a usage of 100w while im gaming, so i'm, not sure what's going on here, but it's fucky.

* Control the card LEDs on even their own DGPU card models via the USB port they created for this purpose. After all the open source or at least linux supported USB drivers intel has made over the decades how could they not even provide the basic ability to turn the lights on / off for LINUX for their flagship consumer DGPUs? Again there's zero hardware / protocol documentation published about how to even DIY it in OSS and only an independent OSS project openrgb with no apparent assistance whatever from intel has offered any hope of even this basic control capability.

Aren't some arc cards controllable via openRGB? honestly I don't blame intel for this one. It would be nice, but i can understand why it wouldn't be a priority, especially if different cards have different implementations which I could see happening.

How even the most basic non-volatile firmware updating or sensor / setting monitoring & control to match even their OWN "standard library API" capability didn't make it on to the "minimum viable product" list for a "supported platform" is entirely mysterious.
Even 6 pages of open documentation or "gist" sample code could have been enough to enable the OSS community to fill in the gaps here but effectively they've been linux / oss hostile worse than NVIDIA / AMD in these basic respects which is incredibly dissonant with common sense since why otherwise open the "graphics related" driver code but fail so miserably at the foundational control / monitoring / administration / update side of things that's essential but also very simple in comparison?

So now 2 years after ARC launched and we're even less likely to get any of these updates as opposed to entirely incidental to what battlemage / celestial might get and it's more and more likely just going to be a half-baked abandoned DGPU generation that could and should have been much better supported in these ways at launch.

It reinforces my conclusion that DGPUs should largely just "die" and the compute / parallelism / memory bandwidth be implemented in the core "CPU" / "system" architecture so at least then we'll more likely have cross-platform first class toolchains / documentation etc. to enable full use of the core compute and administration capabilities and if there are graphic specific things (ray tracing, video codec, ...) things that somehow need disjoint engines we can at least hope for OSS libraries / code for those.

I'm overall pretty conflicted on the matter, on one hand, actually daily use of it has been fine, I run mesa-git and the latest stable, occasionally I hit regressions, but the intel devs working on mesa address them fairly quickly, and my performance is... decent, as decent as I could expect having the card run in an x8 slot on my ryzen 2600, with 4g decoding enabled if that matters at all, which im not sure it does.

on the other hand, I really want to be able to OC my card, I know there is performance left on the table, and the fans don't even get that loud when i'm gaming. I really wish they didn't backburner DG2 so hard especially in terms of intel XE as the XE driver will pretty much forever be "not really usable" on DG2 because of the huc/guc stuff.

I guess, I'm happy with the progress the device has made. I have zero issues using it as the primary/single GPU aside from one game (ghosts of tsushima). so it's not too major of an issue anyways, (radeon has broke graphics in that game anyways last I checked.)

[pong]

This is really annoying, why can't they just update it over fwupd? hughsie do you know if there was any work trying to enable stuff like this, or if intel has shown any willingness to play ball?


we actually can measure clock speed, voltage/wattage, engine usage, memory usage via xpumanager, but it's been a massive pita to get working on arch so I just gave up, There was a script that monitored energy usage too, but it was reporting that my A380 has a power limit of 55w and a usage of 100w while im gaming, so i'm, not sure what's going on here, but it's fucky.



Aren't some arc cards controllable via openRGB? honestly I don't blame intel for this one. It would be nice, but i can understand why it wouldn't be a priority, especially if different cards have different implementations which I could see happening.



I'm overall pretty conflicted on the matter, on one hand, actually daily use of it has been fine, I run mesa-git and the latest stable, occasionally I hit regressions, but the intel devs working on mesa address them fairly quickly, and my performance is... decent, as decent as I could expect having the card run in an x8 slot on my ryzen 2600, with 4g decoding enabled if that matters at all, which im not sure it does.

on the other hand, I really want to be able to OC my card, I know there is performance left on the table, and the fans don't even get that loud when i'm gaming. I really wish they didn't backburner DG2 so hard especially in terms of intel XE as the XE driver will pretty much forever be "not really usable" on DG2 because of the huc/guc stuff.

I guess, I'm happy with the progress the device has made. I have zero issues using it as the primary/single GPU aside from one game (ghosts of tsushima). so it's not too major of an issue anyways, (radeon has broke graphics in that game anyways last I checked.)

Yes I see what you mean and where you're coming from. I'm conflicted too in that, well, I took a risk buying into the DG generation of cards
thinking "how bad can it be, i915 is already open source, intel has been less OSS hostile than nvidia / amd over the past years, and if it works like a solidly reliable / much faster / more capable intel IGPU with i915 / oneapi / sycl / opencl and has the equivalent of nvidia-settings / nvidia-smi to monitor & manage the card, it'll be a win in my book". So that was my theory and it came close but it's like they ran a marathon getting their IGPU level FOSS working and almost entirely dropped the ball on the "discrete specific" documentation / utilities / administration / monitoring stuff not so common to IGPUs like FW updates, sensors, energy & performance management, etc.

So OTOH it is nice to have basic graphics capability and a opencl / sycl / oneapi capable platform to work with, but then things like seeing them
sit there 24 hours a day consuming 41W at MINIMUM, a factor of 3-4x higher than many competitive DGPUs at near idle / low performance mode and avoidably in the sense that they COULD fix it in SW/FW but just didn't care to do so for ~2 years was galling. Seeing fans running
constantly while the card was idle and cool with no way to turn them off / control them vexing (after all it's likely these WILL be a failure point
for these cards after a few years of spinning and they certainly didn't design them to be maintainable) since just running a GUI desktop or when the monitor itself is in sleep mode the cards SHOULD be able to run on like under 8-10W and 0 RPM fan speed.

I'd forgive them (at least for a time) for not writing a fancy GUI LED control native QT/whatever app and even not for having a similar fancy fan / performance control GUI. But at the very least there should be a shell usable CLI / TUI along the lines of nvidia-smi or intel's own xpumanager for the enterprise GPUs etc. And FW updates should have been supported at and continually after launch.

It's kind of strange to me though that any major (or minor) company would in this day and age not have a standard practice of just writing
cross-platform portable control / monitoring UI utilities. It's so easy to write things with either browser / web engine UIs or use portable-enough stuff like flutter, electron, qt, ... that the UIs could well have run on linux and windows and all they'd need is an API bridge to talk to the
API level interface by which it worked for 98% of the required functionality, assuming they could be bothered to expose things to the point
of their own HAL IGCL API or whatever.

And beyond all that even if they were bound and determined to treat linux as a 4th class citizen for support, I can conceive no sane reason they
wouldn't have at least DOCUMENTED the ways to achieve the monitoring & management stuff so OSS developers could implement it into
lmsensors, and whatever other UIs / CLI tools we wanted since 2022. I'd have personally written such by now had I had the HW / protocol / API documentation sufficient for the purposes (sensors, ...). They obviously have the code for windows for all the control / utility stuff, even if
they just open sourced snippets of that it'd have been good enough to enable much more than the almost zero LINUX tools we have now for
ARC. NVIDIA & AMD GPUs have better DGPU control & monitoring tools on LINUX now than Intel.

As for fwupd -- yes exactly -- why they wouldn't just PUBLISH the firmware files and version change log and then either support fwupd or at least
facilitate 3rd party OSS tools to do it and at least it'd be a "bare minimum pass" as opposed to a "what the hell, intel?!" situation.

A few months ago (around 6.5-6.6) the power management (in near idle / idle mode at least) seemed to improve in my experience so hopefully that gets
rock solid / stable long term. Though shortly after that they (i915 kernel bugs) broke the compute functions for much of the 6.5-onward kernels until 6.9.x where they fixed some of the regressions so it has been hard to assess how stable it has been "lately" with the i915 bugs / regressions.

I agree they really shouldn't have backburnered the DG2 wrt. xe but just fully supported it along with battlemage and then called it sustaining / EOL for DG2 after it was feature complete & stable with their nominal "current" xe driver if not also i915.

Thanks for mentioning the xpumanager monitoring stuff. I looked into that concept quite a long while ago and never saw that there seemed to be any way to get it to be useful on ARC but apparently as you said someone has managed to do something with it so I'll revisit it.

As for monitoring IIRC the best / most interesting thing I had run across is this script:

https://github.com/Disty0/intel-arc-monitor/blob/main/intel-arc-monitor

and I wrote one that used hwmon just for the energy use alone but I haven't looked in details about how well it tracked in high performance
use cases, I was mostly concerned with trying to minimize power when the GPU wasn't working hard.