How expensive is glGenTextures

I have two options for generating the texture IDs. Sure, you normally use option 1.
But if you have packed the texture ID in a struct array, you have to use option 2.
Now to the question, is it OK to use option 2, or are there any disadvantages?

void Test1() {
  GLuint textures[128];
  glGenTextures(128, textures);

void Test2() {
  GLuint textures[128];
  for (int i=0; i<128; i++) {
    glGenTextures(1, &textures[i]);

If you can live with 0.0001 second more, then this is good.

The first version allows for doing less forth and back. The result should be slightly faster. AFAIK, there should have no other differences.

I suggest option 3:

void Test3() {
  GLuint tmp[128];
  GLuint textures[128];
  glGenTextures(128, tmp);
  for (int i=0; i<128; i++)
    textures[i] = tmp[i];

One call to glGenTextures then copying the values is preferable to multiple calls.

Anything which returns data to client memory should be treated as potentially expensive. glGen* probably won’t be expensive in the sense of requiring synchronisation (although it might need a context switch), but it will almost certainly be more expensive than copying an integer.

Thank you very much
I will use this solution.
I need it for text output in OpenGL and I use a texture for each character.

I just came across the following: Array Texture - OpenGL Wiki
But you can only use it if you use OpenGL 3.0 or higher.

The usual approach is to use a texture atlas. This allows multiple characters to be drawn with a single glDrawElements (or similar) call, which is likely to be significantly more efficient than one draw call per character. The legacy approach was to create a display list for each character and use glCallLists; how efficient this is on modern hardware varies wildly depending upon how much effort the driver takes to optimise display lists.

Note that you can’t (reliably) just use an array of sampler2D from a fragment shader because arrays of samplers can only be indexed with integral constant expressions (up to GLSL 3.3) or a dynamically-uniform expression (in GLSL 4.x). The specification doesn’t guarantee that distinct triangles form distinct work groups for the fragment shader, so a per-triangle variable isn’t guaranteed to be dynamically-uniform. And in any case, if you have support for GLSL 4.x, you also have support for array textures.

If array textures are available (3.0 or EXT_texture_array), they have the advantage (compared to an atlas) that you don’t have to worry about bleeding between adjacent images due to filtering, even when using mipmaps.

I have now solved it with glTexImage3D(GL_TEXTURE_2D_ARRAY, ...).
As you write, this function is only available from OpenGL4.x?
On the shader side, it worked with GLSL 330

I already had an OpenGL3.3 solution with a texture atlas. I passed the text to the shader via a uniform. And called the whole thing with glDrawArraysInstanced.

But if you don’t have a monospace font, this solution will hardly work.

And I think you can forget about UTF8 anyway.

Array textures are available in 3.0.

With a proportionally-spaced font, you have to calculate the starting position for each character as the sum of the widths of all the previous characters. This either needs to be done sequentially or with a parallel prefix sum algorithm (which is O(n log n) in the number of characters, so a GPU implementation needs O(log n) iterations).

Any script that isn’t Latin-like (draw glyph, offset by width, repeat) will need an explicit layout phase. Scripts with many characters (e.g. Hanzi/Kanji) may need a multi-layer atlas (i.e. an array texture where each layer is an atlas) or de-composition (multiple quads per glyph). Hangul realistically needs to be de-composed; you probably can’t fit that many pre-composed characters in video memory.