On 5 February 2012 01:35, Timon Gehr <timon.g...@gmx.ch> wrote: > On 02/04/2012 08:57 PM, Manu wrote: > >> So I've been trying to collate a sensible framework for a standard >> cross-platform simd module since Walter added the SIMD stuff. >> I'm sure everyone will have a million opinions on this, so I've drawn my >> approach up to a point where it properly conveys the intent, and I've >> proven the code gen works, and is good. Now I figure I should get >> everyone to shoot it down before I commit to the tedious work filling in >> all the remaining blanks. >> >> (Note: I've only written code against GDC as yet, since DMD's SSE only >> supports x64, and x64 is not supported in Windows) >> https://github.com/TurkeyMan/**phobos/blob/master/std/simd.d<https://github.com/TurkeyMan/phobos/blob/master/std/simd.d> >> >> The code might surprise a lot of people... so I'll give a few words >> about the approach. >> >> The key goal here is to provide the lowest level USEFUL set of >> functions, all the basic functions that people actually use in their >> algorithms, without requiring them to understand the quirks of various >> platforms vector hardware. >> Different SIMD hardware tends to have very different shuffling, >> load/store, component addressing, support for more/less of the primitive >> maths operations, etc. >> This library, which is the lowest level library I expect programmers >> would ever want to use in their apps, should provide that API at the >> lowest useful level. >> >> First criticism I expect is for many to insist on a class-style vector >> library, which I personally think has no place as a low level, portable >> API. >> Everyone has a different idea of what the perfect vector lib should look >> like, and it tends to change significantly with respect to its >> application. >> >> I feel this flat API is easier to implement, maintain, and understand, >> and I expect the most common use of this lib will be in the back end of >> peoples own vector/matrix/linear algebra libs that suit their apps. >> >> My key concern is with my function names... should I be worried about >> name collisions in such a low level lib? I already shadow a lot of >> standard float functions... >> > > That is not really an issue. If it actually bothers someone, static or > named imports come to the rescue. > > > I prefer them abbreviated in this (fairly standard) way, keeps lines of >> code short and compact. It should be particularly familiar to anyone who >> has written shaders and such. >> > > I agree. > > > >> Opinions? Shall I continue as planned? >> > > Looks good. I think it should provide emulation in case of non-existent > hardware support (maybe even with a possibility to opt-out). >
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. 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.