<p>RGB8 format and similar are often not supported by GPUs (or only supported for a subset of GPU operations) because they don't have a power-of-two number of bytes per pixel. RGB8 would be 24 bits or 3 bytes per pixel. All the formats in that list have 1, 2, 4, 8, or 16 bytes per pixel.</p>

<p>Using a power of two simplifies addressing calculations in the hardware, because it can be implemented using a shift instead of a full multiply. (A shift by a fixed value such as 2 bits can even be implemented in hardware without any actual "calculations" at all, just by routing wires.) It also means that pixels are always nicely aligned with respect to boundaries of memory pages, cache lines, etc., which no doubt simplifies many things in the hardware.</p>

CC BY-SA 3.0
2017-01-15T01:27:00.053Z
2017-01-15T02:19:05.003Z
2017-01-15T02:19:05.003Z
Nathan Reed
<p>As stated in <a href="https://www.khronos.org/opengl/wiki/Layout_Qualifier_(GLSL)#Image_formats" rel="nofollow noreferrer">documentation</a> possible values for layout qualifiers of image formats are (for example floating point):</p>
<blockquote>
<p>Floating-point layout image formats:</p>
<ul>
<li>rgba32f</li>
<li>rgba16f</li>
<li>rg32f</li>
<li>rg16f</li>
<li>r11f_g11f_b10f</li>
<li>r32f</li>
<li>r16f</li>
<li>rgba16</li>
<li>rgb10_a2</li>
<li>rgba8</li>
<li>rg16</li>
<li>rg8</li>
<li>r16</li>
<li>r8</li>
<li>rgba16_snorm</li>
<li>rgba8_snorm</li>
<li>rg16_snorm</li>
<li>rg8_snorm</li>
<li>r16_snorm</li>
<li>r8_snorm</li>
</ul>
</blockquote>
<p>So we can use <code>R</code>, <code>RG</code> and <code>RGBA</code> formats. But why <code>RGB</code> (except r11f_g11f_b10f) is not allowed?</p>

CC BY-SA 3.0
2017-01-15T01:44:27.053Z
R11F_G11F_B10F is an RGB format.
Nicol Bolas
CC BY-SA 3.0
2017-01-15T03:04:50.213Z
Keep in mind that the docs don't list all possible formats. There are often vendor-specific formats, and formats that came after the docs were written.
user1118321
CC BY-SA 3.0
2017-01-15T10:19:44.533Z
@NicolBolas Yeah because it has 32 bits overall, now I see it.
mdkdy
<opengl><texture>
Using RGB texture format for image load/store
mdkdy
# Using RGB texture format for image load/store

(Asked by: username_0 on 2017-01-15)

As stated in [documentation](https://www.khronos.org/opengl/wiki/Layout_Qualifier_(GLSL)#Image_formats) possible values for layout qualifiers of image formats are (for example floating point):

> Floating-point layout image formats:
>
> * rgba32f
> * rgba16f
> * rg32f
> * rg16f
> * r11f\_g11f\_b10f
> * r32f
> * r16f
> * rgba16
> * rgb10\_a2
> * rgba8
> * rg16
> * rg8
> * r16
> * r8
> * rgba16\_snorm
> * rgba8\_snorm
> * rg16\_snorm
> * rg8\_snorm
> * r16\_snorm
> * r8\_snorm

So we can use `R`, `RG` and `RGBA` formats. But why `RGB` (except r11f\_g11f\_b10f) is not allowed?

**Tags:** opengl, texture

> **Comments:**
> **username_1**: R11F_G11F_B10F is an RGB format.  
> **username_2**: Keep in mind that the docs don't list all possible formats. There are often vendor-specific formats, and formats that came after the docs were written.  
> **username_0**: @username_1 Yeah because it has 32 bits overall, now I see it.  

---

## 1 answers

### Answer by username_3 on 2017-01-15. Score: 9 | Accepted answer

RGB8 format and similar are often not supported by GPUs (or only supported for a subset of GPU operations) because they don't have a power-of-two number of bytes per pixel. RGB8 would be 24 bits or 3 bytes per pixel. All the formats in that list have 1, 2, 4, 8, or 16 bytes per pixel.

Using a power of two simplifies addressing calculations in the hardware, because it can be implemented using a shift instead of a full multiply. (A shift by a fixed value such as 2 bits can even be implemented in hardware without any actual "calculations" at all, just by routing wires.) It also means that pixels are always nicely aligned with respect to boundaries of memory pages, cache lines, etc., which no doubt simplifies many things in the hardware.


---

