Intel Comes Up With A Way For Vulkan Sparse Support On Their Existing Linux Driver

[phoronix]

Phoronix: Intel Comes Up With A Way For Vulkan Sparse Support On Their Existing Linux Driver

The biggest hindrance for using Intel Arc Graphics for Linux gaming has been the lack of Vulkan sparse support as needed for running many newer Windows DirectX 12 games atop Valve's Steam Play with Proton using VKD3D-Proton. Intel recently did implement Vulkan sparse support for ANV in Mesa 23.3 but it only works with their yet-to-be-upstreamed and still-experimental Xe kernel driver. But now Intel Linux graphics driver engineers have managed to pull off a solution for getting the sparse resources supported while using the existing i915 kernel DRM driver...

https://www.phoronix.com/news/Intel-Vukan-Sparse-TR-TT

[Quackdoc]

ah yes, seems *very* abandoned. laughing at haters aside, really glad to see this and I cant wait to benchmark it, if it becomes a thing where loading xe will simply give a preformance bump, thats still fine with me.

[RejectModernity]

will simply give a preformance bump

What? People literally buy new hardware for performance bumps.

[Quackdoc]

What? People literally buy new hardware for performance bumps.

and? anyone who bought into DG2 thinking that it was going to be a card you could slot in and compete against Nvidia and AMD in everything, is at the height of idiocy, the fact that we are managing to get a fully featured card at all is beyond expectations for me, the fact that they are preforming so well for the price point blows me away.

I've already said that personally, my biggest gripe with DG2 was/is the fractured nature that it was going to take in linux, this is now being solved as we will be able to have the full package. if swapping a kernel module will give me a performance bump, that is still a win for me.

[RejectModernity]

and? anyone who bought into DG2 thinking that it was going to be a card you could slot in and compete against Nvidia and AMD in everything, is at the height of idiocy, the fact that we are managing to get a fully featured card at all is beyond expectations for me, the fact that they are preforming so well for the price point blows me away.

I've already said that personally, my biggest gripe with DG2 was/is the fractured nature that it was going to take in linux, this is now being solved as we will be able to have the full package. if swapping a kernel module will give me a performance bump, that is still a win for me.

Temporarily sure, we can stay on i915, but long term I prefer getting proper support for HuC in Xe which also helps in long term support. Also, only Xe has proper support for architectures other than x86 and well, you can't choose working huc on arm.

[Quackdoc]

Temporarily sure, we can stay on i915, but long term I prefer getting proper support for HuC in Xe which also helps in long term support. Also, only Xe has proper support for architectures other than x86 and well, you can't choose working huc on arm.

ofc I prefer it too, however for me it's not something important let alone critical, realistically speaking the huc loading code might require refactoring and adding a code path intel doesn't want to support, I wouldn't be surprised if when xe lands in stable if someone would make a dkms for it.

[darkbasic]

ah yes, seems *very* abandoned. laughing at haters aside, really glad to see this and I cant wait to benchmark it, if it becomes a thing where loading xe will simply give a preformance bump, thats still fine with me.

Unfortunately Arc is and will forever remain a paperweight for me, because i915 doesn't have plans for architectures other than x86 and Xe doesn't have plans for supporting its media engine.

[nyanmisaka]

Better than nothing. On the other hand I hope their plans for Xe1 HuC are just low priority rather than abandoning it completely.

[X_m7]

Better than nothing. On the other hand I hope their plans for Xe1 HuC are just low priority rather than abandoning it completely.

Surely if it was actually "low priority" they'd have just come out and said it instead of saying "no plans", talking about how the code would only be useful for DG2 and absolutely nothing else so it's not worth doing, and telling people to just use i915 since they'll still support it as best they can.

At this point it seems to me that the only way DG2 can have working HuC on Xe is if some outside contributor puts in the work, and that's of course assuming the maintainers are willing to accept said work at all.

[nyanmisaka]

Surely if it was actually "low priority" they'd have just come out and said it instead of saying "no plans", talking about how the code would only be useful for DG2 and absolutely nothing else so it's not worth doing, and telling people to just use i915 since they'll still support it as best they can.

At this point it seems to me that the only way DG2 can have working HuC on Xe is if some outside contributor puts in the work, and that's of course assuming the maintainers are willing to accept said work at all.

It's not difficult to see from their commits that they did not spend much time on the media engine. Even MTL's HuC has not been added to the header file.

https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/xe_uc_fw.c?ref_type=heads#L115

On the UMD side, the media-driver also doesn't yet support Xe KMD. And interestingly, Intel once said it had no plans for AV1 ICQ encoding on Linux, but the the requests from the community changed their mind.