Hi, On Mon, 2007-10-01 at 09:31 -0500, Dirk Reiners wrote: > Hi All, > > this is the other split thread that came out of the boost::function > start. Let's try to keep the subjects separate. I was tempted to restart > the thread, but that would lose the connection to the start discussion, > so I didn't do it. > > Marcus Lindblom wrote: > > > > Yeah. Expression templates are kool. :) I suppose it will be better with > > C++0x and Concepts. However, clever use of +=/*= leads to efficient code > > too, without long compile times and horrible error messages. > > At this point I would like to ask a general question for the users: how > many of you actually do vec/pnt operations on properties? Do you > dynamically change the values of whole vertex arrays? I'm not talking > about preprocessing, which is usually not that time-critical, but actual > work in the running program? How many create the geometry dynamically or > regenerate it on a regular basis? > > My suspicion is that most people set up their scene once and then just > render it and move objects around, but I might be wrong.
> >>> For instance, if you want peak performance, you should not have > >>> zero-initializing default ctors for vec/pnt classses. > >> that is true but changing this won't make us any friend ;-) > > > > I'd love you more if you did. :) But I think you're right. :) > > We could have a define for it OSG_INSANELY_FAST_BUT_VERY_DANGEROUS or > something like it. ;) My feeling is that actually it would not be that dangerous. How often do you rely on an initialised vectors/points. Most of the code assigns values rather than starting from 0,0,0 and than go on mathematically. Where initialisation is more critical IMHO are matrices. > > Also, perhaps it would make sense to make a Simd4f-class (that has it's > > MFSimd4f and GeoProp, and perhaps a Simd2d / Simd8ub, etc) for that > > extra over-teh-top speed. :) > > The 4f part is the one that bothers me a bit. 90% of the vectors we use > are 3d, so either we have to do weird stuff like have x,y and z in > separate arrays or we have to tack on a 4th element that is not used. > Does SIMD really pay off if you have to do that? The problem is that we have conflicting layout constraints. SIMD and OpenGL. Both influence the memory layout and if values should be implicit or explicit. Let's see if there is a reasonable way to combine these. But I just started working with SIMD so it will take a second to let it settle to get to some conclusions. > > Anyway, I think I'm rooting at some way to separate these concerns a bit > > so that one could focus fully on each: > > > > * Default user-friendly lib with most code inside a dll > > * Expression template lib > > * SIMD stores (so that one at least avoids copies) > SIMD stores should be nearly available in 2.x (at least for mfields). I recently changed the mfield interface to support custom allocators. I will drop in the aligned allocator I have lying around, so you get the proper memory alignment. The only question left would be how to get the data out as __m128, except the ugly cast you can do right now. But as we already have a split between storage and functional interface that should be straight forward. I can give it a try for the stuff that already maps to simd without problems, e.g. all the 4x vector with the right size. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
