Intel's Experimental Xe Driver For Linux Lacking HuC Media Support For DG2/Alchenist

[pioto]

This is indeed a disappointment and a kind of big deal indeed. AV1 encode also did not make it into the OBS and alike as of yet. Another issue on Arc is the lspci speed reporting: https://community.intel.com/t5/Graph...x1/m-p/1455448. Otherwise the card runs pretty decent.

I am not a gamer, so maybe my use-case is different. I had an AMD RX 6600 XT, for the very reason of open source drivers. After less than a year I swapped it for Arc A770 (50£ I had to add to the deal). My impression is that GPGPU (OpenCL but also ML workloads: pytorch) run way better on Intel than AMD. In order to get OpenCL driver on AMD I always had to deal with docker images, otherwise Mesa drivers would be messed up (maybe I wasn't skilled enough). Also ROCm would just not run reliably on RX 6600 XT (not officially supported, required some extra ENV var overloads). How is it possible that software which is marketed by AMD to run cross-platform does not run reliably on many (most) graphics cards made by AMD themselves. On Arc, after 30 minutes I had stable diffusion (https://huggingface.co/nitrosocke/mo-di-diffusion) running and doing 7it/s (beating Nvidia RTX 3080 doing 6it/s, which was a surprise).

I am just not sure that AMD open source drivers (in general sense, not only gaming) are better than Intel. And that is the impression I am getting from this thread.

[qarium]

This is for all the geniuses who insist everyone should "vote with their feet" and buy Intel GPU's in order to save the discrete GPU market. I mean, yeah, the GPU market hasn't been in a worse state than the last few years, but at the end of the day I want a properly working product and not unexpectedly being bitten in the ass because of being an early adopter.

right... many people here at phoronix.com told me a million times that in the opensource field intel GPUs are the new Gold.

then i bought a intel arc a380 for my mothers pc and for like 6 months nothing worked in fedora 37 ... not in fedora 38 the 4K resolution works but of course they rip of their customers.

i only bought intel because the AMD options did not have AV1 decode radeon 6400/6500

i really don't get it all the intel fanboys who are now ripped of why they defent this shit company ?

yeah i get it intel did lose a lot of money this quarder finance numbers show and they need to cut costs

but why they cut cost at the newest productline ??? and why they burn their freshly new customers ?

[Quackdoc]

right... many people here at phoronix.com told me a million times that in the opensource field intel GPUs are the new Gold.

then i bought a intel arc a380 for my mothers pc and for like 6 months nothing worked in fedora 37 ... not in fedora 38 the 4K resolution works but of course they rip of their customers.

i only bought intel because the AMD options did not have AV1 decode radeon 6400/6500

i really don't get it all the intel fanboys who are now ripped of why they defent this shit company ?

yeah i get it intel did lose a lot of money this quarder finance numbers show and they need to cut costs

but why they cut cost at the newest productline ??? and why they burn their freshly new customers ?

dont blame intel for your shitty distro's issues.

ubuntu rhel and sles had decent day one support. Arch wasn't bad, but the media driver didn't work out of box on kernel so another user and I were figuring out how to get it going, cheers to kkartaltepe for the patched ubuntu kernel pkgbuild. DG2 has honestly had quite good support, things have obviously been rocky, but running linux drm tip and mesa-git, I often find noticable improvements.

the only major gripe I have now is this specifc issue, which it's not too late for them to walk back on. one of the devs in the repo seemingly didn't understand the importance of VM_BIND and is going back to investigate it. I don't care which kernel driver it is so long as it's the complete package. assuming they find VM_BIND to indeed be necessary, I am still willing to put faith that either HUC will be added to XE, or VM_BIND to i915. which ever is the least effort and intrusive.

[Sonadow]

So just use i915 where there's HuC support for the DG2.

I don't see what the fucking problem is.

[Quackdoc]

So just use i915 where there's HuC support for the DG2.

I don't see what the fucking problem is.

because i915 won't be getting VM_BIND (possibly sometime in the distant future) which is necessary for sparse residency, which is needed for some emulators I think, but more importantly a growing dependency of vkd3d-proton. so this is actually a rather large problem considering the growing reliance of vkd3d-proton for modern games. you will have to swap kernel drivers, and as it stands, you cannot even unbind from i915 live, so it needs a reboot

[Sonadow]

because i915 won't be getting VM_BIND (possibly sometime in the distant future) which is necessary for sparse residency, which is needed for some emulators I think, but more importantly a growing dependency of vkd3d-proton. so this is actually a rather large problem considering the growing reliance of vkd3d-proton for modern games. you will have to swap kernel drivers, and as it stands, you cannot even unbind from i915 live, so it needs a reboot

And how much of your life will a reboot require?

5 minutes, tops.

Add separate entries to Grub2 to load the kernel with Xe or i915.

Play games and do normal computing stuff in Xe. Reboot to i915 when doing video encode.

Or do it the other way. Stay in i915 for everything. Reboot to Xe for gaming.

[Quackdoc]

And how much of your life will a reboot require?

5 minutes, tops.

Add separate entries to Grub2 to load the kernel with Xe or i915.

Play games and do normal computing stuff in Xe. Reboot to i915 when doing video encode.

Or do it the other way. Stay in i915 for everything. Reboot to Xe for gaming.

yeah the issue is doing both at the same time, HUC is needed for h264/265 encoding at the very least. maybe for AV1 too but I am hearing reports that it isn't needed for that. both at the same time is not uncommon, HEVC hwencode is still going to be what most people use for high fidelity recording of gameplay (either for content creators or people who like to have instant replay, I myself am the latter).

this is also important for something like sunshine+moonlight game streaming, which is actually a daily use of mine. and for people who want to bounce back and forth between encoding and gaming, etc.

there are a LOT of use cases that are broken by this (discord screensharing is another common and broken usecase). just because yours isn't doesn't mean that other people's aren't. this is a significant problem for myself and plenty of other people

[abott]

Lol, rebooting? Fuck off, my time is more valuable than that.

Also, looking at the HuC code in the kernel. It's 4 files and a few hundred lines. Is that all that needs ported? Obviously there's details in the notes, and the new driver will work different in general. But wouldn't understanding the function of the uC portion be enough to port it? It seems pretty damn trivial, it has minimal reference not shared with the generic GuC portions of the code. I definitely wouldn't release it since I don't really know their hardware/changes/etc/use, however I'd definitely fuck around with making it work for myself if it's only what I was seeing in the kernel with those 4 files in the uC portion.

Like, feature parity should totally be the first worry. Losing hardware features? I paid for those things, literally for the nice AV codec options. Holy hell.

[Sonadow]

Lol, rebooting? Fuck off, my time is more valuable than that.

Also, looking at the HuC code in the kernel. It's 4 files and a few hundred lines. Is that all that needs ported? Obviously there's details in the notes, and the new driver will work different in general. But wouldn't understanding the function of the uC portion be enough to port it? It seems pretty damn trivial, it has minimal reference not shared with the generic GuC portions of the code. I definitely wouldn't release it since I don't really know their hardware/changes/etc/use, however I'd definitely fuck around with making it work for myself if it's only what I was seeing in the kernel with those 4 files in the uC portion.

Like, feature parity should totally be the first worry. Losing hardware features? I paid for those things, literally for the nice AV codec options. Holy hell.

You paid for a card that was released for the fucking i915 driver.

And anybody who is not paid $10000 an hour has no excuse talking about how they cannot take 5 minutes out of their lives to reboot a computer.

[Sonadow]

HEVC hwencode is still going to be what most people use for high fidelity recording of gameplay (either for content creators or people who like to have instant replay, I myself am the latter).

this is also important for something like sunshine+moonlight game streaming, which is actually a daily use of mine. and for people who want to bounce back and forth between encoding and gaming, etc.

there are a LOT of use cases that are broken by this (discord screensharing is another common and broken usecase). just because yours isn't doesn't mean that other people's aren't. this is a significant problem for myself and plenty of other people

h264_vaapi

Problem solved.