vkCreateImageView(): 2D views on 3D images can only be used as color attachments.

[BearishSun]

How can I avoid the following error?

VK_ERROR_FEATURE_NOT_PRESENT: vkCreateImageView(): 2D views on 3D images can only be used as color attachments.

I'm creating a 3D texture that is being used both as a color attachment and for shader reads (in a later stage).

For color attachment purposes I'm binding the texture slices as 2D texture array view, which is allowed. For shader reads I'm binding the texture as a 3D texture view, which is also allowed.

I don't think we should be receiving the error if the usage is correct. Or am I misunderstanding something?

[cdavis5e]

If you use VkImageViewUsageCreateInfoKHR from VK_KHR_maintenance2, and set the usage on your 2D array view to VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, you should be able to avoid that error.

[billhollings]

@cdavis5e @Lichtso

While we're on the topic...the implemented logic for the test for this seems strange:

            if ( !mvkIsAnyFlagEnabled(_usage, VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT) ) {
                setConfigurationResult(reportError(VK_ERROR_FEATURE_NOT_PRESENT, "vkCreateImageView(): 2D views on 3D images can only be used as color attachments."));
            } else if (!mvkIsOnlyAnyFlagEnabled(_usage, VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT)) {
                reportError(VK_ERROR_FEATURE_NOT_PRESENT, "vkCreateImageView(): 2D views on 3D images can only be used as color attachments.");
            }

This appears to be an if followed by the same logic as an iff...which would appear to be redundant to me...but the iff doesn't mark the error as a config error.

I should think I can clean this up by eliminating the first test...and reporting the config error correctly in the second.

But before I go ahead and do that...am I missing something in this logic?

[Lichtso]

• mvkIsAnyFlagEnabled: At least the selection is enabled.
• !mvkIsAnyFlagEnabled: The selection is disabled.
• mvkIsOnlyAnyFlagEnabled: Only the selection is enabled.
• !mvkIsOnlyAnyFlagEnabled: If the selection is enabled, then other flags must be too. The selection can also be disabled.

As far as my reasoning goes, yes, the second condition includes the first, therefore it is redundant.

[billhollings]

I should think I can clean this up by eliminating the first test...and reporting the config error correctly in the second.

Fixed in PR #971.

[benjaminmordaunt]

@billhollings Are we 100% sure this is fixed?

The mentioning issue above, from yuzu-emu, encounters this problem. I wouldn't even begin to know where to look for Vulkan/MoltenVK-specific logs or debug information. The Yuzu logs don't produce anything else but:

