To be clear, I'm talking about behavior like https://www.khronos.org/opengl/wiki/Texture#Swizzle_mask, not "normal" myColorVariable.rbgr swizzling in a shader.

I really did start missing this feature after switching from OpenGL to Direct3D11, and ended up implementing a poor man's version in HLSL. Initially, I just assumed this was another "feature" of OpenGL that didn't actually exist on any hardware and was just being emulated by every driver, but then I noticed that Vulkan supports it as well.

My understanding is that the Vulkan specification is not supposed to include "extras" that aren't supported by hardware, so what gives? Why is this feature present in OpenGL/Vulkan and not Direct3D/Metal?


1 Answer 1


Why is this feature present in OpenGL/Vulkan and not Direct3D/Metal?

It's present in OpenGL because someone thought it would be a good idea, wrote an OpenGL extension specification for it, released and supported the extension in their drivers, and the extension was eventually adopted into core profile. While it's usually pretty obvious why feature X is present in some API (because it's a thing that makes sense to have), it's generally hard to say why feature X is not present in some other API. There's a wide range of possible reasons. You would have to talk to whoever were the people responsible for the design of the API in question at the time to find out…

Concerning hardware support: In case of doubt, you can simply convince yourself by comparing rendering times with and without using a texture swizzle. You would notice if you were hitting a software path there. The fact that the extension was introduced by NVIDIA would lead me to the conclusion that there's at least one hardware vendor that is able to support this on their hardware; otherwise, why would they introduce it!? If you think about it: Texture sampling hardware already has to support lots of different formats (floating point, signed integer, unsigned integer, normalized signed integer, normalized unsigned integer, all for different numbers of components, component sizes, sRGB versions for some, compressed formats, …) including some where the order of components is different on the output side from what it is on the input side (e.g., BGRA). Adding a few bits to the texture descriptor to control which components go where in the output is probably not a big deal. I'm not a hardware engineer, but it would seem to me that it probably even makes the hardware simpler because it reduces the number of special cases. So I'd say chances are that hardware was already using a swizzle mask internally long before it was exposed on the API side…

Apart from that, while I don't know about Metal, Direct3D 12 does allow you to specify a shader component mapping when creating a resource view, which is effectively exactly the same thing as the OpenGL texture swizzle mask…

  • 1
    $\begingroup$ Ah, thanks. I didn't think of checking D3D12, the fact is present there seems to suggest that its omission in D3D11 was just because it just never got added, rather than being deliberately omitted. $\endgroup$ Commented Jan 7, 2019 at 4:10
  • $\begingroup$ Metal 3.0 (OS X 10.15+) since added the support for texture swizzle, with a hardware family requirement (MTLGPUFamilyMac2). $\endgroup$
    – rotoglup
    Commented May 6, 2022 at 8:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.