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.
