Hey chaps (and possibly lasses?)
I've been slowly working a std.simd library, the aim of which is to provide
a lowest-level hardware-independent SIMD interface. core.simd implements
SSE currently for x86, other architectures are currently exposed via
gcc.builtins.
The purpose of std.simd,
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,
On Thu, 15 Mar 2012 12:09:58 -0500, Manu wrote:
Hey chaps (and possibly lasses?)
I've been slowly working a std.simd library, the aim of which is to
provide
a lowest-level hardware-independent SIMD interface. core.simd implements
SSE currently for x86, other architectures are curr
On 15 March 2012 20:35, Robert Jacques wrote:
> On Thu, 15 Mar 2012 12:09:58 -0500, Manu wrote:
>
>> Hey chaps (and possibly lasses?)
>>
>> I've been slowly working a std.simd library, the aim of which is to
>> provide
>> a lowest-level hardware-indepen
's
> a problem for a higher layer of library.
> I really feel it's important to keep std.simd STRICTLY about the hardware
> simd operations, only implementing what the hardware can express
> efficiently, and not trying to emulate anything else. In some areas I feel
> I've a
Great to hear this is coming along. Can I get a link to the
(github?) source?
Do the simd functions have fallback functionally for unsupported
hardware? Is that planned? Or is that something I'd be writing
into my own Vector structures?
Also, I noticed Phobos now includes a "etc" library, do
On 16 March 2012 11:14, F i L wrote:
> Great to hear this is coming along. Can I get a link to the (github?)
> source?
>
> Do the simd functions have fallback functionally for unsupported hardware?
> Is that planned? Or is that something I'd be writing into my own Vector
> structures?
>
> Also, I
(or an equivalent enum to the effect)
> >
> >
> > I can see how you come to that conclusion, but I generally feel that
> that's
> > a problem for a higher layer of library.
> > I really feel it's important to keep std.simd STRICTLY about the hardware
> &g
On 16 March 2012 00:14, F i L wrote:
> Do the simd functions have fallback functionally for unsupported hardware?
> Is that planned? Or is that something I'd be writing into my own Vector
> structures?
I am thinking more and more that it'll have fallback for unsupported
hardware (since the same
elf, the killer feature
>> >> for
>> >> such a library would be have the CUDA compatible alignments for the
>> >> types.
>> >> (or an equivalent enum to the effect)
>> >
>> >
>> > I can see how you come to that conclusion, but I
On Thu, 15 Mar 2012 14:02:15 -0500, Manu wrote:
On 15 March 2012 20:35, Robert Jacques wrote:
On Thu, 15 Mar 2012 12:09:58 -0500, Manu wrote:
[snip]
This sounds reasonable. However, please realize that if you wish to use
the short vector names (i.e. float4, float3, float2, etc) you should
s
r layer of library.
>>
>
> Then you should to leave namespace room for that higher level library.
>
I haven't stolen any names that aren't already taken by core.simd. I just
want to claim those primitive types already aliased in std.simd to enhance
them with some more useful base-level functionality.
If at some point you want to mix types from both modules, you
could always use static or renamed imports. For example, »import
lowlevel = std.simd« would give you »lowlevel.float4
upVector;«, which might be clearer in the context of your
application than any longer, pre-defined name could ever be.
e, »import lowlevel =
std.simd« would give you »lowlevel.float4 upVector;«, which might be
clearer in the context of your application than any longer, pre-defined
name could ever be.
True, we shouldn't generally pick very likely-to-collide names by
default just because we can so,
it happening. Above the most primitive level that
I've tried to cover with std.simd, I think it'll be very hard to find
agreement on what that API should look like.
If you can invent a proposal that everyone agrees on, I'd be very
interested to see it. Perhaps if you extend the fairly r
an example of a non-simd context where this is the case?
Don't say shaders, because that is supported in hardware, and that's my
point.
Also there's nothing stopping a secondary library adding/emulating the
additional types. They could work seamlessly together. flaot4 may come from
s
t.
>> Also there's nothing stopping a secondary library adding/emulating the
>> additional types. They could work seamlessly together. flaot4 may come
>> from
>> std.simd, float3/float2 may be added by a further lib that simply extends
>> std.simd.
>>
>
I'm thinking of implementation std.simd in fashion different to
https://github.com/TurkeyMan/simd
since it looks dead and too sophisticated.
My proposal is:
- std.simd - processor independent intrinsics and some high
level stuff.
You only depend on different sizes of SIMD v
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
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
applicati
On 5 February 2012 01:35, Timon Gehr 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
>>
On 5 February 2012 02:17, Martin Nowak wrote:
> 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 ten
On 2/4/2012 11:57 AM, Manu wrote:
My key concern is with my function names... should I be worried about name
collisions in such a low level lib?
No. D's module resolution is good enough that prefixing names is not D-style and
is to be avoided.
I prefer them abbreviated in this (fairly stan
On 5 February 2012 02:55, Walter Bright wrote:
> On 2/4/2012 11:57 AM, Manu wrote:
>
>> My key concern is with my function names... should I be worried about name
>> collisions in such a low level lib?
>>
>
> No. D's module resolution is good enough that prefixing names is not
> D-style and is to
Let me restate the main point.
Your approach to a higher level module wraps intrinsics with named
functions.
There is little gain in making simd(AND, f, f2) to and(f, f2) when you can
easily take this to the level GLSL achieves.
On 5 February 2012 03:08, Martin Nowak wrote:
> Let me restate the main point.
> Your approach to a higher level module wraps intrinsics with named
> functions.
> There is little gain in making simd(AND, f, f2) to and(f, f2) when you can
> easily take this to the level GLSL achieves.
>
What is m
On 02/05/2012 02:03 AM, Manu wrote:
On 5 February 2012 02:55, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
On 2/4/2012 11:57 AM, Manu wrote:
My key concern is with my function names... should I be worried
about name
collisions in such a low level lib?
Am 05.02.2012, 02:13 Uhr, schrieb Manu :
On 5 February 2012 03:08, Martin Nowak wrote:
Let me restate the main point.
Your approach to a higher level module wraps intrinsics with named
functions.
There is little gain in making simd(AND, f, f2) to and(f, f2) when you
can
easily take this to
On 5 February 2012 03:37, Martin Nowak wrote:
> Am 05.02.2012, 02:13 Uhr, schrieb Manu :
>
>
> On 5 February 2012 03:08, Martin Nowak wrote:
>>
>> Let me restate the main point.
>>> Your approach to a higher level module wraps intrinsics with named
>>> functions.
>>> There is little gain in ma
Am 05.02.2012, 02:46 Uhr, schrieb Manu :
On 5 February 2012 03:37, Martin Nowak wrote:
Am 05.02.2012, 02:13 Uhr, schrieb Manu :
On 5 February 2012 03:08, Martin Nowak wrote:
Let me restate the main point.
Your approach to a higher level module wraps intrinsics with named
functions.
Th
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 t
On 2/4/2012 7:37 PM, Martin Nowak wrote:
Am 05.02.2012, 02:13 Uhr, schrieb Manu :
On 5 February 2012 03:08, Martin Nowak wrote:
Let me restate the main point.
Your approach to a higher level module wraps intrinsics with named
functions.
There is little gain in making simd(AND, f, f2) to and(
Looks good so far:
it could use float[2] code wherever there is float[3] code
(magnitude2 etc)
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')
I ha
Looks good to me so far ;-)
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 w
On 5 February 2012 07:47, Sean Cavanaugh wrote:
>
> Looks good so far:
>
> it could use float[2] code wherever there is float[3] code (magnitude2
> etc)
>
Yep, I intended to do this. You'll see I added dot2, I just didin't add the
others yet :P
Note: this is FAR from complete, I just wanted to
On 5 February 2012 09:22, F i L wrote:
> Looks good to me so far ;-)
>
> 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 shoul
On Saturday, 4 February 2012 at 23:15:17 UTC, Manu wrote:
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 te
On 6 February 2012 10:49, a wrote:
> On Saturday, 4 February 2012 at 23:15:17 UTC, Manu wrote:
>
> 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 th
True, I have only been working in x86 GDC so far, but I just
wanted to get
feedback about my approach and API design at this point.
It seems there are no serious objections, I'll continue as is.
I have one proposal about API design of matrix operations. Maybe
there could be functions that woul
On 6 February 2012 15:13, a wrote:
>> True, I have only been working in x86 GDC so far, but I just wanted to get
>> feedback about my approach and API design at this point.
>> It seems there are no serious objections, I'll continue as is.
>
>
> I have one proposal about API design of matrix operat
There's a thread in d.gnu with Linux and MinGW cross compiler
binaries.
I didn't know that, thanks.
On 6 February 2012 17:13, a wrote:
> True, I have only been working in x86 GDC so far, but I just wanted to get
>> feedback about my approach and API design at this point.
>> It seems there are no serious objections, I'll continue as is.
>>
>
> I have one proposal about API design of matrix opera
used like this (a* are inputs and r* are outputs):
transpose(aX, aY, aZ, aW, rX, rY, rZ, rW);
... the problem is, without multiple return values (come on, D
should have
multiple return values!), how do you return the result? :)
Maybe those functions could be used to implement the functions
43 matches
Mail list logo
