Should I Use Stl Containers?

[hessiess]

As OpenGL requires a C style array for glVrtexPointer() and related functions, a dynamic array is necessary. I was wondering if the use of STD::vector here would create any major performance decrease, and should be creating this with new/malloc instead.

Thanks.

 

[darkblu]

As OpenGL requires a C style array for glVrtexPointer() and related functions, a dynamic array is necessary. I was wondering if the use of STD::vector here would create any major performance decrease, and should be creating this with new/malloc instead.

* stl's vector is a fairly simple and efficient container. it's so efficient that the only thing you'd occasionally think of when using it is what to reseve().

* unless you're using some insanely-dynamic (read: changing each frame), and fairly-small meshes, you should be using VBO's there, not vertex arrays. from the pov of the GL driver, vertex arrays are a 'non-cacheable' operations - each time you specify a gl*Pointer() you effectively command the GL to flush its knowledge of this buffer and re-read it anew from user space - not good if you're not absolutely positive you actually mean that.

 

[hessiess]

As OpenGL requires a C style array for glVrtexPointer() and related functions, a dynamic array is necessary. I was wondering if the use of STD::vector here would create any major performance decrease, and should be creating this with new/malloc instead.

* stl's vector is a fairly simple and efficient container. it's so efficient that the only thing you'd occasionally think of when using it is what to reseve().

* unless you're using some insanely-dynamic (read: changing each frame), and fairly-small meshes, you should be using VBO's there, not vertex arrays. from the pov of the GL driver, vertex arrays are a 'non-cacheable' operations - each time you specify a gl*Pointer() you effectively command the GL to flush its knowledge of this buffer and re-read it anew from user space - not good if you're not absolutely positive you actually mean that.


The mesh in question may or may not change every frame, though it sounds like using a std::vector wouldn't cause a major slowdown.

 

[benjymous]

As OpenGL requires a C style array for glVrtexPointer() and related functions, a dynamic array is necessary. I was wondering if the use of STD::vector here would create any major performance decrease, and should be creating this with new/malloc instead.

Thanks.

I've been using stl containers heavily in my game, and it doesn't seem to have any issues with performance (all my slowdown at the moment is in the SDL drawing code, so I'll probably investigate your library soon to see how easily I can drop it in to my engine)

In fact, there are many things you can easily solve with a few lines of stl usage that would take many more lines to do manually (removing duplicates? stuff them in a std::list) and is likely to be buggier than the code produced by the stl guys

 

[darkblu]

The mesh in question may or may not change every frame, though it sounds like using a std::vector wouldn't cause a major slowdown.

well, then if it's the only piece of geometry in your scene try to make sure you call gl*Pointer() only when that mesh changes (of course, cannot be done if there are other meshes too).

again, consider VBO's - api-wise they're little but an 'expansion' to normal arrays, but really help make things optimal buffers-wise.

 

[Xmas]

from the pov of the GL driver, vertex arrays are a 'non-cacheable' operations - each time you specify a gl*Pointer() you effectively command the GL to flush its knowledge of this buffer and re-read it anew from user space

That's unrelated to gl*Pointer(), though. GL has to read data from client arrays at every draw call, since it has no knowledge over when you modify data in these arrays.

 

[lulzfish]

If the SGX shares memory with the CPU, isn't OpenGL always reading stuff from memory anyway?

 

[darkblu]

from the pov of the GL driver, vertex arrays are a 'non-cacheable' operations - each time you specify a gl*Pointer() you effectively command the GL to flush its knowledge of this buffer and re-read it anew from user space

That's unrelated to gl*Pointer(), though. GL has to read data from client arrays at every draw call, since it has no knowledge over when you modify data in these arrays.

doh. a deserved correction, Xmas. i'm getting rusty with client arrays.

If the SGX shares memory with the CPU, isn't OpenGL always reading stuff from memory anyway?

chances are SGX's uma spot and your process' heap are not the same physical memory - data still has to get from the latter to the former. VBO's are your friends ™.

 

[Xmas]

If the SGX shares memory with the CPU, isn't OpenGL always reading stuff from memory anyway?

It's important to understand that GPU and CPU work in parallel, with the driver implementing a command buffer so that applications which typically submit their rendering commands in bursts don't get slowed down by one unit having to wait for the other. If the GPU was reading directly from the client array, the draw call would have to block until the data is actually consumed.

If data is stored in driver-owned memory instead, the draw call can return immediately since the app cannot change the buffer contents without the driver knowing.

 

[multiplex]

VBO's are your friends ™.

Is VBO support even confirmed on the Pandora? IIRC, it's not part of the OpenGL ES base specification, but available as an extension.

 

[darkblu]

VBO's are your friends ™.

Is VBO support even confirmed on the Pandora? IIRC, it's not part of the OpenGL ES base specification, but available as an extension.

pandora should be good from the get go - VBOs are in es1.1 and es2 core specs.

 

[sinoth]

If the SGX shares memory with the CPU, isn't OpenGL always reading stuff from memory anyway?

chances are SGX's uma spot and your process' heap are not the same physical memory - data still has to get from the latter to the former. VBO's are your friends ™.
I'd like to know a little more about this. I was under the impression the GPU and CPU grabbed from the same memory pool, so there wouldn't be a drastic performance difference between VAs and VBOs.

 

[darkblu]

I'd like to know a little more about this. I was under the impression the GPU and CPU grabbed from the same memory pool, so there wouldn't be a drastic performance difference between VAs and VBOs.

*points at Xmas' very informative post a few posts above*

it explains the matter quite well. my post, OTOH, was more of a skin-deep sarcasm.