GLMAPBUFFERRANGE(3G)
okay so bestie, we're deep in glMapBufferRange(3G) territory and it's literally about mapping all or part of a buffer object's data store into the client's address space. no cap, this is the whole vibe.
π NAME π
glMapBufferRange, glMapNamedBufferRange β map all or part of a buffer object's data store into the client's address space. periodt.
πΈ C SPECIFICATION πΈ
void *glMapBufferRange(GLenum target, GLintptr offset,
GLsizeiptr length, GLbitfield access);
void *glMapNamedBufferRange(GLuint buffer, GLintptr offset,
GLsizeiptr length, GLbitfield access);
π PARAMETERS π
target
Specifies the target to which the buffer object is bound for glMapBufferRange, which must be one of the buffer binding targets in the following list:
GL_ARRAY_BUFFERβ vertex attributesGL_ATOMIC_COUNTER_BUFFERβ atomic counter storageGL_COPY_READ_BUFFERβ buffer copy sourceGL_COPY_WRITE_BUFFERβ buffer copy destinationGL_DISPATCH_INDIRECT_BUFFERβ indirect compute dispatch commandsGL_DRAW_INDIRECT_BUFFERβ indirect command argumentsGL_ELEMENT_ARRAY_BUFFERβ vertex array indicesGL_PIXEL_PACK_BUFFERβ pixel read targetGL_PIXEL_UNPACK_BUFFERβ texture data sourceGL_QUERY_BUFFERβ query result bufferGL_SHADER_STORAGE_BUFFERβ read-write storage for shadersGL_TEXTURE_BUFFERβ texture data bufferGL_TRANSFORM_FEEDBACK_BUFFERβ transform feedback bufferGL_UNIFORM_BUFFERβ uniform block storage
buffer
Specifies the name of the buffer object for glMapNamedBufferRange. iykyk.
offset
Specifies the starting offset within the buffer of the range to be mapped.
length
Specifies the length of the range to be mapped.
access
Specifies a combination of access flags indicating the desired access to the mapped range. this is the bitfield bestie, pay attention π
π DESCRIPTION π
glMapBufferRange and glMapNamedBufferRange map all or part of the data store of a specified buffer object into the client's address space. offset and length indicate the range of data in the buffer object that is to be mapped, in terms of basic machine units. access is a bitfield containing flags which describe the requested mapping. These flags are described below.
A pointer to the beginning of the mapped range is returned once all pending operations on the buffer object have completed, and may be used to modify and/or query the corresponding range of the data store according to the following flag bits set in access:
GL_MAP_READ_BITβ indicates that the returned pointer may be used to read buffer object data. No GL error is generated if the pointer is used to query a mapping which excludes this flag, but the result is undefined and system errors (possibly including program termination) may occur. like, do not test this at home πGL_MAP_WRITE_BITβ indicates that the returned pointer may be used to modify buffer object data. No GL error is generated if the pointer is used to modify a mapping which excludes this flag, but the result is undefined and system errors (possibly including program termination) may occur. same energy, bestie: undefined is not your friend πGL_MAP_PERSISTENT_BITβ indicates that the mapping is to be made in a persistent fashion and that the client intends to hold and use the returned pointer during subsequent GL operation. It is not an error to call drawing commands (render) while buffers are mapped using this flag. It is an error to specify this flag if the buffer's data store was not allocated through a call to theglBufferStorage()command in which theGL_MAP_PERSISTENT_BITwas also set. so slay, but only if you set it up right β¨GL_MAP_COHERENT_BITβ indicates that a persistent mapping is also to be coherent. Coherent maps guarantee that the effect of writes to a buffer's data store by either the client or server will eventually become visible to the other without further intervention from the application. In the absence of this bit, persistent mappings are not coherent and modified ranges of the buffer store must be explicitly communicated to the GL, either by unmapping the buffer, or through a call toglFlushMappedBufferRange()orglMemoryBarrier(). the way that coherence mattersβ¦ iconic honestly π«Ά
The following optional flag bits in access may be used to modify the mapping:
GL_MAP_INVALIDATE_RANGE_BITβ indicates that the previous contents of the specified range may be discarded. Data within this range are undefined with the exception of subsequently written data. No GL error is generated if subsequent GL operations access unwritten data, but the result is undefined and system errors (possibly including program termination) may occur. This flag may not be used in combination withGL_MAP_READ_BIT. okay so this one is giving "throw it away, I'll write new stuff" πGL_MAP_INVALIDATE_BUFFER_BITβ indicates that the previous contents of the entire buffer may be discarded. Data within the entire buffer are undefined with the exception of subsequently written data. No GL error is generated if subsequent GL operations access unwritten data, but the result is undefined and system errors (possibly including program termination) may occur. This flag may not be used in combination withGL_MAP_READ_BIT. whole-buffer chaos, but make it deliberate πGL_MAP_FLUSH_EXPLICIT_BITβ indicates that one or more discrete subranges of the mapping may be modified. When this flag is set, modifications to each subrange must be explicitly flushed by callingglFlushMappedBufferRange(). No GL error is set if a subrange of the mapping is modified and not flushed, but data within the corresponding subrange of the buffer are undefined. This flag may only be used in conjunction withGL_MAP_WRITE_BIT. When this option is selected, flushing is strictly limited to regions that are explicitly indicated with calls toglFlushMappedBufferRange()prior to unmap; if this option is not selectedglUnmapBuffer()will automatically flush the entire mapped range when called. so either you flush by hand or the unmap does it for you, no in-between bestie πGL_MAP_UNSYNCHRONIZED_BITβ indicates that the GL should not attempt to synchronize pending operations on the buffer prior to returning fromglMapBufferRangeorglMapNamedBufferRange. No GL error is generated if pending operations which source or modify the buffer overlap the mapped region, but the result of such previous and any subsequent operations is undefined. highkey risky vibe, but okay π
If an error occurs, a NULL pointer is returned.
If no error occurs, the returned pointer will reflect an allocation aligned to the value of GL_MIN_MAP_BUFFER_ALIGNMENT basic machine units. Subtracting offset from this returned pointer will always produce a multiple of the value of GL_MIN_MAP_BUFFER_ALIGNMENT. alignment math, but make it glam β¨
The returned pointer values may not be passed as parameter values to GL commands. For example, they may not be used to specify array pointers, or to specify or query pixel or texture image data; such actions produce undefined results, although implementations may not check for such behavior for performance reasons. literally do not pass these pointers around like candy, bestie π
Mappings to the data stores of buffer objects may have nonstandard performance characteristics. For example, such mappings may be marked as uncacheable regions of memory, and in such cases reading from them may be very slow. To ensure optimal performance, the client should use the mapping in a fashion consistent with the values of GL_BUFFER_USAGE for the buffer object and of access. Using a mapping in a fashion inconsistent with these values is liable to be multiple orders of magnitude slower than using normal memory. not me warning you about the slow lane ππ
πΈ NOTES πΈ
okay so real talk bestie β the returned pointer is guaranteed to be aligned only if the version of GL is 4.2 or greater. like, donβt come for the alignment unless youβre on 4.2+. also, the GL_ATOMIC_COUNTER_BUFFER target is accepted only if the GL version is 4.2 or greater. periodt. β¨
the GL_DISPATCH_INDIRECT_BUFFER and GL_SHADER_STORAGE_BUFFER targets are accepted only if the GL version is 4.3 or greater. π
the GL_QUERY_BUFFER target is available only if the GL version is 4.4 or greater. π¦
and the GL_MAP_PERSISTENT_BIT and GL_MAP_COHERENT_BIT flags are available only if the GL version is 4.4 or greater. no cap. π
π ERRORS π
GL_INVALID_ENUMis generated byglMapBufferRangeiftargetis not one of the buffer binding targets listed above. π©GL_INVALID_OPERATIONis generated byglMapBufferRangeif zero is bound totarget.GL_INVALID_OPERATIONis generated byglMapNamedBufferRangeifbufferis not the name of an existing buffer object.GL_INVALID_VALUEis generated ifoffsetorlengthis negative, if$offset + length$is greater than the value ofGL_BUFFER_SIZEfor the buffer object, or ifaccesshas any bits set other than those defined above.
GL_INVALID_OPERATION is generated for any of the following conditions:
lengthis zero.- The buffer object is already in a mapped state.
- Neither
GL_MAP_READ_BITnorGL_MAP_WRITE_BITis set. GL_MAP_READ_BITis set and any ofGL_MAP_INVALIDATE_RANGE_BIT,GL_MAP_INVALIDATE_BUFFER_BITorGL_MAP_UNSYNCHRONIZED_BITis set.GL_MAP_FLUSH_EXPLICIT_BITis set andGL_MAP_WRITE_BITis not set.- Any of
GL_MAP_READ_BIT,GL_MAP_WRITE_BIT,GL_MAP_PERSISTENT_BIT, orGL_MAP_COHERENT_BITare set, but the same bit is not included in the bufferβs storage flags.
also important, bestie: no error is generated if memory outside the mapped range is modified or queried, but the result is undefined and system errors β possibly including program termination π β may occur. so likeβ¦ please donβt. thatβs giving βchaos gremlinβ energy and not the cute kind.
π ASSOCIATED GETS π
glGet() with pname GL_MIN_MAP_BUFFER_ALIGNMENT. the value must be a power of two that is at least 64. thatβs the whole vibe. β¨
π VERSION SUPPORT π
hereβs the OpenGL version vibe check, bestie:
glMapBufferRangeβ2.0:-;2.1:-;3.0:β;3.1:β;3.2:β;3.3:β;4.0:β;4.1:β;4.2:β;4.3:β;4.4:β;4.5:β.glMapNamedBufferRangeβ2.0:-;2.1:-;3.0:-;3.1:-;3.2:-;3.3:-;4.0:-;4.1:-;4.2:-;4.3:-;4.4:-;4.5:β.
π«Ά SEE ALSO π«Ά
go read these too, iykyk:
glMapBuffer()glUnmapBuffer()glFlushMappedBufferRange()glBindBuffer()glBufferStorage()
π COPYRIGHT π
Copyright Β© 2010-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 π
Copyright Β© 2014 Khronos Group
okay thatβs the page, bestie! it says it comes from [FIXME: source], dated 08/09/2021, and itβs filed under GLMAPBUFFERRANGE(3G). mwah ππ
π¦ 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