Interleaved or tightly-packed VertexArrays?
Post: #1
Which is better? Interleaved or packed for vertexArrays? by how much?
---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Post: #2
I actually benchmarked this to find out, and discovered that there was no noticeable difference between vertex formats.
Post: #3
Does it matter if I waste space with a wide stride?
e.g. pass a struct like this:
Am I wasting space on the card if I do this?
e.g. pass a struct like this:
Code:
struct Vertex {
Vector2f tex;
Vector3f norm;
Vector3f loc;
int someOther junk;
int moreJunk;
public:
...
};
...
Vertex *verts = new Vertex[someArrayLength];
glInterleavedArrays(GL_T2F_N3F_V3F, sizeof(Vertex), verts);---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Post: #4
premature optimisation, just profile fix slow bits etc etc
Sir, e^iπ + 1 = 0, hence God exists; reply!
Post: #5
This is more of a memory access pattern issue for your app, updating vertex attributes. In general I think you will get slightly higher performance if you ensure all your writes are tightly packed and in sequential order (some architectures have write combining, so updates to sequential bytes/words may actually be written over the bus in large (i.e. 128 bit) bursts if possible.)
As for wasting space on the GPU-- that is opaque to your app. The internal layout of the GPU copy of vertex data depends on the GPU. The GL framework will copy and/or resort and/or format convert your data as needed, based on what is most efficient for the GPU. In any case, it won't be copying any non-attribute data you interleave in your struct. But the same memory access rules apply, since it has to read your data somehow.
As for wasting space on the GPU-- that is opaque to your app. The internal layout of the GPU copy of vertex data depends on the GPU. The GL framework will copy and/or resort and/or format convert your data as needed, based on what is most efficient for the GPU. In any case, it won't be copying any non-attribute data you interleave in your struct. But the same memory access rules apply, since it has to read your data somehow.
Post: #6arekkusu Wrote:This is more of a memory access pattern issue for your app, updating vertex attributes. In general I think you will get slightly higher performance if you ensure all your writes are tightly packed and in sequential order (some architectures have write combining, so updates to sequential bytes/words may actually be written over the bus in large (i.e. 128 bit) bursts if possible.)perfect. thanks.
As for wasting space on the GPU-- that is opaque to your app. The internal layout of the GPU copy of vertex data depends on the GPU. The GL framework will copy and/or resort and/or format convert your data as needed, based on what is most efficient for the GPU. In any case, it won't be copying any non-attribute data you interleave in your struct. But the same memory access rules apply, since it has to read your data somehow.
---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Post: #7unknown Wrote:premature optimisation, just profile fix slow bits etc etcActually no, I fixed all the other bits. Right now I'm fixing geometry upload performance. So while I'm adding in vertex arrays, etc to the code, knowing what format is particularly relevant.
---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
