Fake Sparse Support Merged For Intel's Vulkan Linux Driver To Make More Games Playable

[phoronix]

Phoronix: Fake Sparse Support Merged For Intel's Vulkan Linux Driver To Make More Games Playable

Preventing some modern Windows games from running on Intel Arc Graphics under Linux with Valve's Steam Play has been held up by lack of sparse support within Intel's ANV Vulkan driver. Those limitations will hopefully be overcome with the Intel Xe kernel mode driver when that is mainlined in hopefully the coming months, but for now it's a bit of a sore spot for Intel Linux gamers. A partial workaround though has now been merged for Mesa 23.3 with fake sparse support...

https://www.phoronix.com/news/Intel-Fake-Sparse-Merged

[RejectModernity]

Is this some kind of cope to not make Xe a primary driver for Intel's Alchemist cards?

[bezirg]

Is this some kind of cope to not make Xe primary driver for Intel's Alchemist cards?

Exactly.

[Teggs]

Fake it until you make it.

[QwertyChouskie]

Is this some kind of cope to not make Xe a primary driver for Intel's Alchemist cards?

From the MR:

Some DX12 games require sparse resource support but don't actually use sparse resources. Add a way to make these games work while we still don't have sparse resources fully working on every KMD backend.

So it's a stop-gap measure.

[Quackdoc]

Is this some kind of cope to not make Xe a primary driver for Intel's Alchemist cards?

I doubt XE was ever planned to be the primary driver for alchemist, it simply takes far too long for a driver to mature to that degree, ofc XE is already pretty promising regardless. who knows, intel might be against doing the work to get HUC working itself, but it might not be that hard to get a DKMS for XE with DG2 Huc patched in, it's not something I have cared to look into however

[Veto]

Shouldn't this be fixed in the DXVK (or whatever) translation layer instead?

Vulkan was always just supposed to expose whatever the hardware actually supports.

[Quackdoc]

Shouldn't this be fixed in the DXVK (or whatever) translation layer instead?

Vulkan was always just supposed to expose whatever the hardware actually supports.

I guess that would depend if the game itself is requesting sparse, or if DXVK is erroneously requesting it, it seems like it might be the game that's requesting it, in that case it would be the game that ought to fix it . but if DXVK is the one erroneously requesting it, then it would probably be on them.

[smitty3268]

I guess that would depend if the game itself is requesting sparse, or if DXVK is erroneously requesting it, it seems like it might be the game that's requesting it, in that case it would be the game that ought to fix it . but if DXVK is the one erroneously requesting it, then it would probably be on them.

I believe it's just a baseline requirement for DX12, so if a game tries to use a DX12 renderer, DXVK has to check if the driver supports all the required features whether the game uses it or not.

There's not really any way to work around that in DXVK, other than:

• Bypass the check, report DX12 driver support to games, and allow it to crash if the game tries to actually use the feature
• Do game by game testing to see if it uses it, and whitelist those that work. Which is exactly what this driver patch is doing on the Mesa side.

I think they probably didn't do that 2nd part in DXVK yet simply because ARC cards are still very rare and nobody is really feeling a ton of pressure to fix support for them yet. Most of the pressure is still on the Intel side to provide better drivers. And they are indeed working on them, with proper support supposedly on the way even if it isn't instant. Testing all their games on ARC wouldn't be instant either from DXVK's side.

I'm guessing that would have happened eventually if ARC cards kept selling well and increasing share, but Intel didn't want to wait that long and added "fake" support on their side first instead.