GLARETEXTURESRESIDENT(3G)
β¨ NAME β¨
glAreTexturesResident β bestie, this one tells you if your textures are actually loaded in texture memory or just, like, vibing in the void π
π C SPECIFICATION π
GLboolean glAreTexturesResident( GLsizei n,
const GLuint *textures,
GLboolean *residences )
πΈ PARAMETERS πΈ
nβ how many textures you wanna interrogate, queen. The count of the query.texturesβ an array holding the names of the textures you're asking about. Yes, the names. Not the vibes, the names.residencesβ the array where the answer gets dropped off π«Ά The residence status of a texture named by an element oftexturescomes back in the corresponding element ofresidences. Same index, same bestie, no shuffling.
π DESCRIPTION π
So GL keeps a ``working set'' of textures that are resident in texture memory. And the way that these resident textures can be bound to a texture target is so much more efficient than the textures that are not resident. It's giving fast lane vs. back of the line, honestly.
glAreTexturesResident queries the texture residence status of the n textures named by the elements of textures. Here's the tea:
- If all the named textures are resident β it returns
GL_TRUE, and the contents ofresidencesare left undisturbed. We don't touch, we don't poke, we just say yes β¨ - If not all the named textures are resident β it returns
GL_FALSE, and the detailed status gets returned in thenelements ofresidences. If an element ofresidencesisGL_TRUE, then the texture named by the corresponding element oftexturesis resident. Index matching, periodt.
Also, lowkey, you can check the residence status of a single bound texture by calling glGetTexParameter with the target argument set to the target to which the texture is bound, and the pname argument set to GL_TEXTURE_RESIDENT. And heads up bestie β this is the only way that the residence status of a default texture can be queried. The only one. Don't come at me with other ideas.
π NOTES π
glAreTexturesResidentis available only if the GL version is1.1or greater. Older GL, sorry babe, no dice.- It returns the residency status of the textures at the time of invocation. It does not guarantee the textures will remain resident at any other time. So don't screenshot this answer and frame it, okay? It's a moment, not a promise π
- If textures reside in virtual memory (there is no texture memory), they are considered always resident. Always. Iconic behavior.
- Some implementations may not load a texture until the first use of that texture. So like, it might be shy until you actually use it π
π ERRORS π
GL_INVALID_VALUEis generated ifnis negative. Negative count? Bestie no.GL_INVALID_VALUEis generated if any element intexturesis0or does not name a texture. And in that case, the function returnsGL_FALSEand the contents ofresidencesis indeterminate β aka, don't trust it, it's chaos.GL_INVALID_OPERATIONis generated ifglAreTexturesResidentis executed between the execution ofglBeginand the corresponding execution ofglEnd. Not inside that block, babe. Read the room.
Fr fr, do not call this betweenglBeginandglEnd. It will absolutely not slay there.
π₯ ASSOCIATED GETS π₯
glGetTexParameter with parameter name GL_TEXTURE_RESIDENT retrieves the residence status of a currently bound texture. That's the one, iykyk π
π¦ SEE ALSO π¦
glBindTexture(3G), glGetTexParameter(3G), glPrioritizeTextures(3G), glTexImage1D(3G), glTexImage2D(3G), glTexImage3D(3G), glTexParameter(3G)
And that's the whole page, bestie π This was the GLARETEXTURESRESIDENT(3G) manual page β same name up top, same name down at the bottom as the source/version footer. Go check your textures, tell them they're resident, and have the best day πβ¨π«Ά
π¦ where this page comes from
- opensuse-leap 16.0: Mesa-libGL-devel 24.1.7-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms