On 5 February 2012 03:37, Martin Nowak <d...@dawgfoto.de> wrote: > Am 05.02.2012, 02:13 Uhr, schrieb Manu <turkey...@gmail.com>: > > > On 5 February 2012 03:08, Martin Nowak <d...@dawgfoto.de> wrote: >> >> Let me restate the main point. >>> Your approach to a higher level module wraps intrinsics with named >>> functions. >>> There is little gain in making simd(AND, f, f2) to and(f, f2) when you >>> can >>> easily take this to the level GLSL achieves. >>> >>> >> What is missing to reach that level in your opinion? I think I basically >> offer that (with some more work) >> It's not clear to me what you object to... >> I'm not prohibiting the operators, just adding the explicit functions, >> which may be more efficient in certain cases (they receive the version). >> >> Also the 'gains' of wrapping an intrinsic in an almost identical function >> are, portability, and potential optimisation for hardware versioning. I'm >> specifically trying to build something that's barely above the intrinsics >> here, although a lot of the more arcane intrinsics are being collated into >> their typically useful functionality. >> >> Are you just focused on the primitive math ops, or something broader? >> > > GLSL achieves very clear and simple to write construction and conversion > of values. > > I think wrapping the core.simd vector types in an alias this struct makes > it a snap > to define conversion through constructors and swizzling through > properties/opDispatch. > Then you can overload operands to do the implementation specific stuff and > add named methods > for the rest. >
So you are referring to the light wrapper class, that's what I thought. I think that's overcooking it a bit. Also, you seem to have ignored the reason I created the primitive operator functions twice now. They are needed to take advantage of the hardware with respect to different versions. At the lowest level, I am generally favouring performance over usage (if it doesn't cause serious damage to the API). You're suggesting exactly what I expected half the forum to suggest, and I'm not against it in any way, but I think it's a layer above this. This should remain pure, and performance orientated... There must be a library that provides the opportunity for the best performance, before sugary libs get all layered over the top, and it's as I've said twice now, everyone will have a different idea of what that sugar API will look like, so I feel it should live above this... or perhaps beside this (in the same file?), but I wouldn't want to remove this API in favour of a vector 'class'.