Are there any methods that we can reserve memory for GL_ELEMENT_ARRAY_BUFFER in OpenGL like .reserved(int) of std::vector or thrust::device_vector in Cuda?
Say, I have 200 triangles (600 indices) on frame1, but there are 250 completely new triangles (750 indices) on frame2. How can I reserved once at the beginning and update it on every frame?
Once you have allocated a buffer object and made a glBufferData() call then the memory to back it is allocated. You can pass a null data pointer into the first glBufferData() call to make an allocate-only buffer with no data upload.
You can patch an existing buffer without reallocation using glBufferSubData(), however just make sure you don't try to patch a buffer which is still referenced in existing draw calls. See ...
https://community.arm.com/graphics/b/blog/posts/mali-performance-6-efficiently-updating-dynamic-resources
for more details.
Related
I am working with PointCloud data that I need to render using opengl. I get a new vector of data points every frame. I want that I be able to cache the data previously sent to opengl and only send the newest frame data to it. How can I do so?
I did some searching and found this idea here:
// Bind the old buffer to `GL_COPY_READ_BUFFER`
glBindBuffer (GL_COPY_READ_BUFFER, old_buffer);
// Allocate data for a new buffer
glGenBuffers (1, &new_buffer);
glBindBuffer (GL_COPY_WRITE_BUFFER, new_buffer);
glBufferData (GL_COPY_WRITE_BUFFER, ...);
// Copy `old_buffer_size`-bytes of data from `GL_COPY_READ_BUFFER`
// to `GL_COPY_WRITE_BUFFER` beginning at 0.
glCopyBufferSubData (GL_COPY_READ_BUFFER, GL_COPY_WRITE_BUFFER, 0, 0, old_buffer_size);
But it looks like its finally sending previous and new data in the new buffer instead of caching and sending only the latest data. So I am not sure if its the best way. Please correct me if I am wrong or suggest alternative.
So you store some data in your CPU memory, and you append more data to this storage. Then you want to send only the appended data to GPU, not the whole buffer.
Your code example is irrelevant for this task, as glCopyBufferSubData copies data from a location in GPU memory to another location in GPU memory again.
You need a combination of glBufferData and glBufferSubData. glBufferData allocates memory in GPU and optinoaly initializes it. glBufferSubData writes some data to already allocated GPU buffer. You may treat glBufferData as C's malloc or C++ new, while glBufferSubData is like a special version C's memcpy or C++ std::copy. More precisely, glBufferSubData is memcpy from CPU to GPU, and glCopyBufferSubData is memcpy from GPU to GPU.
How to cook them together? The same way as in C. Call glBufferData once at initialization time (when program starts), and call glBufferSubData when you need to append data. Be sure to allocate enough space! A buffer allocated by glBufferData does not grow, as well as malloced buffer. Overflowing a buffer with glBufferSubData causes undefined behavior and may crash your application.
Try to predict space requirement for your buffer, and call glBufferData only if your data does not fit into the buffer.
Remember that calling glBufferData with already allocated buffer binding will deallocate existing buffer and create a new one.
glBufferSubData will not reallocate your buffer, but will overwrite data which is already there.
Let me illustrate it with C translation:
glGenBuffers(..., buf); // float* buf;
glBindBuffer(buf); // Tell opengl that we will use buf pointer, no analog in C.
glBufferData(/*non-null pointer*/); // buf = malloc(/*..*/); memcpy(to_gpu, from_cpu);
glBufferData(/*another non-null pointer*/); // free(buf); buf = malloc(/*..*/); memcpy(to_gpu, from_cpu);
glBufferSubData(...); // memcpy(to_gpu, from_cpu);
Ideomatic approach
What you need is:
glGenBuffers(..., buf); // float* buf;
glBindBuffer(buf); // Tell opengl that we will use buf pointer, no analog in C.
// Initialization
glBufferData(/*non-null pointer*/); // buf = malloc(/*..*/); memcpy(to_gpu, from_cpu);
// Hot loop
while (needToRender) {
if(needToAppend) {
if (dataDoesNotFit) glBufferData(...); // Reallocate, same buffer name
else glBufferSubData(...); // memcpy(to_gpu, from_cpu);
}
}
Here we reallocate memory only occasionally, when we need to append something and buffer is too small.
Other approaches
I advised to reallocate with glBufferData as you already have all data in a single buffer on CPU. If not (i.e. you have a chunk of data on GPU and another chunk on CPU, but not together), you could use glCopyBufferSubData for reallocating:
glBufferData(/*alloc new_gpu_buffer*/);
glCopyBufferSubData(/*from old_gpu_buffer to new_gpu_buffer*/);
glDeleteBuffers(/*old_gpu_buffer*/);
glBufferSubData(/*from_cpu_buffer to new_cpu_buffer*/)p; // Add some new data from CPU.
Another approach for updating GPU data is mapping it to CPU, so you just access GPU memory by pointer. It's likely to be slow (blocks the buffer, stalls the pipeline), and is useful only in special cases. Use it if you know what you do.
Since OpenGL is an API focused on drawing things (ignoring compute shaders for the moment) and when drawing a scene you normally start from an empty canvas, you'll have to retain the complete backlog of point cloud data throughout for the whole span of time, you want to be able to redraw.
Assuming that for large amounts of point cloud data, redrawing the whole set might take some time, some form of cachine might seem reasonable. But let's do some back of the envelope calculateions first:
Typical GPUs these days are perfectly capable of performing full vertex setup at a rate well over 10^9 vertices / second (already 20 years ago GPUs were able to do something on the order of 20·10^6 vertices / second). Your typical computer display has less than 10·10^6 pixels. So because of the pigeonhole principle, if you were to draw more than 10·10^6 points you're either producing serious overdraw or fill up most of the pixels; in practice it's going to be somewhere inbetween.
But as we've already seen, GPUs are more than capable of drawing that many points at interactive framerates. And drawing any more of them will likely fill up your screen or occlude data.
Some form of data retirement is required, if you want the whole thing to remain readable. And for any size of pointcloud that is readable your GPU will be able to redraw the whole thing just fine.
Considering the need for data retirement, I suggest you allocate a large buffer, that is able to hold a whole set of points over their lifetime, before eviction, and use it as a circular round robin buffer: Have an offset where you write over new data as it arrives (using glBufferSubData), at the edges you may have to split this in two calls, pass the latest writing index as a uniform, to fade out points by their age, and then just submit a single glDrawElements call to draw the whole content of that buffer in one go.
I am a newbee to OpenGL. Now I could render something on screen, which is great. Now I want to streaming some data point(GL_POINTS) on my screen. However, initially it doesn't show anything. And it costs me several days to find out how to make it works.
The point is, I use an VBO to save my data and call glBufferSubData() to update the buffer. However, it ONLY works if I call glBufferData() before the first render loop. In other words, if I just do
glGenVertexArrays(1, &VAO);
glGenBuffers(1, &VBO);
in my initializing function (before first render loop), and in my updateData loop I do
glBindVertexArray(VAO);
glBindBuffer(VBO);
glBufferData(GL_ARRAY_BUFFER, myData.size() * sizeof(float), &myData[0], GL_DYNAMIC_DRAW);
... // glVertexAttribPointer and other required general process
It won't render anything. It seems I have to glBufferData(/some random data here/) to "allocate" the buffer (I thought it was allocated when calling glGenBuffer()). And use
glBufferSubData(/*override previous data*/) or
glMapData()
to update that buffer.
So my question would be...what is the proper/normal way to initialize an VBO if I don't know how much data/vertex I need to draw in the compile time? (right now I just glBufferData() a loooooong buffer and update it when needed)
Note: OpenGL3.3, Ubuntu16.04
Update:
In my opinion, it works in the way like allocating char[], I have to say pointing out how much I need for the string char[200], and fill in the data via snprintf(). But we now have vector or string, that allows us to dynamically change the memory location. Why OpenGL doesn't support that? If they did, how should I use it.
I thought it was allocated when calling glGenBuffer()
The statement:
int *p;
Creates an object in C/C++. That object is a pointer. It does not point to an actual object or any kind of storage; it's just a pointer, waiting to be given a valid address.
So too with the result of glGenBuffers. It's a buffer object, but it has no storage. And like an uninitialized pointer, there's not much you can do with a buffer object with no storage.
what is the proper/normal way to initialize an VBO if I only don't know how much data/vertex I need to draw in the compile time?
Pick a reasonable starting number. If you overflow that buffer, then either terminate the application or allocate additional storage.
But we now have vector or string, that allows us to dynamically change the memory location. Why OpenGL doesn't support that?
Because OpenGL is a low-level API (relatively speaking).
In order to support dynamic reallocation of storage in the way you suggest, the OpenGL implementation would have to allocate new storage of the size you request, copy the old data into the new storage, and then destroy the old storage. std::vector and std::string have to do the same stuff; they just do it invisibly.
Also, repeatedly doing that kind of operation horribly fragments the GPU's address space. That's not too much of a problem with vector and string, since those arrays are usually quite small (on the order of kilobytes or low megabytes). Whereas a single buffer object that takes up 10% of a GPU's total memory are hardly uncommon in serious graphics applications. Reallocating that is not a pleasant idea.
OpenGL gives you the low-level pieces to build that, if you want to suffer the performance penalty for doing so. But it doesn't implement it for you.
UPDATE I just discovered my question is likely a duplicate of If you call glBufferData after already calling it on a buffer, is there a memory leak?
Hopefully my question is still useful to someone, as I give code samples, rather than merely mentioning the gl function calls, as in that Q&A.
I don't understand the relationship between glGenBuffers / glBindBuffer / glBufferData and gldeletebuffers.
Consider drawing a sequence of lines (a line strip). The original sequence is drawn over some number of frames, but then new user input increases the number of lines.
My first thought is to re-use the buffer object name assigned by glGenBuffers, when the size changes. But since the buffer size needs to be larger, I can't use the existing buffer as-is.
NOTE: At this time, I would rather not assume some "maximum size", allocate that, and then do sub-data calls for the size I currently need.
Consider code based on this example:
When should I call glDeleteBuffers()?
If I had done these lines in an initialization function before drawing the first frame (code may not compile -- I'm concerned about the call sequence, not the exact parameters to pass -- I'm actually working in C# under Xamarin using OpenTK to access OPENGL ES 2.0, but it is easier to find examples in C++ using opengl):
GLuint VBO;
void init(int size, float* data) {
glGenBuffers(1, &VBO);
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
}
which many frames later (or when app exits) is released via:
void destroy() {
glDeleteBuffers(1, &VBO);
}
But now I want to have a "re_init" function that allocates a different size, what exactly do I need to do?
I could re-assign a new VBO buffer name:
void re_init(newSize, newData) {
destroy();
init(newSize, newData);
}
But this seems like overkill. What is the minimum work that I can do? And is that any more efficient than the brute-force destroy/create-a-new-one above?
It seems that any set of calls I do works, but i don't know whether the result is leaking memory or not. I will eventually need to learn how to test for memory leaks in the environment I am in, but right now I want to get the theory right, in hopes that I will write code that is both efficient and non-leaking.
Will this leak memory?
void re_init(newSize, newData) {
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, newSize, newData, GL_STATIC_DRAW);
}
That is, I haven't done glDeleteBuffers on the old buffer, because doing so freed the VBO buffer name, and I am trying to find out how to not do so.
One question is whether there is a way to re-use a VBO buffer name, with data of a different size?
Or am I better off sticking to the simple model of freeing the buffer and its name every time I need to change buffer size? (That is what glDeleteBuffers seems to do.)
There are 3 separate entities in play here:
A buffer name. Since it is an integer value lot of people like to call this an "id". But if you read official OpenGL documentation, it is always called "name".
A buffer object. This is the object that contains the state attributes, like the current size, the usage flags, etc.
A buffer store. This is the memory that contains the actual buffer content.
With these definitions, we can describe what each call is doing:
glGenBuffers() creates buffer names.
glBindBuffer() creates a buffer object the first time the given name is bound, and makes it the current buffer for other calls operating on buffers.
glBufferData() deletes the current buffer store if there already was one, and creates a new buffer store.
glBufferSubData() modifies data in the existing data store.
glDeleteBuffers() deletes the buffer names, as well as the associated buffer objects and buffer stores if they exist.
This means that calling glBufferData() on the same buffer object multiple times is perfectly fine, and will not cause any memory leaks.
A subtle detail in the list above is that glGenBuffers() does not create buffer objects. That only happens the first time the name is bound. This does not really matter for buffer objects, but it is important to understand for other types of objects (like textures) that have the same behavior.
glBufferData will replace the content of the buffer object - as indicated is the spec/doc, "while creating the new storage, any pre-existing data store is deleted" - so this won't leak memory.
For efficiency, there are many factors to consider, and no universal guidelines - I suggest you profile in your application, once you have a real use case with your data.
I have just started learning about vertex buffer objects in C++. I am reading a book about OpenGL that says that VBO rendering is more efficient than other forms of rendering because the data is stored on the GPU instead of on the heap. However, I am confused how this could be if you still have to load an array of data from the heap to the GPU. Every few seconds, I update the vertex data of my program, which means that I must then use glBufferData() to refresh the data to update to the new state. I don't see how this is more efficient than just rendering the array normally. I was wondering if I am calling glBufferData() more than is necessary, or if there is a better way to update the vertex data directly on the GPU.
Well, glBufferData (...) does more than you think. True it supplies data to a VBO, but the more important point is that it allocates memory on the server side (GPU for all intents and purposes) for vertex storage.
In your example, the number of vertices, and therefore size required to store them does not seem to change when you refresh your data. What you should actually be doing is calling glBufferSubData (...) to update the data without re-allocating space for it. Coupled with a correct usage flag (e.g. GL_DYNAMIC_DRAW) this can be much more efficient than copying from client to server everytime something is drawn.
Think of glBufferData (...) as a combination of malloc (...) and memcpy (...). glBufferSubData (...) on the other hand is memcpy (...). To this, end you can even do memory mapping of VBOs into your application's address space without having to allocate storage in both the client and server using glMapBuffer (...) and glUnmapBuffer (...), which are analogous to mmap (...) and munmap (...).
You should try to avoid modifying your vertex data every few frames. Vertex/fragment shaders are specifically there to allow you to modify your geometry on the fly, with some limitations of course.
However, in the simplest case (if you don't care about maximizing your performance), it is entirely possible to rewrite the buffer on every frame, and it should still beat calling glBegin..glEnd for every object.
Would someone care to explain the difference to be between a VertexBuffer, a VertexArray, a VertexBufferObject, and a VertexArrayObject? I'm not even sure if these are all terms for different things, but I've seen all of them appear in the OpenGL spec.
I know that a VertexBuffer simply contains vertices and nothing else, once bound, and once I've set the vertex pointers, I can use DrawArrays to draw it. I've done it this way many times.
I am using what I think is a VertexArray, which stores the state of any vertex buffers that are set, and also any vertex pointers. Binding a VertexArray automatically binds the vertex buffer and sets the vertex pointers. I have used this (mostly) successfully too.
But what is a VertexBufferObject, and a VertexArrayObject? Are they better? Doesn't VertexArray give me everything I need?
A vertex array is simply some data in your program (inside your address space) that you tell OpenGL about by providing a pointer to it.
While more efficient than specifying every single vertex individually, they still have performance issues. The GL must make a copy at the time you call DrawElements (or a similar function), because that is the only time it can be certain that the data is valid (after all, nothing prevents you from overwriting the data right away). This means that there is a significant hindrance to parallelism, and thus a performance issue.
Vertex buffer objects ("vertex buffers") are raw blocks of data that you do not own, i.e. they are not in your address space. You can either copy data into the buffer object with Copy(Sub)Data or by temporarily mapping it to your address space. Once you unmap the buffer, it does no longer belong to you. The huge advantage is that now the GL can decide what to do with it, and when to upload it. It knows that the data will be valid, because you cannot access it. This makes CPU/GPU parallelism a lot easier.
Vertex array abjects are a bit of a misnomer. There are no vertices or arrays in them. They are merely a kind of "state description block" which encapsulate the bindings of one or several vertex buffer objects (including any VertexAttribPointer calls). As such, they are both a convenience function and somewhat more efficient (fewer function calls), but not strictly necessary. You could do anything that a VAO does by hand, too.
BufferObject: a GPU allocated memory buffer
Vertex Buffer Object: a BufferObject containing vertices informations (colors, position, custom data used by a shader, ...)
Pixel Buffer Object: a BufferObject containing pixel or texel informations. Mainly used to upload textures.
Element Buffer Object: a BufferObject containing indices (used by glDrawElements).
Vertex Array: memory used by gl*Pointer call. Might be host memory or a Vertex Buffer Object if it is bound using glBindBuffer command with GL_ARRAY_BUFFER.
Element Array: memory used by glDrawElements call. Might be host memory or an Element Buffer Object if it is bound using glBindBuffer command with GL_ELEMENT_ARRAY_BUFFER.