Hi everybody, I am teaching an introductory class on OpenGL and to keep things simple the curriculum introduces geometry specification with client side arrays. Later in the course we touch on VAOs and VBOs filled with glBufferData.

I'm thinking of modernizing the material by (obviously) totally scrapping client side arrays and (not-so-obviously) also scrapping glBufferData in favor of glMapBuffer or glMapBufferRange.

It is a short class and I think conceptually the students can hang with any of these options, but I wonder... if it is better to teach glBufferData and let them figure out glMapBuffer for themselves or teach glMapBuffer and let them figure out glBufferData for themselves.

Thanks,
Nick

Keep in mind that glBufferData and glMapBuffer[Range] don't do the same thing. glBufferData actually allocates the memory for the buffer, as well as setting the contents whereas glMapBuffer(Range) only sets the data (once the buffer memory has been allocated). glBufferData is good enough for introductory material but I would also just mention glMapBuffer[Range] for the curious students who may want to know more.

Ok, thanks a lot! I'll stick with glBufferData() as my buffer-filling function in the lecture.

P.S. For my own personal curiosity, is the "proper" way to fill ever-changing vertex data with glMapBuffer() still require a glBufferData(NULL) beforehand to orphan? Is all this rigamarole avoided by using glMapBufferRange() with the invalidate flag instead?

I doubt my students will get that detailed, but I would like to know the real-world usage patterns in addition to the dry API descriptions.

Wow, thanks for all the help everybody. I do understand that glBufferData is needed to allocating the buffer object... I am asking which function I should teach for filling it up. I guess I'm asking if glBufferData is deprecated as a filling-up function nowadays.

Promit, thanks so much for that link. I actually did stumble across that in my research and would like to ask a question about it a passage -- I hope I read it carefully enough:

Pinned memory is standard CPU memory and there is no actual transfer to de- vice memory: in this case, the device will use data directly from this memory location. The PCI-e bus can access data faster than the device is able to render it, so there is no performance penalty for doing this, but the driver can change that at any time and transfer the data to device memory.

So when I've taught (and been taught) VBOs in the past, they are often rationalized with a statement along the lines of "we used to keep vertex data in slow client-side memory, but with VBOs we can keep vertex data in superfast video card memory!"

I just did some double-checking before I posted this, even opengl.org frames the advantages of VBOs in terms of which memory they are stored in:

A Vertex Buffer Object (VBO) is a memory buffer in the high speed memory of your video card designed to hold information about vertices.

However, if I'm reading Hrabcak and Masserann correctly they are saying that actually, VBOs can be in client-side memory and additionally keeping vertex data in client-side memory isn't necessarily that slow.

This is very different than what I thought! I can only imagine that the performance improvement of a VBO stored in client-side memory comes because you aren't memcpy-ing your data over to the driver every frame. Is this true? Is presenting VBOs as superior for their lack of clientside-to-clientside copying every frame the way to go pedagogically?

Thanks again,

Nick

The choice of what method to fill the buffer is dependent on a per use case basis. If the buffer is going to be static etc and never changed for the lifetime of the application, then I don't really see a benefit in mapping the buffer and copying the data, might as well supply the data at buffer creation time. If the buffer contents changes on a regular basis, then you would have to see if mapping and copying is more efficient than sub uploading coupled with orphaning etc...there really is no right or wrong answer as only you would know your specific use case.

Whew okay... think I have my answer here. I was mostly worried about misleading the students by omitting the "standard fast" way, but it seems there is still a lot of flexibility in vertex upload functions.

One last technical question though (I can't help it) -- I didn't realize that glMapBuffer existed on iOS. Since iOS is a shared memory GPU, doesn't that mean that our client-side memory and our GPU memory are the same memory? In that case, wouldn't their be no difference between writing to unified memory with glBufferData/glBufferSubData versus writing to unified memory with glMapBuffer/glMapBufferRange?

Thanks for all the patience and answers,

Nick