<blockquote>
  <p>Why is this feature present in OpenGL/Vulkan and not Direct3D/Metal?</p>
</blockquote>

<p>It's present in OpenGL because someone thought it would be a good idea, wrote an <a href="https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_swizzle.txt" rel="nofollow noreferrer">OpenGL extension specification</a> 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 <em>is</em> present in some API (because it's a thing that makes sense to have), it's generally hard to say why feature X <em>is not</em> 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&hellip;</p>

<p>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 <em>lots</em> 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, &hellip;) 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&hellip;</p>

<p>Apart from that, while I don't know about Metal, Direct3D 12 does allow you to specify a <a href="https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/ne-d3d12-d3d12_shader_component_mapping" rel="nofollow noreferrer">shader component mapping</a> when creating a resource view, which is effectively exactly the same thing as the OpenGL texture swizzle mask&hellip;</p>

CC BY-SA 4.0
2019-01-07T04:10:15.090Z
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.
Matt Haynie
CC BY-SA 4.0
2022-05-06T08:04:31.380Z
Metal 3.0 (OS X 10.15+) since added the support for texture swizzle, with a hardware family requirement (MTLGPUFamilyMac2).
rotoglup
CC BY-SA 4.0
2019-01-06T15:04:24.507Z
2019-01-06T18:20:40.817Z
2019-01-06T18:20:40.817Z
Michael Kenzel
<p>To be clear, I'm talking about behavior like <a href="https://www.khronos.org/opengl/wiki/Texture#Swizzle_mask" rel="nofollow noreferrer">https://www.khronos.org/opengl/wiki/Texture#Swizzle_mask</a>, not "normal" <code>myColorVariable.rbgr</code> swizzling in a shader.</p>

<p>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. </p>

<p>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?</p>

<directx11>
Why don't Direct3D/Metal support texture swizzles?
Matt Haynie
# Why don't Direct3D/Metal support texture swizzles?

(Asked by: username_0 on 2019-01-06)

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?

**Tags:** directx11


---

## 1 answers

### Answer by username_1 on 2019-01-06. Score: 4 | Accepted answer

> 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](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_swizzle.txt) 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](https://docs.microsoft.com/en-us/windows/desktop/api/d3d12/ne-d3d12-d3d12_shader_component_mapping) when creating a resource view, which is effectively exactly the same thing as the OpenGL texture swizzle mask…

> **Comments:**
> **username_0**: 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.  
> **username_2**: Metal 3.0 (OS X 10.15+) since added the support for texture swizzle, with a hardware family requirement (MTLGPUFamilyMac2).  

---

