Intel Has Many Improvements For The Xe Graphics Driver In Linux 6.10

[phoronix]

Phoronix: Intel Has Many Improvements For The Xe Graphics Driver In Linux 6.10

Intel today sent out more than one hundred new feature patches to DRM-Next of new "Xe" kernel graphics driver material they have readied for the upcoming Linux 6.10 kernel merge window...

https://www.phoronix.com/news/Linux-6.10-Intel-Xe-DRM-Patches

[rene]

thanks cool and all. But will it finally be able to run Crysis?

[pong]

> "Similar to the i915 driver, via the HWMON sysfs the Xe driver can now expose the discrete graphics card power use and energy metrics."

That's entirely underwhelming.
I've got their Arcanist card and monitoring the power consumption is about the ONLY thing I've found that can be monitored / controlled and that's
2-years after the Arc released and apparently from the article they're just getting to parity with that pittance for Xe now?!

What about monitoring temperatures, clock speeds, fan RPMs, voltages?
What about CONTROLLING clock speeds, power limits, fan speeds?

I admire intel's OSS to the extent it exists vs. say nvidia, but 2+ years after intel has released DGPUs there's neither
documentation (AFAICT) nor API nor CLI nor GUI for even the most basic control & monitoring of the GPU sensors & operations for LINUX
while NVIDIA has had all that (nvidia-smi, nvidia-settings) for decades and also AMD wrt. utilities.

Intel's case is especially shameful since they have their own 'xpumanager' linux tool supported for their non-consumer GPUs but nothing for ARC / et. al.
Intel has their GPU control center GUI for MSW, for consumer gpus, nothing for LINUX.

Intel has the IGCL library / api for sensor monitoring & some operational controls for MS windows which they tout as being an open and utilitarian way to monitor
and control stuff as opposed to proprietary and closed ad-hoc interfaces, YET where is the implementation of that library / API in their OPEN SOURCE for LINUX?
Completely missing, no such interface.

What the hell, Intel, could you not be bothered to write 2-pages of API or hardware level documentation so SOMEONE can write a FOSS control / monitoring utility even if you won't bother to?

And could it REALLY be so hard to port YOUR OWN IGCL / xpumanager to work on your DGPU / IGPU LINUX consumer devices?

EDIT: And similarly true for the RGB LED control. Intel claims OSS is advantageous etc. and a better situation than nouveau having to reverse engineer the basic nvidia monitoring stuff, but if you're supporting OSS why the hell is "openrgb" reverse engineering your LED control USB interface just so your linux users can choose to control GPU LED settings that every single one of your MSW OS users can control with your own utility. Is the 2-pages of USB API too much to be bothered to document so SOMEONE can write correct support for your HW if you won't?

[cutterjohn]

more importantly will they finally support hw video encoding on the Xe driver?!

[EDIT]

Or is it still teh too hard?

[/EDIT]

[stygian]

more importantly will they finally support hw video encoding on the Xe driver?!

[EDIT]

Or is it still teh too hard?

[/EDIT]

It's always been supported? It's just only Alchemist cards won't have hw encode decode support in Xe driver.

Not sure why people got so hard on for trying to use experimental driver that is meant for next generation of gpus to be used on current generation. Intel has been pretty clear that Xe driver will always be experimental for alchemist cards

[rogerx]

Shrugs... just thankful I have a video card that just works under Linux, versus having to invest into nVidia game playing market anymore.

As far as fans, RPMS, power usage; I have never really needed the information or software utilities unless cooling failed due to insufficient cooling. Have yet experience having any problems with a graphics card (or CPU, memory, etc...) overheating for the past decade or more. Can only recall having overheating problems using a 20+ year old laptop, or when living near or within the desert during the Summer. As far as environmental overheating, likely best investing in substantial cooling methods. Regardless during overheating events, don't think seeing your temperature or fan RPMS will be very helpful, otherwise telling you are already overheating. Never was much of a fan over-clocking something outside OEM specifications. Can only imagine the hell manufacturers go through with returns and damage claims. In other words, a video card intended for business or computer development, while still being used for entertainment, probably can do without.

If it's so essential for seeing temperatures, usually needed when over-clocking, can always purchase a voltmeter with temperature monitoring capabilities and likely monitor temperatures far more accurately and consistently after things haphazardly expectedly freeze-up! I also believe there are RPM sensors, might be able to find something with a cheap laser for detecting fan RPMS. A lot of motherboards engineered for over-clockers, usually have digital readouts engineered for displaying after system freezes. Long story short, when over-clocking, use some additional tools. Otherwise, I keep things within OEM specifications. If I do operate outside of OEM specifications, I usually take on the risk and loss if I fail to think through something. Then again, not a day goes buy I'm pulling apart something, trying to fix without causing more damage or loss.

[Phoronos]

thanks cool and all. But will it finally be able to run Crysis?

Maybe in 20 years if things go well.

[cutterjohn]

It's always been supported? It's just only Alchemist cards won't have hw encode decode support in Xe driver.

Not sure why people got so hard on for trying to use experimental driver that is meant for next generation of gpus to be used on current generation. Intel has been pretty clear that Xe driver will always be experimental for alchemist cards

it is NOT supported by your own comment as well as Intel's it's teh too hard comments, so I do not understand your reply... IT DOES NOT WORK becuase it's teh too hard to support our own hw... BUT you can keep using i915 driver and have hw encoding...

Did I miss something that you seem to know? as AFAIK hw encoding will (maybe) only be supported for battlemage with Xe driver as apparently it's less teh hard....

you must remember these are comments wrt Intel devs whinging about about hw encoding being teh 'hard' whiich makes me go crosseyed... before firing them...

Ill remain hopeful that one of their more inventive devs finds at least a hack to enable hw encoding w/the Xe driver for alchemist, o.w. fuck Intel for being lazy!

[stygian]

it is NOT supported by your own comment as well as Intel's it's teh too hard comments, so I do not understand your reply... IT DOES NOT WORK becuase it's teh too hard to support our own hw... BUT you can keep using i915 driver and have hw encoding...

Did I miss something that you seem to know? as AFAIK hw encoding will (maybe) only be supported for battlemage with Xe driver as apparently it's less teh hard....

you must remember these are comments wrt Intel devs whinging about about hw encoding being teh 'hard' whiich makes me go crosseyed... before firing them...

Ill remain hopeful that one of their more inventive devs finds at least a hack to enable hw encoding w/the Xe driver for alchemist, o.w. fuck Intel for being lazy!

1) i915 is official driver for alchemist, why are you so hellbent on trying to use unofficial unsupported driver on alchemist cards?
2) I'm sure driver development is as easy as you say, that's why you have numerous contributions to i915 and Xe.
3) By HW encode decode being supported, I meant on the cards that have official Xe kmd support (basically latest iGPUs)
4) Learn to spell shit.

Edit: 5) I would TOTALLY like to have hacky support for HW encode and decode on a GPU that isn't officially supported for Xe driver. It's just one simple hack. We woudn't ever get a clusterfuck that is i915 by adding hacks ontop of hacks. But hey, if you like hacks on top of hacks, I heard AMD is always recruiting new driver developers.


Edit: To add, there is absolutely NO REASON to use Xe driver for alchemist. If you need VM_BIND just use the out of tree i915 driver.
https://dgpu-docs.intel.com/driver/k...ver-types.html Section 4.2 Or what magical feature do you need from Xe that is not in i915?