Linux 6.8 Features Excite With New Intel Xe Driver, Performance Optimizations & New Hardware

[phoronix]

Phoronix: Linux 6.8 Features Excite With New Intel Xe Driver, Performance Optimizations & New Hardware

While the Linux 6.8 kernel merge window has been over for several weeks now, due to a busy February of new hardware releases and lots of Linux hardware reviews/benchmarking, I've been behind in writing up my Linux 6.8 feature recap. For those wanting a concise look at the many great changes coming with Linux 6.8 that will debut as stable in March, here's an overview of the interesting Linux 6.8 changes.

https://www.phoronix.com/review/linux-68-features

[avis]

Michael

Could you please write about this any way you like/prefer?

Quite an interesting topic: https://gitlab.freedesktop.org/drm/amd/-/issues/3195

Thanks a lot!

[pong]

Does the current Xe driver as in the present 6.8 kernel enable any fixes for ARC for the lack of ASPM / lower power near-idle @ desktop / screen saver / monitor off scenarios which the i915 / ARC combination seemingly still fails to rectify? Does it support any interfaces for better ARC clock / fan / power / temperature control & monitoring than i915?

[skeevy420]

Michael

Could you please write about this any way you like/prefer?

Quite an interesting topic: https://gitlab.freedesktop.org/drm/amd/-/issues/3195

Thanks a lot!

I don't think there is much we can do in the driver to address this directly. Windows and android handle most of this in their compositors. To address this we need the following:

I've had this discussion before and, in my opinion, it's all comes down to Wayland needing plugin support. The reason it isn't a problem on Windows or Android is because there's only a single compositor to target. On Linux, however, there's a compositor protocol, Wayland, and more compositors adopting various levels of that protocol than I'm able to keep up with by memory.

Anyways, apparently* Wayland doesn't allow proprietary extensions and not everything AMD needs to do can be done open source**. That's compounded by the fact that even if Wayland did accept extensions from AMD for proprietary features, it would still be up to the Mutter, KWin, Sway/wlroots, etc devs to add the AMD proprietary extensions or for AMD to have a dev that did nothing but work on Linux compositors.

That's why, to me, the only real solution to that problem is for Wayland to adopt a plugin extension and then window managers need to support loading plugins. Assuming the WM devs implement the Wayland plugin extensions properly, any burden from issues caused by the plugins would be shifted on to the plugin creators.

*I say apparently because I can't find that no proprietary rule written down anywhere and it's just what I've been told. I didn't look hard to find that rule.

**That was stated to me in the context of complete feature parity between Windows and Linux. Proprietary and closed source may or may not be the case is the scope is limited to just video rendering.

[avis]

I've had this discussion before and, in my opinion, it's all comes down to Wayland needing plugin support. The reason it isn't a problem on Windows or Android is because there's only a single compositor to target. On Linux, however, there's a compositor protocol, Wayland, and more compositors adopting various levels of that protocol than I'm able to keep up with by memory.

Anyways, apparently* Wayland doesn't allow proprietary extensions and not everything AMD needs to do can be done open source**. That's compounded by the fact that even if Wayland did accept extensions from AMD for proprietary features, it would still be up to the Mutter, KWin, Sway/wlroots, etc devs to add the AMD proprietary extensions or for AMD to have a dev that did nothing but work on Linux compositors.

That's why, to me, the only real solution to that problem is for Wayland to adopt a plugin extension and then window managers need to support loading plugins. Assuming the WM devs implement the Wayland plugin extensions properly, any burden from issues caused by the plugins would be shifted on to the plugin creators.

*I say apparently because I can't find that no proprietary rule written down anywhere and it's just what I've been told. I didn't look hard to find that rule.

**That was stated to me in the context of complete feature parity between Windows and Linux. Proprietary and closed source may or may not be the case is the scope is limited to just video rendering.

This all looks like we need a single reference Wayland server, not a zoo of compositors where now you can even enjoy more/less power efficient implementations.

[skeevy420]

