<p>First, a correction:</p>
<blockquote>
<p>GL_MAX_TEXTURE_SIZE contains 3379</p>
</blockquote>
<p>No, it does not. That is the value of the <code>GL_MAX_TEXTURE_SIZE</code> <em>enumerator</em> (0x0D33). The actual implementation-defined maximum size is queried with <code>glGetIntegerv</code> <em>using</em> that enumerator.</p>
<hr />
<p>As for how to render to a conceptual image larger than the size of the texture you can create... you're just going to have to render the scene several times, with different viewports to different images. You can employ <a href="https://www.khronos.org/opengl/wiki/Geometry_Shader#Layered_rendering" rel="nofollow noreferrer">layered rendering</a> with array textures to shift viewports between the layers. And you should do different frustum culling for the different layers (so you're not rendering the exact same scene multiple times). But that's about it.</p>

CC BY-SA 4.0
2023-02-28T18:37:58.523Z
This makes a lot more sense. That it needs to actually go get the value from somewhere and not just expect it to be there waiting. Thank you Nicol.
mathreadler
CC BY-SA 4.0
2023-02-28T18:20:17.397Z
2023-02-28T18:20:17.397Z
Nicol Bolas
<p>I recently hit the roof for maximum texture size for my opengl implementation (GL_MAX_TEXTURE_SIZE contains <span class="math-container">$3379$</span>) when I wanted to create a texture for a 4k resolution video frame (<span class="math-container">$3840 \times 2160$</span>).</p>
<p>This made me think about various ways to circumvent the problem that <span class="math-container">$3840&gt;3379$</span>.</p>
<p>I have used TEXTURE_2D_ARRAY, and I suppose one way would be to create such an array with sizes divided by two. In my case 4 slices of <span class="math-container">$1920\times 1080$</span> which then get to represent one &quot;quadrant&quot; each. Like a &quot;block-matrix&quot;, so to speak.</p>
<p>I was thinking maybe there exist other, better solutions of how to address this.</p>

CC BY-SA 4.0
2023-02-28T11:37:22.350Z
I would do it the same way. Saving as `TEXTURE_2D_ARRAY` allows you to use layered rendering. To do this, you can use the geometry shader to duplicate the edited faces and rasterize them in all texture quadrants, using only one drawing call. This is especially useful if the vertex calculations are very computationally intensive. When using different textures, you would have to either cache the calculation (transform feedback buffer or shader storage buffer) or calculate it accordingly multiple times (per texture once).
Thomas
CC BY-SA 4.0
2023-02-28T12:17:30.803Z
3379 is very small for modern hardware, perhaps consider changing out the hardware itself.
pmw1234
CC BY-SA 4.0
2023-02-28T12:59:32.067Z
or check if you have installed the newest driver
Thomas
CC BY-SA 4.0
2023-02-28T13:25:27.370Z
@pmw1234 yes I am aware. It is an old card from.. almost 10 years ago, I think. Given how much interest I have for software development and graphics in general you are definitely right, but the current price situation on the GPU market is not very attractive.
mathreadler
CC BY-SA 4.0
2023-02-28T16:56:03.043Z
@Thomas this seems very interesting! Feel free to make an answer. I would gladly upvote.
mathreadler
CC BY-SA 4.0
2023-02-28T18:06:50.500Z
@mathreadler: "*GL_MAX_TEXTURE_SIZE contains 3379*" No, it does not. That's the value of the *enumerator* (0x0D33), not the value of your implementation's maximum texture size. You have to use `glGetIntegerv` with that enumerator to get the *actual* maximum texture size.
Nicol Bolas
CC BY-SA 4.0
2023-02-28T18:30:43.837Z
Of course! you are right Nicol. This makes a lot more sense. A power of 2: 16384
mathreadler
CC BY-SA 4.0
2023-02-28T20:09:50.140Z
With a hardware that old, you should check if layered rendering is supported before starting implementing it...
Thomas
CC BY-SA 4.0
2023-02-28T20:14:00.147Z
As Nicol pointed out, I needed to call an API function to get the true value which was 16384 -- a bit more reasonable.
mathreadler
<opengl><texture><data-structure>
Which coding strategies exist to handle opengl texture size limit?
mathreadler
# Which coding strategies exist to handle opengl texture size limit?

(Asked by: username_0 on 2023-02-28)

I recently hit the roof for maximum texture size for my opengl implementation (GL\_MAX\_TEXTURE\_SIZE contains $3379$) when I wanted to create a texture for a 4k resolution video frame ($3840 \times 2160$).

This made me think about various ways to circumvent the problem that $3840>3379$.

I have used TEXTURE\_2D\_ARRAY, and I suppose one way would be to create such an array with sizes divided by two. In my case 4 slices of $1920\times 1080$ which then get to represent one "quadrant" each. Like a "block-matrix", so to speak.

I was thinking maybe there exist other, better solutions of how to address this.

**Tags:** opengl, texture, data-structure

> **Comments:**
> **username_1**: I would do it the same way. Saving as `TEXTURE_2D_ARRAY` allows you to use layered rendering. To do this, you can use the geometry shader to duplicate the edited faces and rasterize them in all texture quadrants, using only one drawing call. This is especially useful if the vertex calculations are very computationally intensive. When using different textures, you would have to either cache the calculation (transform feedback buffer or shader storage buffer) or calculate it accordingly multiple times (per texture once).  
> **username_2**: 3379 is very small for modern hardware, perhaps consider changing out the hardware itself.  
> **username_1**: or check if you have installed the newest driver  
> **username_0**: @username_2 yes I am aware. It is an old card from.. almost 10 years ago, I think. Given how much interest I have for software development and graphics in general you are definitely right, but the current price situation on the GPU market is not very attractive.  
> **username_0**: @username_1 this seems very interesting! Feel free to make an answer. I would gladly upvote.  
> **username_3**: @username_0: "*GL_MAX_TEXTURE_SIZE contains 3379*" No, it does not. That's the value of the *enumerator* (0x0D33), not the value of your implementation's maximum texture size. You have to use `glGetIntegerv` with that enumerator to get the *actual* maximum texture size.  
> **username_0**: Of course! you are right username_3. This makes a lot more sense. A power of 2: 16384  
> **username_1**: With a hardware that old, you should check if layered rendering is supported before starting implementing it...  
> **username_0**: As username_3 pointed out, I needed to call an API function to get the true value which was 16384 -- a bit more reasonable.  

---

## 1 answers

### Answer by username_3 on 2023-02-28. Score: 3 | Accepted answer

First, a correction:

> GL\_MAX\_TEXTURE\_SIZE contains 3379

No, it does not. That is the value of the `GL_MAX_TEXTURE_SIZE` *enumerator* (0x0D33). The actual implementation-defined maximum size is queried with `glGetIntegerv` *using* that enumerator.

---

As for how to render to a conceptual image larger than the size of the texture you can create... you're just going to have to render the scene several times, with different viewports to different images. You can employ [layered rendering](https://www.khronos.org/opengl/wiki/Geometry_Shader#Layered_rendering) with array textures to shift viewports between the layers. And you should do different frustum culling for the different layers (so you're not rendering the exact same scene multiple times). But that's about it.

> **Comments:**
> **username_0**: This makes a lot more sense. That it needs to actually go get the value from somewhere and not just expect it to be there waiting. Thank you username_3.  

---

