Intel Linux Graphics Driver To Finally Expose GPU Package Temperature

[phoronix]

Phoronix: Intel Linux Graphics Driver To Finally Expose GPU Package Temperature

With the upcoming Linux 6.12 kernel the Intel graphics driver will finally be able to report GPU fan speeds. Another long sought feature is also on the way for this open-source Linux driver: GPU package temperature reporting for Intel discrete GPUs...

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

[jojo7887]

First the fan speed, now this. I had no idea these features were still missing in Linux. Really want to like Intel GPU's, in time they can be a nice open source alternative to AMD but it looks like it's gonna take a few more years before they can be deemed worth buying.

[Ferrum Master]

First the fan speed, now this. I had no idea these features were still missing in Linux. Really want to like Intel GPU's, in time they can be a nice open source alternative to AMD but it looks like it's gonna take a few more years before they can be deemed worth buying.

I have a strong feeling the Intel GPU division will be disbanded in few years sooner than this happens.

[pWe00Iri3e7Z9lHOX2Qx]

I have a strong feeling the Intel GPU division will be disbanded in few years sooner than this happens.

There's a bazillion dollars to be made from enterprise GPU compute. While a desire to save money and kill off the consumer dGPU line may happen, it could be saved by their interest in enterprise space. Intel is doing good stuff with their GPU compute frameworks / APIs. I hope they stay to compete in both. The current dGPU duopoly is bad for us.

[pong]

I have a strong feeling the Intel GPU division will be disbanded in few years sooner than this happens.

I'm waiting for the day pretty much all companies disband their GPU divisions.

To be clear, graphics / video / image SPECIFIC processing does still have some use cases for "dedicated" HW acceleration
blocks, possibly enough that it reasonably mandates being on a separate IC depending on the use case (video codec, ray tracing, whatever). And video (HW) interfaces DP/HDMI/MIPI/whatever still need physical support though those are simple & small enough even mobile phone SOCs tend to have those integrated in the main SOC as a block / peripheral so in many cases this and some other (e.g. video codec) functions can be "on chip peripherals" and not "distinct chips / cards".

Otherwise? For parallel / SIMD compute -- that's a core CAPABILITY of a computing system affecting key functionality of processing use cases including multi-processing / multi-threading / vector processing that's legitimately as much or sometimes more the concern of the "CPU" than a "GPU". Similarly for high bandwidth memory access whether VRAM, DRAM, HBM, that's also a core SYSTEM capability and should benefit the whole core system architecture not be
an isolated island on a GPU card, the CPU and core processing / memory / I/O fabric should benefit from high bandwidth memory access to the level needed to support whatever compute / graphics / HPC / IO the system needs to do.

AI/ML? Again it's really most often a core system level capability at this point requiring whatever level of vector / tensor processing ALU capability, whatever level of memory bandwidth, whatever level of multi-threading / processing. And in many cases these "compute oriented" capabilities should just be "in the CPU" not off on the isolated island of a GPU.

To the extent that ML processing requirements are SO HEAVY or so task-specific for a given system that specific acceleration is needed then whatever consider a NPU if it makes sense but so far since "ordinary" GPUs are mostly solving
this problem for client / edge / server / data center purposes and these GPUs are solving the matrix / vector / tensor
processing using only "ordinary" ALU/FPU/integer/mixed-precision compute & fast memory highly parallel computations
then arguably that stuff is just "foundational" FLOPS / IOPS / TOPS HPC stuff and should be handled along with the
normal compute stuff.

Reluctance to evolve x86-64 computing architecture to embrace better SIMD / HPC / parallelism and higher BW RAM access for most systems has hobbled the architecture from the laptop to the desktop to the server side for decades now and largely has enabled the fertile breeding grounds for discrete GPUs to act as essentially modern day "FPUs" to accommodate a level of processing & memory BW intel / amd didn't deign worthy to provide in the CPU / chipset and so was handled by
competitors using (architecturally most awkwardly!) add-on-cards. A current high end client/consumer desktop with the newest CPUs doesn't have nearly the memory BW or the vector processing capability of a ~15 year old "performance gamer" discrete GPU, and the highest end consumer/client CPU+IGPU combinations don't even reach near the level of
HPC or RAM BW capability of the very lowest end discrete GPUs from 3-4 generations ago e.g. 2060, 3060, etc.

And for ARM / RISC-V there's even less excuse since they're not limited by the tradition / mindset / architecture of decades old X86-64 systems if competing in the laptop / performance desktop / server space.

