std.simd module

Martin Nowak dawg at dawgfoto.de
Sat Feb 4 17:37:13 PST 2012


Am 05.02.2012, 02:13 Uhr, schrieb Manu <turkeyman at gmail.com>:

> On 5 February 2012 03:08, Martin Nowak <dawg at 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.


More information about the Digitalmars-d mailing list