A Swapchain in native APIs represents a queue of presentable textures. The user doesn't create or own individual textures in that queue, but they can request (at swapchain creation) specific flags usage supported by those images.

Metal

CAMetalLayer configuration has framebufferOnly flag:

If the value is true (the default), the CAMetalLayer class allocates its MTLTexture objects in ways that are optimized for display purposes. However, you may not sample, read from, or write to those textures. To support sampling and pixel read/write operations on the layer’s textures (at a cost to performance), set this value to false.

This clearly indicates that restricting the swapchain to a typical usage has performance benefits.

D3D12

DXGI_SWAP_CHAIN_DESC contains DXGI_USAGE bits, of which relevant are:

• DXGI_USAGE_RENDER_TARGET_OUTPUT
• DXGI_USAGE_SHADER_INPUT
• DXGI_USAGE_UNORDERED_ACCESS
• copies appear to be always supported, but their performance depends on the SHADER_INPUT flag

MSDN doesn't appear to specify if requesting these flags has any performance implications, or if some combinations are not supported on a particular platform.

However, run-time does complain when UNORDERED_ACCESS is requested:

The BufferUsage field of the swapchain description contains some DXGI_USAGE flags that are not supported

Vulkan

VkSwapchainCreateInfoKHR has imageUsage flags that allow the user to specify the supported usage for the images.

The requested flags have to be a subset of the flags returned in VkSurfaceCapabilitiesKHR::supportedUsageFlags by vkGetPhysicalDeviceSurfaceCapabilitiesKHR.

The only guaranteed usage by the specification is VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT.

TL;DR

Note that being able to use STORAGE in all of the APIs requires us to be able to create a texture view with a format that actually supports storage operations, i.e. view "rgba8unorm" as "r32uint". We don't currently support this casting in WebGPU.