Dxvk: Texture swizzling on Intel Gen7 Graphics

[SilverBird775]

Intel Ivy Bridge and Bay Trail are the Intel's Vulkan low-end. Besides the lack of caching for coherent memory the is another major thorn in rear about them.

In essence, the Ivy Bridge (desktop variant) and Bay Trail (mobile variant) can't do texture swizzling. Shocking.
Here is the Bugs Mailing List report about the problem:
https://bugs.freedesktop.org/show_bug.cgi?id=104355

There is an unofficial patch mentioned
git://github.com/vsyrjala/mesa.git anv_gen7_tex_swizzle_3
for swizzling emulation but it was never commited into master for being awful inefficient as it seems. Yes, it works for those who enjoy drivers tinkering but the others are still suffering.

Can we do something on the DXVK side to shuffle the data at least for a most common formats? Indeed, it's a driver issue, but it will stay so even when it will be fixed upstream. It will stay inefficient, but the game engine or DXVK could potentially ease the problem in advance.

Can you please share your thought on this issue? The mentioned graphics chips are quite widespread and within a certain limits do their casual gaming duties well. Making them to just work would be a huge deal.

Whatever you decide, thank you for your hard work!

[Joshua-Ashton]

I can think of two methods to fix this:

a) Being incredibly expensive on the CPU and manually changing resources to have the right swizzle

b) Having a million and one shader permutations for swizzling textures inside the shader.

Both of which are rather impractical and would be horribly inefficient, the latter could also use uniforms, but I have serious doubts as to Ivy Bridge/Bay Trail's efficiency at control flow too (unless it could be avoided somehow)

However, then you also have the fact that depth buffers & stencils that are bound to samplers utilize swizzles to go into the correct vector slot that is expected by DXBC shaders.

[Joshua-Ashton]

This has also been a blocker for MoltenVK usage with DXVK, not sure if they have a solution for it yet.

[cdavis5e]

This has also been a blocker for MoltenVK usage with DXVK, not sure if they have a solution for it yet.

We do. It's disabled by default, but you can turn it on with any of the following:

• Building MoltenVK with -DMVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE=1
• Setting MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE=1 in the environment
• Calling vkSetMoltenVKConfigurationMVK() with a MVKConfiguration object whose fullImageViewSwizzle member is set to true

When enabled, it will insert code into the shaders to handle texture swizzling. And yeah, this is pretty bad for performance--that's why it's disabled by default.

[SilverBird775]

I propose to convert everything to mutually compatible formats ahead of the swizzle and reduce the swizzle complexity to something more trivial. The idea comes from the fake compressed textures support, where both compressed and uncompressed textures are hiding under the same hood and each one used as appropriate.

The idea behind this may not work for swizzling, so please bear my ignorance, i'm just an unhappy user wanting to be useful.

[doitsujin]

I do not plan to support hardware without proper Vulkan support. Some things may work, and minor quality-of-life improvements are certainly an option (like the memory allocation workaround), but I really want to avoid complex workarounds that simply aren't necessary on compliant implementations. It's just too much work.

The same goes for Intel's Haswell GPUs, which do not support sampled depth images (which is a major issue for pretty much every game which has some sort of SSAO, and would be even harder to work around), and Ivy Bridge probably suffers from the same issue.

[SilverBird775]

For a story to be complete:
Since Mesa 19.2 the texture swizzling for Gen 7 hardware is emulated through shaders in ANV drivers.