<div class="gmail_quote">On 5 February 2012 03:37, Martin Nowak <span dir="ltr"><<a href="mailto:dawg@dawgfoto.de">dawg@dawgfoto.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 05.02.2012, 02:13 Uhr, schrieb Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>>:<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 5 February 2012 03:08, Martin Nowak <<a href="mailto:dawg@dawgfoto.de" target="_blank">dawg@dawgfoto.de</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me restate the main point.<br>
Your approach to a higher level module wraps intrinsics with named<br>
functions.<br>
There is little gain in making simd(AND, f, f2) to and(f, f2) when you can<br>
easily take this to the level GLSL achieves.<br>
<br>
</blockquote>
<br>
What is missing to reach that level in your opinion? I think I basically<br>
offer that (with some more work)<br>
It's not clear to me what you object to...<br>
I'm not prohibiting the operators, just adding the explicit functions,<br>
which may be more efficient in certain cases (they receive the version).<br>
<br>
Also the 'gains' of wrapping an intrinsic in an almost identical function<br>
are, portability, and potential optimisation for hardware versioning. I'm<br>
specifically trying to build something that's barely above the intrinsics<br>
here, although a lot of the more arcane intrinsics are being collated into<br>
their typically useful functionality.<br>
<br>
Are you just focused on the primitive math ops, or something broader?<br>
</blockquote>
<br></div></div>
GLSL achieves very clear and simple to write construction and conversion of values.<br>
<br>
I think wrapping the core.simd vector types in an alias this struct makes it a snap<br>
to define conversion through constructors and swizzling through properties/opDispatch.<br>
Then you can overload operands to do the implementation specific stuff and add named methods<br>
for the rest.<br>
</blockquote></div><div><br></div>So you are referring to the light wrapper class, that's what I thought.<br><div>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.</div>
<div>At the lowest level, I am generally favouring performance over usage (if it doesn't cause serious damage to the API).</div><div>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...</div>
<div>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'.</div>