GLINVALIDATEBUFFERSU(3G)
β¨ GLINVALIDATEBUFFERSU(3G) β¨
okay so bestie, this is a page from the 3G manual section β OpenGL and friends, the whole GL fam π
β and today's main character is glInvalidateBufferSubData. it's giving "let me just yeet this chunk of buffer data into the void." no cap, that's literally the whole job.
π NAME π
glInvalidateBufferSubData β invalidate a region of a buffer object's data store
like, just a region though. not the whole thing. we're being surgical here π¦
πΈ C SPECIFICATION πΈ
void glInvalidateBufferSubData(GLuint buffer, GLintptr offset,
GLsizeiptr length);
π PARAMETERS π
bufferβ the name of a buffer object, and we're invalidating a subrange of its data store. not somebody else's. this one's.offsetβ the offset within the buffer's data store where the range to be invalidated starts. like where you're planting the little "nothing to see here" flag π©lengthβ the length of the range within the buffer's data store that's getting invalidated. how much of it we're torching.
π¦ DESCRIPTION π¦
glInvalidateBufferSubData invalidates all or part of the content of the data store of a buffer object.
and after invalidation? the content of the specified range of the buffer's data store becomes undefined. not zeroed, not cleared to some cute default value β undefined. it's giving "this memory is now vibes only" π so pls don't go reading it expecting anything specific.
the start of the range is given by offset and its size is given by length, and both of those are measured in basic machine units. iykyk π«Ά
π ERRORS π
GL_INVALID_VALUEis generated ifoffsetorlengthis negative, or ifoffset+lengthis greater than the value ofGL_BUFFER_SIZEforbuffer. so no negative girlies and no overreaching, the math has to actually fit inside the buffer, periodt.GL_INVALID_VALUEis generated ifbufferis not the name of an existing buffer object. you can't invalidate a buffer that isn't real, bestie, that's not a vibe β¨GL_INVALID_OPERATIONis generated if any part ofbufferis currently mapped. even one part of it mapped = nope. unmap first, then come back π
π₯ ASSOCIATED GETS π₯
glGetBufferParameter()with argumentGL_BUFFER_SIZE
that's your little vibe check for how big the buffer actually is π
π VERSION SUPPORT π
so here's the tea on which OpenGL versions are on the guest list β glInvalidateBufferSubData is a late arrival, she showed up in 4.3 and stayed for 4.4 and 4.5:
- OpenGL 2.0 β
-(not invited) - OpenGL 2.1 β
-(not invited) - OpenGL 3.0 β
-(not invited) - OpenGL 3.1 β
-(not invited) - OpenGL 3.2 β
-(not invited) - OpenGL 3.3 β
-(not invited) - OpenGL 4.0 β
-(not invited) - OpenGL 4.1 β
-(not invited) - OpenGL 4.2 β
-(not invited) - OpenGL 4.3 β
β(slay, she's here) - OpenGL 4.4 β
β(still iconic) - OpenGL 4.5 β
β(still iconic, we love consistency)
so yeah, 2.0 through 4.2 are all -, and 4.3 / 4.4 / 4.5 are all β. the way that she just... wasn't a thing before 4.3 π
π SEE ALSO π
glInvalidateTexSubImage(),,glInvalidateTexImage(),glInvalidateBufferData(),glInvalidateFramebuffer(),glInvalidateSubFramebuffer().
(and yes the double comma after glInvalidateTexSubImage() is in the original, i'm just the messenger π
β go read those other pages too, they're the whole invalidation friend group πΈ)
π COPYRIGHT π
Copyright Β© 2013-2014 Khronos Group. This material may be distributed subject to the terms and conditions set forth in the Open Publication License, v 1.0, 8 June 1999. http://opencontent.org/openpub/.
π COPYRIGHT π (yes, again β it's listed twice in the original, so it's listed twice here, i don't make the rules π)
Copyright Β© 2013-2014 Khronos Group
and that's the page!! source situation: [FIXME: source], dated 08/09/2021, and the whole thing is filed under GLINVALIDATEBUFFERSU(3G) in the 3G manual. bestie you ate that, go invalidate responsibly π«Άπ
π¦ where this page comes from
- centos-stream 9: gl-manpages 1.1-24.20190306.el9 Β· MIT and Open Publication
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms