While this is arguably a feature addition, it is a feature that the GL backend had since forever and I'm surprised we got away without it in d3d11 so far.
From: Stefan Dösinger stefan@codeweavers.com
--- dlls/wined3d/utils.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c index dea43836f06..8256e387b22 100644 --- a/dlls/wined3d/utils.c +++ b/dlls/wined3d/utils.c @@ -4261,6 +4261,7 @@ static void init_vulkan_format_info(struct wined3d_format_vk *format, {WINED3DFMT_B8G8R8X8_UNORM, VK_FORMAT_B8G8R8A8_UNORM, "XYZ1"}, {WINED3DFMT_B8G8R8X8_UNORM_SRGB, VK_FORMAT_B8G8R8A8_SRGB, "XYZ1"}, {WINED3DFMT_B5G6R5_UNORM, VK_FORMAT_R5G6B5_UNORM_PACK16, }, + {WINED3DFMT_B5G5R5A1_UNORM, VK_FORMAT_A1R5G5B5_UNORM_PACK16, }, {WINED3DFMT_BC1_UNORM, VK_FORMAT_BC1_RGBA_UNORM_BLOCK, }, {WINED3DFMT_BC1_UNORM_SRGB, VK_FORMAT_BC1_RGBA_SRGB_BLOCK, }, {WINED3DFMT_BC2_UNORM, VK_FORMAT_BC2_UNORM_BLOCK, },
From: Stefan Dösinger stefan@codeweavers.com
We can query support for this format without checking for an extension. VK_EXT_4444_formats introduces VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT, which is a native fit, but we have to introduce extension checks to vulkan_formats[]. I'll wait until after the release to submit this.
---
Not all Vulkan implementations support 16 bit packed formats. Notably Metal on Intel/AMD GPUs doesn't expose any of them (but MoltenVK knows the enums, so we can call vkGetPhysicalDeviceFormatProperties()). We'll need to do conversion similarly to the GL backend. --- dlls/wined3d/utils.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c index 8256e387b22..f4036eed726 100644 --- a/dlls/wined3d/utils.c +++ b/dlls/wined3d/utils.c @@ -4262,6 +4262,7 @@ static void init_vulkan_format_info(struct wined3d_format_vk *format, {WINED3DFMT_B8G8R8X8_UNORM_SRGB, VK_FORMAT_B8G8R8A8_SRGB, "XYZ1"}, {WINED3DFMT_B5G6R5_UNORM, VK_FORMAT_R5G6B5_UNORM_PACK16, }, {WINED3DFMT_B5G5R5A1_UNORM, VK_FORMAT_A1R5G5B5_UNORM_PACK16, }, + {WINED3DFMT_B4G4R4A4_UNORM, VK_FORMAT_R4G4B4A4_UNORM_PACK16, "YZWX"}, {WINED3DFMT_BC1_UNORM, VK_FORMAT_BC1_RGBA_UNORM_BLOCK, }, {WINED3DFMT_BC1_UNORM_SRGB, VK_FORMAT_BC1_RGBA_SRGB_BLOCK, }, {WINED3DFMT_BC2_UNORM, VK_FORMAT_BC2_UNORM_BLOCK, },
Jan Sikorski (@jsikorski) commented about dlls/wined3d/utils.c:
{WINED3DFMT_B8G8R8X8_UNORM_SRGB, VK_FORMAT_B8G8R8A8_SRGB, "XYZ1"}, {WINED3DFMT_B5G6R5_UNORM, VK_FORMAT_R5G6B5_UNORM_PACK16, }, {WINED3DFMT_B5G5R5A1_UNORM, VK_FORMAT_A1R5G5B5_UNORM_PACK16, },
{WINED3DFMT_B4G4R4A4_UNORM, VK_FORMAT_R4G4B4A4_UNORM_PACK16, "YZWX"},
It looks like it should be `ZYXW`, or am I reading the fixup wrong?
On Fri Dec 13 17:11:47 2024 +0000, Jan Sikorski wrote:
It looks like it should be `ZYXW`, or am I reading the fixup wrong?
Admitedly I found this via trial and error - YZWX was the one that got the textures in Maple Story right.
Here's a more thoughtful attempt in explaining it. I prefer Vulkan's pixel format enums over dxgi since someone at Microsoft insisted on reordering them vs their d3d9 counterparts...
WINED3DFMT_B4G4R4A4_UNORM matches VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT. My patch is using R4G4B4A4_UNORM for now:
``` VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT VK_FORMAT_R4G4B4A4_UNORM_PACK16
A/W is in R/X R/X is in G/Y G/Y is in B/Z B/Z is in A/W ```
we want to have RGBA in the shader read, so YZWX.
This merge request was approved by Jan Sikorski.
This merge request was approved by Elizabeth Figura.
Approved, though it strikes me as more of a feature addition than anything else. On the other hand, the Vulkan backend is still not the default, so in terms of safety it's probably more safe than not?
-
Elizabeth Figura (＠zfigura) -
Jan Sikorski (＠jsikorski)
-
Stefan Dösinger
-
Stefan Dösinger (＠stefan)