<div class="gmail_quote">On 5 February 2012 01:35, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch">timon.gehr@gmx.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 02/04/2012 08:57 PM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I've been trying to collate a sensible framework for a standard<br>
cross-platform simd module since Walter added the SIMD stuff.<br>
I'm sure everyone will have a million opinions on this, so I've drawn my<br>
approach up to a point where it properly conveys the intent, and I've<br>
proven the code gen works, and is good. Now I figure I should get<br>
everyone to shoot it down before I commit to the tedious work filling in<br>
all the remaining blanks.<br>
<br>
(Note: I've only written code against GDC as yet, since DMD's SSE only<br>
supports x64, and x64 is not supported in Windows)<br>
<a href="https://github.com/TurkeyMan/phobos/blob/master/std/simd.d" target="_blank">https://github.com/TurkeyMan/<u></u>phobos/blob/master/std/simd.d</a><br>
<br>
The code might surprise a lot of people... so I'll give a few words<br>
about the approach.<br>
<br>
The key goal here is to provide the lowest level USEFUL set of<br>
functions, all the basic functions that people actually use in their<br>
algorithms, without requiring them to understand the quirks of various<br>
platforms vector hardware.<br>
Different SIMD hardware tends to have very different shuffling,<br>
load/store, component addressing, support for more/less of the primitive<br>
maths operations, etc.<br>
This library, which is the lowest level library I expect programmers<br>
would ever want to use in their apps, should provide that API at the<br>
lowest useful level.<br>
<br>
First criticism I expect is for many to insist on a class-style vector<br>
library, which I personally think has no place as a low level, portable API.<br>
Everyone has a different idea of what the perfect vector lib should look<br>
like, and it tends to change significantly with respect to its application.<br>
<br>
I feel this flat API is easier to implement, maintain, and understand,<br>
and I expect the most common use of this lib will be in the back end of<br>
peoples own vector/matrix/linear algebra libs that suit their apps.<br>
<br>
My key concern is with my function names... should I be worried about<br>
name collisions in such a low level lib? I already shadow a lot of<br>
standard float functions...<br>
</blockquote>
<br></div></div>
That is not really an issue. If it actually bothers someone, static or named imports come to the rescue.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I prefer them abbreviated in this (fairly standard) way, keeps lines of<br>
code short and compact. It should be particularly familiar to anyone who<br>
has written shaders and such.<br>
</blockquote>
<br></div>
I agree.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Opinions? Shall I continue as planned?<br>
</blockquote>
<br></div>
Looks good. I think it should provide emulation in case of non-existent hardware support (maybe even with a possibility to opt-out).<br>
</blockquote></div><br><div>It will, although I'm still not clear on how far to take that... in some cases, simply not supporting the feature for their hardware encourages them to implement a different solution, which they should do on such a system.</div>
<div>I also intend to support float[N] for those systems with no vector hardware. It's important to the API that float[4] and native vectors are not implicitly interchangeable though, this is a major performance hazard which the API should not encourage.</div>