<div class="gmail_quote">On 5 February 2012 03:08, 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">
Let me restate the main point.<br>
Your approach to a higher level module wraps intrinsics with named 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>
</blockquote></div><br><div>What is missing to reach that level in your opinion? I think I basically offer that (with some more work)</div><div>It's not clear to me what you object to...</div><div>I'm not prohibiting the operators, just adding the explicit functions, which may be more efficient in certain cases (they receive the version).</div>
<div><br></div><div>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.</div>
<div><br></div><div>Are you just focused on the primitive math ops, or something broader?</div>