Should I Use Stl Containers?


hessiess

Member
Joined
Apr 26, 2008
Messages
219
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.
 
Hessiess said:
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.
 
Last edited by a moderator:
darkblu said:
Hessiess said:
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.
 
Last edited by a moderator:
Hessiess said:
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
 
Last edited by a moderator:
Hessiess said:
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.
 
Last edited by a moderator:
darkblu said:
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.
 
Last edited by a moderator:
Xmas said:
darkblu said:
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.

lulzfish said:
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 ™.
 
Last edited by a moderator:
lulzfish said:
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.
 
Last edited by a moderator:
darkblu said:
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.
 
Last edited by a moderator:
Multiplex said:
darkblu said:
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.
 
Last edited by a moderator:
darkblu said:
lulzfish said:
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.
 
Last edited by a moderator:
sinoth said:
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.
 
Last edited by a moderator:
Back
Top