![]() A rendering call with buffers does not have to handle the possibility of the user changing the memory later, so it can simply write a few tokens into the command stream. This is generally why Buffer Objects are better than using client memory for rendering. ![]() Modifications to client memory after the rendering call will only affect future rendering calls, not those that have already passed. These are usually used for rendering calls in which case, once the rendering call has returned, the memory to be read from client data has been read. During that period, they must remain valid. When these use client-side memory (which is no longer permitted in core OpenGL), the pointers are stored for a period of time. Legacy Note: The only OpenGL functions that behave differently are functions that end in Pointer. When glBufferSubData returns, you can immediately modify or delete whatever memory pointer you gave it, as OpenGL has already read as much as it wants. When glReadPixels returns, the pixel data is in your client memory (unless you are reading into a buffer object). Functions like glTexSubImage2D, glReadPixels, glBufferSubData and so forth.īecause OpenGL is defined to be synchronous, when any of these functions have returned, they must have finished with the client memory. There are several OpenGL functions that can pull data directly from client-side memory, or push data directly into client-side memory. If you issue a command which depends on the results of a prior command, the implementation will prevent any execution overlap between those two commands. As such, the OpenGL API will appear synchronous even if it executes asynchronously. ![]() The OpenGL API however is defined to be synchronous each command acts as if all prior commands had completed entirely. This transition eats up a lot of cycles, so if the internal driver can store 30 rendering commands and then issue all of them with only one transition, this is faster than making one transition for each of the 30 rendering calls. Issuing a command to the internal rendering command buffer can be a fairly slow process, due to a CPU transition (on x86 hardware) out of protected mode and into unprotected mode. It allows for many optimizations of the rendering command pathway. This is not a weakness of OpenGL it is a strength. The OpenGL specification allows implementations the freedom to get around to rendering commands whenever it is best for them. Indeed, it is perfectly legitimate for rendering to not even have started when this function returns. If you call any of the glDraw* functions to initiate rendering, it is not at all guaranteed that the rendering has finished by the time the call returns. OpenGL Rendering Commands are assumed to execute be asynchronous.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |