Quoting IOhannes m zmoelnig zmoelnig@iem.at:
naively i have assumed that all arrays are of the same dimension, which is not true; texCoordArray is [Nx2] and normalArray is [Nx3], the rest is [Nx4]; this is certainly more memory-efficient.
however, i would propose to unify all arrays to [Nx4];
This is not going to work well because OpenGL wants the arrays in very specific formatting. A loop to rearrange arrays before uploading would be a performance killer. In fact, profiling the vertex_ stuff shows that a lot of time is spent uploading the data to the card through the driver. There are supposedly ways to DMA this and/or eliminate driver copies, but I haven't gotten them to work. The best advice I can give is to find the best (fastest) array format for GL and stick to it religiously. The vertex_stuff has the potential for some very heavy shit and all of the fat has to be trimmed to make the paths as fast and unencumbered as possible.
Specifics:
why ?
- i can apply a single processVertex-function to all arrays without
having to know anything about the type of data (this reminds me strongly of the "generalized 3d shape synthesizer")
It's a good idea, but the sacrifice of performance for flexibility might be far to great to have a usable system in the end.
- there shouldn't be a problem with memory nowadays.
GEM is very memory efficient, but take a look at what I had to do with vertex_model - there is a cached copy of the model. This could potentially put some strain on memory in certain cases like my Powerbook that has 1GB max RAM, which is even on the high side as far as laptops go.
- operations on the normalArray is probably faster than with [Nx3]
(given that SIMD needs aligned memory)
Honestly, I don't forsee doing a whole lot of normal processing. But take heart, because even though the 96 bit wide data isn't ideal for SIMD it can be dealt with efficiently. Here's how:
while (count < max){
//interleave the float and vector ops
//vector float vertex = vec_madd(vertex,scale,offset);
//vector int color = vec_adds(color,color_offset);
//float normal = normal * scale;
//vector float texcoord = vec_madd();
}
Here the super-scalar architecture would still issue these operations immediately as there would be nothing in the pipeline (ideal case) before them and no dependencies either. The only possible stall would be from a dependency for the texcoord from a vertex op or the vertex op could not be pipelined. Subsequent ops would have to be pipelined as always but at the very least all ops would be issued immediately. Something like a PPC 970 could really crank on this with it's dual FPUs (although the float and int vector units share the same resources which may or may not be problematic).
I think the arrays should remain specific to their data types for the most efficient handling of them. The real-time nature of GEM pretty much demands this.
_sources_: OBJ-loader, grid, quad, supershape, random, sphere,... _sinks_: draw, OBJ-exporter _manips_(with only a lefthand gemlist): add(=offset), scale, set, matrix-multiplication, rotation _manips2_(with 2 gemlists): add, mul, set, blend _misc_: info, merge (e.g. take array1 of gemlist1 as color and array4 of gemlist2 as vertex)
That's pretty close to my original list, although I favor having more non-standard sources like the supershape rather than the usual Geo primitives. The OBJ exporter can use the already provided code we use for importing the models.
Also, it is possible to use vertex arrays in display lists, so that might make for a nice option.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.