DXVK should use VK_KHR_image_format_list

[gfxstrand]

When creating UAV or typeless images, DXVK sets VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT which makes sense. Unfortunately, this causes the Intel Vulkan driver to shut off basically all compression. It would be helpful if you used the VK_KHR_image_format_list extension and provided the list of all formats you intend to use. For typeless images, this would be the list of all formats that correspond to the used _TYPELESS format. For UAV images, it would be the UAV image format together with the corresponding integer format. This would let us turn compression back on in most cases.

[doitsujin]

I can see the point of doing it for UAV images since that's an implementation detail of DXVK, but would there be any situation where doing it for TYPELESS images would be helpful? There are no restrictions on which formats can be used to view a TYPELESS image as long as the total number of bits per pixel is the same, not to mention that the list would be huge and prone to errors.

[gfxstrand]

Doing it for typed UAV is useful because it lets the driver know that you will only be using those two types (the primary type and the integer type). Also, while we're on the topic, you appear to set VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT for UAV regardless of whether or not it already has an integer format.

For texture views, I'm seeing this in the DXGI_FORMAT documentation:

Typeless data, with a defined number of bits. Typeless formats are designed for creating typeless resources; that is, a resource whose size is known, but whose data type is not yet fully defined. When a typeless resource is bound to a shader, the application or shader must resolve the format type (which must match the number of bits per component in the typeless format).

A typeless format contains one or more subformats; each subformat resolves the data type. For example, in the R32G32B32 group, which defines types for three-component 96-bit data, there is one typeless format and three fully typed subformats.

This seems to imply (please correct me if I'm wrong!) that the view format must match both the bits-per-pixel of the format and the channel layout (R8G8B8A8 vs R16G16) of the typeless format. This is far more restrictive than the Vulkan and OpenGL rules which simply require the bits-per-pixel to match and allow you to have a view which re-interprets R8G8B8A8_UNORM as R16G16_FLOAT. That restriction is what we need in order to turn on compression and using VK_KHR_image_format_list will let you communicate it to the driver.

[doitsujin]

This seems to imply (please correct me if I'm wrong!) that the view format must match both the bits-per-pixel of the format and the channel layout

The docs are inaccurate in this case, you can reinterpret R8G8B8A8_TYPELESS as pretty much anything that has a 32-bit pixel size. There are a few games which use such an image with a R32_UINT view, for example.

[gfxstrand]

The docs are inaccurate in this case, you can reinterpret R8G8B8A8_TYPELESS as pretty much anything that has a 32-bit pixel size. There are a few games which read such an image as R32_UINT, for example.

That's very unfortunate. In that case, something more complex may be needed because we really don't want the performance hit of setting VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT all the time without restriction. Yes, D3D11 and OpenGL drivers have to deal with this but we can do a lot more CPU-side tracking in those APIs than we can with Vulkan.

[doitsujin]

I've done some more research and it looks like the restrictions you quoted do apply to render target views, but not to UAVs. So in theory we could make good use of the format list for images which we know won't be used as storage images.

Now the question is how to actually implement this while staying sane...

[doitsujin]

Latest master should provide a format list for non-UAV images, and also fixes an issue where the MUTABLE bit would not be set for an SRGB image which can be used with a non-SRGB view and vice versa.

[doitsujin]

63af141 adds support for typed UAVs as well, and they are no longer marked as MUTABLE if the integer clear format is the same as the image format itself.