This all looks like we need a single reference Wayland server, not a zoo of compositors where now you can even enjoy more/less power efficient implementations.

I used to be in the "wlroots FTW" camp but the reality is that one size doesn't always fit all; that every project has different priorities. As much as it seems that one feature-complete compositor would be the best case scenario, that still doesn't handle closed source, proprietary, use-cases so a plugin system would still be necessary.

One solution can also lead to stagnation and Zoos of Projects can be what drives innovation. They allows different groups to try different approaches to achieve the same solution.

Jokingly, this all looks like we need a single reference operating system, not a zoo of operating systems where now you can even enjoy more/less power efficient implementations. We don't really need a choice between Windows, FreeBSD, Haiku, Umpteen Linux distros, or ..... since Windows ME will suffice.

[andyprough]

Michael

Could you please write about this any way you like/prefer?

Quite an interesting topic: https://gitlab.freedesktop.org/drm/amd/-/issues/3195

Thanks a lot!

This is COMPLETELY irrelavent to your questions on gitlab, avis, but your questions do bring to my mind this discussion on a Dasharo Coreboot developers docs page about the difference between working with Intel and AMD:

>"Why there is no AMD mainboard supported in Dasharo ?"

"Unfortunately, from the perspective of a small open-source firmware vendor, it isn't easy to work with AMD. Despite our experience with AMD SoCs since 2016, we could not yet deliver Dasharo for a modern (Zen core-based) platform. We're trying hard, but Intel has a better ecosystem for open-source firmware development.

"The reason for that state may be because AMD is in a rush, and they are understaffed in all areas compared to their success. We've been doing AMD open-source firmware development for 6+ years, including our yearly reports of open-source firmware status at FOSDEM, but the level of support for small volume firmware development companies is not yet at the level of competition.

"AGESA distribution was a problem in the past, but we solved that, and Dasharo for AMD is possible. Because Dynamic Root of Trust can work without blob, we favor AMD, but we can't do anything without a partner who can sponsor the development effort. We are on the market of open-source firmware vendors, not hardware vendors."

https://docs.dasharo.com/osf-trivia-list/dasharo/#why-there-is-no-amd-mainboard-supported-in-dasharo

[sunami88]

Does the current Xe driver as in the present 6.8 kernel enable any fixes for ARC for the lack of ASPM / lower power near-idle @ desktop / screen saver / monitor off scenarios which the i915 / ARC combination seemingly still fails to rectify?

I would love to know this too! Going from a bottom-tier NVIDIA card that drew 7w at idle my a750 is frankly obscene at ~65w*. I'm fortunate to say I can afford it but it's pretty egregious for idle.


* Estimation based on what my UPS tells me. It's possible I've misconfigured something but I've googled this several times, and coupled with comments from Intel themselves, it seems this is a well known problem. Mobo is an X670 AORUS ELITE AX 1.0 .

[anda_skoa]

*I say apparently because I can't find that no proprietary rule written down anywhere and it's just what I've been told. I didn't look hard to find that rule.

That would be extremely surprising.

Essentially every new protocol is proprietary until it sees its first release and it is unlikely that anyone releases even a draft before having tired to implement it themselves.

I have also seen several embedded projects that used the Qt Wayland compositor to create a custom implementation and some did use proprietary protocols for extended client/compositor communication.

So what we could rather say is that proprietary is possible but not very useful outside that closed proprietary context.
If it is intended to be used in a wider ecosystem it needs to be available to other actors in that group

[mrg666]

Michael

Could you please write about this any way you like/prefer?

Quite an interesting topic: https://gitlab.freedesktop.org/drm/amd/-/issues/3195

Thanks a lot!

I don't think 13W vs. 3.5W is anything important. I have both Intel and AMD CPUs that go past 200w. There are such big differences in the architecture, power scaling methods etc. between the two CPUs as well. And, there is someone trying to exaggerate by using words "outrageous", "hugely", terribly", I can't trust those numbers are accurate. Meh, just wasted time reading that.