1
$\begingroup$

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.

$\endgroup$
9
  • 1
    $\begingroup$ 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). $\endgroup$
    – Thomas
    Feb 28 at 11:37
  • 2
    $\begingroup$ 3379 is very small for modern hardware, perhaps consider changing out the hardware itself. $\endgroup$
    – pmw1234
    Feb 28 at 12:17
  • $\begingroup$ or check if you have installed the newest driver $\endgroup$
    – Thomas
    Feb 28 at 12:59
  • $\begingroup$ @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. $\endgroup$ Feb 28 at 13:25
  • 2
    $\begingroup$ @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. $\endgroup$ Feb 28 at 18:06

1 Answer 1

3
$\begingroup$

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

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$ Feb 28 at 18:37

Your Answer

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

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