<div class="gmail_quote">On 5 February 2012 07:47, Sean Cavanaugh <span dir="ltr"><<a href="mailto:WorksOnMyMachine@gmail.com">WorksOnMyMachine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Looks good so far:<br>
<br>
  it could use float[2] code wherever there is float[3] code (magnitude2 etc)<br></blockquote><div><br></div><div>Yep, I intended to do this. You'll see I added dot2, I just didin't add the others yet :P</div><div>
<br></div><div>Note: this is FAR from complete, I just wanted to get initial opinions before I took it too far.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 any/all should have template overloads to let you specificy exactly which channels match, and simple hardcoded ones for the common cases (any1, any2, any3, any4 aka the default 'any')<br></blockquote><div><br></div>
<div>... I'll look into it again more closely, but I don't think I can bring myself to do this. It's ONLY really possible on SSE. Something so expensive shouldn't be in the base API I don't think.</div>
<div>The only case where this operation is particular common is working with 3d vectors. In my experience (fairly extensive, on many architectures) you will almost always have 0's or 1's in the W anyway, which you can control the mask by choosing greater or greater-equal. With careful consideration, you can achieve this at zero cost, and not providing that API leads you to consider such a construct.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have implementations of floor/ceil/round(to-even) that work on pre-SSE4 hardware for float and doubles I can give out they are fairly simple, as well as the main transcendentals (pow, exp, log, sin, cos, tan, asin, acos, atan).  sinh and cosh being the only major ones I left out.<br>
</blockquote><div><br></div><div>I did plan to add all of these, just haven't gotten to it. You're more than welcome to contribute your implementations.</div><div>I recommend a sincos() functions (and friends) as well. Assuming you implement them as a taylor series, it's more efficient to calculate both at once, and it's rare that you ever call one and not the other.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just need a place or address to post or mail the code.</blockquote><div><br></div><div>Pull request? :)</div>
<div>Or email me: turkeyman at gmail</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> D should be able to handle names and overloading better, though giving everything unique names was the design choice I made for my library, primarily to make the code searchable and potentially portable to C (aside from the heavy use of const references as argument types).</blockquote>
<div><br></div><div>/agree, but the names I've used are so standardised and expected, that I'm really apprehensive to use different names.</div><div>Need more opinions to make a good decision, but currently I'm leaning heavily towards keeping it how it is.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2/4/2012 1:57 PM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
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></div><div class="im">
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></div><div class="im">
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></div><div class="im">
My key concern is with my function names... should I be worried about<br></div><div class="im">
name collisions in such a low level lib? I already shadow a lot of<br>
standard float functions...<br></div><div class="im">
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>
<br>
Opinions? Shall I continue as planned?<br>
</div></blockquote>
<br>
</blockquote></div><br>