[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkCreateImageView(): 2D views on 3D images can only be used as color attachments.
libc++abi: terminating with uncaught exception of type Vulkan::vk::Exception: VK_ERROR_FEATURE_NOT_PRESENT

[billhollings]

@benjaminmordaunt What was fixed was some poorly-executed logic. The basic test remains the same.

See the note by @cdavis5e above for how, within Vulkan, to avoid the conditions creating the reported error.

With regards to MoltenVK error logging, errors are reported via VK_EXT_debug_report, and are logged to stderr (so, wherever your app sends stderr).

[benjaminmordaunt]

@billhollings Thanks!

From what I understand, the emulator already uses VkImageViewUsageCreateInfoKHR from VK_KHR_maintenance2. The issue is that MoltenVK appears to add the restriction that if VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT is set, that is the only buffer usage that is allowed to be set, as there is an exclusivity check which ultimately results in this error. I'm no Vulkan/graphics expert, but I understand that, in this case, the emulator wants to (re)use the buffer in other stages, so other usages are also added.

AFAIK, this is not a constraint of a typical VK implementation, so shouldn't MVK be making provisions for this somehow instead of just saying "no can do"?

I think reworking the emulator code to cater for this case would be quite challenging. I would be interested to hear the underlying deficiency in Metal that means this is a necessary restriction.

The confusion comes because this issue is marked as closed, but the solution is not really a solution for many uses.

From a different emulator project (not sure if related):

MoltenVK has a ton of issues surrounding storage buffer usage stage flags when running under argument buffers mode. The command buffer immediately fails if the stage usage for any buffer changes between two draws (used in vertex shader only, then in follow up (or in another binding on the same set) used in fragment shader). You'd think that setting the stage flags to always be every stage would work around this issue. However, shaders without a fragment stage or using rasterizer discard force this to happen, and always cause the error. The only way to really solve this is to end the render pass when the stage usage changes due to the program's used stages, and there's a ton of annoying boilerplate we have to do to achieve that. Vulkan should not break when a buffer is used between multiple stages.

Can this issue be reopened?

[billhollings]

Possibly related to more recent #1870?

[AMA2581]

@billhollings Hi, I was trying to support suyu-emu on macOS but I got this issue and I saw that this issue is reopened I wondered, is it fixed? How can I fix this? If you could help me to understand and fix it, it would be wonderful.

We are using VkImageViewUsageCreateInfoKHR from VK_KHR_maintenance2 but still we have this issue.

I have to note that my macOS and moltenVK is updated to latest release.

[billhollings]

If you could help me to understand and fix it, it would be wonderful.

It depends on what problem you are encountering.

The issue described above...

if VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT is set, that is the only buffer usage that is allowed to be set, as there is an exclusivity check which ultimately results in this error.

...still exists. If you are encountering that error, because you need the image usage to include other usage elements, then you'll have to remove that restriction within MoltenVK code, to avoid the error, and see if it works for you (no guarantees if you act on any particular of those additional usages).

The fundamental issue we are wrestling with is that Metal fundamentally does not support 2D views on 3D textures, so we have to emulate it, which has other ramifications for other usages.

[AMA2581]

@billhollings Hi. I fixed the error by adding some lines of code to my codes not moltenVK. the code that I added was:

    // using image usage color attachment bit on 3D models 
    auto usage = ImageUsageFlags(format_info, info.format);
    if (info.type == ImageType::e3D)
        usage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;

    const auto [samples_x, samples_y] = VideoCommon::SamplesLog2(info.num_samples);
    return VkImageCreateInfo{
        .sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,
        .pNext = nullptr,
        .flags = flags,
        .imageType = ConvertImageType(info.type),
        .format = format_info.format,
        .extent{
            .width = info.size.width >> samples_x,
            .height = info.size.height >> samples_y,
            .depth = info.size.depth,
        },
        .mipLevels = static_cast<u32>(info.resources.levels),
        .arrayLayers = static_cast<u32>(info.resources.layers),
        .samples = ConvertSampleCount(info.num_samples),
        .tiling = VK_IMAGE_TILING_OPTIMAL,
        .usage = usage, // changed this to usage
        .sharingMode = VK_SHARING_MODE_EXCLUSIVE,
        .queueFamilyIndexCount = 0,
        .pQueueFamilyIndices = nullptr,
        .initialLayout = VK_IMAGE_LAYOUT_UNDEFINED,
    };
}

thanks for your support.

I know it's not a good place but I have this issue now that in some games I get this error:

[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 3):
output of type float4 is not compatible with a MTLPixelFormatRGBA16Uint color attachment..

I'm trying to figure out what is causing this problem and what should I do. I think it tries to convert float4 into a MTLPixelFormatRGBA16Uint or four four 16 bit unsigned integers but it can't. If you guys could help me, it would be so wonderful.

[billhollings]

Glad you got it working. I see you are able to restrict the 3D image usage to just VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, which matches the needs of Metal under MoltenVK. That's great.

[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 3): output of type float4 is not compatible with a MTLPixelFormatRGBA16Uint color attachment..

It appears that the pipeline shader is expecting float pixel formats, but you're attempting to render to an integer format image.

Generally, shaders outputting floats are used for rendering to either float or unorm format images.

[AMA2581]

@billhollings well I don't know what to do but I will try to figure out what is going on inside the code and probably fix it. If I did it I will tell you that I've done it.

One thing worth noting is that pipeline is already using float but I think moltenVK wants Uint. I know how the Uint works but I think there should be a conversion to make this work. I try to figure out where should I put that conversion.

If you were free, it would be so awesome if you check out our code and give me your opinion about our mess. https://gitlab.com/suyu-emu/suyu. I have a lot of respect to your work and your team and I hope me trying my best every day works and fixes the issue.

[billhollings]

If you were free, it would be so awesome if you check out our code and give me your opinion about our mess. https://gitlab.com/suyu-emu/suyu. I have a lot of respect to your work and your team and I hope me trying my best every day works and fixes the issue.

Thanks for the compliments! I'm very interested in seeing how the suyu emulator evolves, and I'm happy to help with issues that you encounter and post here. But unfortunately, I won't have the bandwidth to dig into and understand the suyu codebase.