Dirk Reiners wrote:
> 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.
Since we have a lot of dynamic geometry, we do a fair bit of runtime
computation (normals, tangents, bitangents) and geometry update.
Billboarding and skinning is done on the CPU for us as well (currently).
Those functions are candidates for SSE/ET, because we can't move them to
the GPU that easily, currently.
We also do a fair bit of simpler math (project a point on a line,
compute distance), that isn't time-critical, since each function is run
1-5 times/frame. For that math, a simple, useful, math lib is better,
since non-wizards are able to work with it.
>>>> 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. ;)
Yup, but that's dangerous as we have to make sure all OpenSG-code does
it right with that #define enabled.
>> 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.
I don't think OpenGL can assemble data efficiently like that.
We don't have a lot of SSE-experience, but i'd expect to be able to use
it a little bit anyway, to do linear ops.
> Does SIMD really pay off if you have to do that?
It still could give you 3x the floating-point performance. And the
fourth value could be useful for other things (generic attributes,
double texcoords, etc).
>> 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)
>
> Can you give a little bit more info on 1 vs. 2?
For 1:
* Separate color/vec/pnt.
* Very little template code. (no expression templates):
* Simple error messages.
* Fast compilation.
* Resonably small user code, if not 100% efficient.
* Most class member functions exported from dll (not in inline code).
* "Nice" functions that does what you expect (pnt/vec * matrix), etc.
* Used for all math that is not very time-critical.
For 2:
* Single vec type for color/vec/pnt with all possible math ops.
(glsl-equivalent).
* Bleeding fast, takes ages to compile, horrible error messages.
* Used in a few places (calcnormals, etc..)
* Converts easily to 1 classes.
Does it make sense?
I'm just venting my thoughts here. If you think 2 is the way to go,
please do.
Cheers,
/Marcus
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
