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
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
There's a thread in d.gnu with Linux and MinGW cross compiler
binaries.
I didn't know that, thanks.
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
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 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
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 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 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
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
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
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(
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
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
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: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 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?
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
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 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
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: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 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
>>
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 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
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,
26 matches
Mail list logo