Meanwhile the GPUs have been miserable at providing the basic cross-platform / portable / open source / open architecture / administer-able / secure / multi-user / virtualizable capabilities we expect from CPUs, NICs, and generally most core system compute components & peripherals these days.

So yeah let's see LLVM / GCC etc. handle the toolchains, let's boost memory BW / tensor / SIMD compute in the system core, set up architectures where we can have locally distributed computing that scales and works mechanically / electrically / architecturally across multi-processor modular high performance systems and stop letting the "GPU is the new CPU" be some awkward frankenstein parasitism of a giant GPU awkwardly globbed on top of a motherboard that doesn't even meaningfully integrate its functions.

[pong]

On the one hand I appreciate the years-late work to FINALLY improve sensor monitoring under LINUX and also some of the things that improved (I hope it gets better / stable) the near idle energy management somewhat.

We STILL can't even update non-volatile firmware under LINUX for these cards.

"minimum viable product" parity really suggests that the RIGHT thing to do ethically would be to provide a full fwupd FW update solution for LINUX and a IGCL + GPU control center like capability.

[Quackdoc]

it feels like Christmas, Firmware, Energy via sensors (xpumanager still being a pita to install) and overclocking are the major missing features right now

On the one hand I appreciate the years-late work to FINALLY improve sensor monitoring under LINUX and also some of the things that improved (I hope it gets better / stable) the near idle energy management somewhat.

We STILL can't even update non-volatile firmware under LINUX for these cards.

"minimum viable product" parity really suggests that the RIGHT thing to do ethically would be to provide a full fwupd FW update solution for LINUX and a IGCL + GPU control center like capability.

apparently it can be updated over fwupd, intel just isn't pushing updates to lvfs -_-

[pong]

First the fan speed, now this. I had no idea these features were still missing in Linux. Really want to like Intel GPU's, in time they can be a nice open source alternative to AMD but it looks like it's gonna take a few more years before they can be deemed worth buying.

Yeah none of the intel graphics control center for windows sensor monitoring & settings management corresponding stuff exists for LINUX CLI / GUI. And in their SW stack (at several different levels) you cannot allocate / use chunks of VRAM bigger than 4GBy on your shiny new 8GBy / 16GBy VRAM equipped GPU.

https://github.com/intel/intel-extension-for-pytorch/issues/325

It's just not "fully baked" in FW / SW support at the very least.

[Quackdoc]

I wonder if anyone has a pkgbuild for an i915-git dkms to load these earlier.

[pong]

it feels like Christmas, Firmware, Energy via sensors (xpumanager still being a pita to install) and overclocking are the major missing features right now
apparently it can be updated over fwupd, intel just isn't pushing updates to lvfs -_-

Yeah given that almost all talk / effort lately seems to have been focused on battlemage et. al. and that ARC is 2+ years old and the (IIRC) reported mass layoffs at intel I had been fearing we'd just NEVER get either the updates or the information to improve any of these things on ARC.

The near-idle / idle / low-load energy consumption improvements was my #1 day-in-day-out concern since it was pretty extreme and already
greatly improved on ms-win with no announcements of any change for LINUX as of some months ago, so it was quite a surprise / relief to see that.

I wasn't even aware there were several other classes of firmware that were not updated on LINUX until reading that 3rd party article detailing
the situation as well as the significantly important changes that FW updates have brought to windows users over the past 2 years but now
knowing it's a big deal I'm concerned to update it though worried about 3rd party vs. official upstreamed FW update images and not having it via fwupd.

I have to follow up and see if the compute regression / bug stuff has been fixed that was affecting arcs as of some months ago but if so then at least it'll be nice to work with that again. I'd started getting routine i915 driver crash logs and GUI loss as of some months ago so I hope that'll be better with a newer kernel soon when I get to updating & testing it again.

So if what's there is stable again now / ongoing for actual functionality then I'd say settings FW updates & control / management is probably my #1 "additional capability" desire since we've got nothing there now beyond the openrgb LED control AFAIK. Well that's not quite true, SR-IOV / virtualization / sharing that works would be a strong #1 for major capability but for routine quality of life & tweaking stuff control center stuff.

Also I think keeping the interest & advocacy up for ARC is important because it'll surely also affect what we can look forward to (or not) from battlemage, celestial, druid, etc. and intel still has a chance to be top tier wrt. FOSS support from the driver level up to the SW & utility levels if they would care enough to do so, exceeding even what NVIDIA & AMD offer in some important areas that wouldn't be hard for ANY of them to improve on but which are still sadly lacking. Settings / controls administration & monitoring SW is one big area for especially intel & amd to catch up on. Virtualization for all of them. FW updates of every kind also.