If you want D to gain a great advantage (at least for games) over modern c++
compilers  I believe it would be a smart move to add a built in type for float4
(and I guess double2 for completeness.)

CPU support for these types is getting to be pretty ubiquitous and making them built-in has all the advantages of c++ intrinsics and far more besides:

1. consistency across implementations

2. native support for constants

3. debug and release code won't have the huge (order of magnitude) speed disparity that they do in the c++ method. In c++ it is really a pre-requisite to make a class wrapper for the intrinsic functions because they are entirely un-usable in their native form. This works fine but a vector add, for example, calls a 12 instruction function in a debug build and in a release build is a single vector instruction. Trying to debug a 60fps game at 10fps is a royal pain in the arse.

4. the possibility of adding built-in support for vector swizzling/write masking/element access (a la Cg/HLSL) although I guess this is rather contencious

I would be inclined make dot3, dot4, cross, etc. into intrinsic functions rather than trying to invent dodgy operators for them.

Another issue that arises is the ability to keep temporary single scalar results in a vector register so that they don't keep being transferred to and from FPU registers. Would the optimizer be able to factor this problem away, or would an explicit float1 (or whatever) type be better?

Si

+1

D already has very clean access to OpenGL and other C libraries. Having a vector type along with some good standard vector/matrix libraries will draw a lot of game developers. Game developers are an interesting bunch. We typically have terrible time constraints to construct bleeding edge technology that is supposed to run real-time on a wide performance range of computers.


Simon Hobbs wrote:
> If you want D to gain a great advantage (at least for games) over modern c++
> compilers  I believe it would be a smart move to add a built in type for float4
> (and I guess double2 for completeness.)
> 
> CPU support for these types is getting to be pretty ubiquitous and making them
> built-in has all the advantages of c++ intrinsics and far more besides:
> 
> 1. consistency across implementations
> 
> 2. native support for constants
> 
> 3. debug and release code won't have the huge (order of magnitude) speed
> disparity that they do in the c++ method. In c++ it is really a pre-requisite to
> make a class wrapper for the intrinsic functions because they are entirely
> un-usable in their native form. This works fine but a vector add, for example,
> calls a 12 instruction function in a debug build and in a release build is a
> single vector instruction. Trying to debug a 60fps game at 10fps is a royal pain
> in the arse.
> 
> 4. the possibility of adding built-in support for vector swizzling/write
> masking/element access (a la Cg/HLSL) although I guess this is rather
> contencious
> 
> I would be inclined make dot3, dot4, cross, etc. into intrinsic functions rather
> than trying to invent dodgy operators for them.
> 
> Another issue that arises is the ability to keep temporary single scalar results
> in a vector register so that they don't keep being transferred to and from FPU
> registers. Would the optimizer be able to factor this problem away, or would an
> explicit float1 (or whatever) type be better?
> 
> Si
> 
> 
> 

The language already supports vector operations on arrays of floats, doubles, or anything else. Currently, however, it is not implemented in the compiler.

"Simon Hobbs" <Simon_member@pathlink.com> wrote in message news:c851kq$v01$1@digitaldaemon.com...
> If you want D to gain a great advantage (at least for games) over modern
c++
> compilers  I believe it would be a smart move to add a built in type for
float4
> (and I guess double2 for completeness.)

Simon Hobbs wrote:

> If you want D to gain a great advantage (at least for games) over modern
> c++
> compilers  I believe it would be a smart move to add a built in type for
> float4 (and I guess double2 for completeness.)

Does float4 have value or reference semantics?
I don't think I'd use a float4 myself since I'm not a game programmer but it
has repeatedly come up about using (shortish) arrays with value semantics.
Some generic "static array with value-semantics" would be cool. Right now
to get something like it I'm using a struct with the type and length as
template parameters. It works fine but is verbose.

> CPU support for these types is getting to be pretty ubiquitous and making them built-in has all the advantages of c++ intrinsics and far more besides:
> 
> 1. consistency across implementations
> 
> 2. native support for constants
> 
> 3. debug and release code won't have the huge (order of magnitude) speed disparity that they do in the c++ method. In c++ it is really a pre-requisite to make a class wrapper for the intrinsic functions because they are entirely un-usable in their native form. This works fine but a vector add, for example, calls a 12 instruction function in a debug build and in a release build is a single vector instruction. Trying to debug a 60fps game at 10fps is a royal pain in the arse.
> 
> 4. the possibility of adding built-in support for vector swizzling/write masking/element access (a la Cg/HLSL) although I guess this is rather contencious
> 
> I would be inclined make dot3, dot4, cross, etc. into intrinsic functions rather than trying to invent dodgy operators for them.
> 
> Another issue that arises is the ability to keep temporary single scalar results in a vector register so that they don't keep being transferred to and from FPU registers. Would the optimizer be able to factor this problem away, or would an explicit float1 (or whatever) type be better?
> 
> Si

> Does float4 have value or reference semantics?
> I don't think I'd use a float4 myself since I'm not a game programmer but it
> has repeatedly come up about using (shortish) arrays with value semantics.
> Some generic "static array with value-semantics" would be cool. Right now
> to get something like it I'm using a struct with the type and length as
> template parameters. It works fine but is verbose.

I would like to not care when passing it around and trust the compiler to make the fastest decision for me. I have tons of c++ code that looks something like this:

void doSomething(const float3& vecA)

I pass by const reference because I am assuming it will be faster, but in some  cases it just might not be. Who knows and I don't really care how it is passed as long as it is the fastest way possible.

As for (shortish), I regulary use float2,float3,float4, and float16. float16 is for a 4x4 matrix, but that could just be 4 float4 and be just as efficient. So I think 2,3,4 lengths would give you 99% of the value for vector types (as far as game development is concerned).

Hi

Did you read my post on Einstein notation ??

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/288

Would that be useful for game developers ??

I have been thinking that you could drop the index[] notation in my first post and just define the slice at first contact.

Like

v2[i=0..3]=m[i][k=0..5]*v1[k];

for 4x6 matrix multiplication

or

det=M[0][i=0..3]*M[1]*[j=0..3]*M[2][k=0..3]*M[3][l=0..3]*P(i,j,k,l);

to compute the determinant for 4x4 matrix.

Billy Zelsnack wrote:

>> Does float4 have value or reference semantics?
>> I don't think I'd use a float4 myself since I'm not a game programmer but
>> it has repeatedly come up about using (shortish) arrays with value
>> semantics. Some generic "static array with value-semantics" would be
>> cool. Right now to get something like it I'm using a struct with the type
>> and length as template parameters. It works fine but is verbose.
> 
> I would like to not care when passing it around and trust the compiler to make the fastest decision for me. I have tons of c++ code that looks something like this:
> 
> void doSomething(const float3& vecA)
> 
> I pass by const reference because I am assuming it will be faster, but in some  cases it just might not be. Who knows and I don't really care how it is passed as long as it is the fastest way possible.
> 
> As for (shortish), I regulary use float2,float3,float4, and float16. float16 is for a 4x4 matrix, but that could just be 4 float4 and be just as efficient. So I think 2,3,4 lengths would give you 99% of the value for vector types (as far as game development is concerned).

Reference or value semantics makes a difference with code like
 float4 x,y;
 ...
 x[0] = 2.0; // or whatever the syntax is for an element of x
 y = x;
 y[0] = 1.0;

What is x[0]? reference semantics says 1.0, value semantics says 2.0.
Similarly with reference semantics you need to be careful with
  float4 doSomething() {
    float4 res;
    ...
    return res;
  }
unless the memory for "res" is either passed in as an input or allocated
from the heap or something like that.

-Ben

Walter wrote:

> The language already supports vector operations on arrays of floats, doubles, or anything else. Currently, however, it is not implemented in the compiler.
> 
> "Simon Hobbs" <Simon_member@pathlink.com> wrote in message news:c851kq$v01$1@digitaldaemon.com...
>> If you want D to gain a great advantage (at least for games) over modern
> c++
>> compilers  I believe it would be a smart move to add a built in type for
> float4
>> (and I guess double2 for completeness.)

Walter, do you know much about Cg? I was just poking around the nvidia site reading the spec and it looks like they have some interesting ideas to avoid aliasing (inout is copy-in-copy-out, no pointers, etc) that could be nifty to pull into D.

I have implemented Cg's float2 float3 and float4 classes in D they're exactly like Cg

I suggest people just use the standard pioneered by Microsoft and Nvidia for the
vector format :-)
if we can build it into the compiler, great

download it here (it's GPL right now, but as the author I'm willing to relicense
it at your request)
http://cvs.sourceforge.net/viewcvs.py/deliria/deliria/vec.d

http://cvs.sourceforge.net/viewcvs.py/deliria/deliria/matrix.d


In article <c851kq$v01$1@digitaldaemon.com>, Simon Hobbs says...
>
>If you want D to gain a great advantage (at least for games) over modern c++
>compilers  I believe it would be a smart move to add a built in type for float4
>(and I guess double2 for completeness.)
>
>CPU support for these types is getting to be pretty ubiquitous and making them built-in has all the advantages of c++ intrinsics and far more besides:
>
>1. consistency across implementations
>
>2. native support for constants
>
>3. debug and release code won't have the huge (order of magnitude) speed disparity that they do in the c++ method. In c++ it is really a pre-requisite to make a class wrapper for the intrinsic functions because they are entirely un-usable in their native form. This works fine but a vector add, for example, calls a 12 instruction function in a debug build and in a release build is a single vector instruction. Trying to debug a 60fps game at 10fps is a royal pain in the arse.
>
>4. the possibility of adding built-in support for vector swizzling/write masking/element access (a la Cg/HLSL) although I guess this is rather contencious
>
>I would be inclined make dot3, dot4, cross, etc. into intrinsic functions rather than trying to invent dodgy operators for them.
>
>Another issue that arises is the ability to keep temporary single scalar results in a vector register so that they don't keep being transferred to and from FPU registers. Would the optimizer be able to factor this problem away, or would an explicit float1 (or whatever) type be better?
>
>Si
>
>
>

First of all I'd like to say that if walter wishes to integrate my vec.d into his language he can have it under the BSD license or another license if he wants to talk to me about it. Other users must talk to me about changing the license but I'm quite flexible.

I was a bit brief about how my float2 float3 and float4 work in http://cvs.sourceforge.net/viewcvs.py/deliria/deliria/vec.d

but it's almost exactly like the Cg spec except for a few caveats
a) as you can see in my posts before I was complaining that the opCmp operator
must only return an int hence I can't do the 4-way < and > and ==
comparisons...so I use the dot product to get a partial ordering
b) you can still do component-wise compares using the opLess and opGreater and
opLEqual and so forth.
c) you can assign using the swizzle operators
float4 myvar=float4(1,2,3,4);
float3 mytmp.yzx = myvar.zyx;
..
d) you cannot repeat letters in the swizzle operators unless you are on gdc
because digital mars' link.exe has a bug that crashes if too many functions are
defined in a single file
float3 mytmp.xyz = myvar.zyz; <-- only works if you define Swizzle as a compiler
flag
otherwise the alternative is
float3 mytmp.xyz = myvar.swizzle(2,1,2);
it's just as powerful a syntax and only necessary if you repeat components.

e) I have provided real2 real3 and real4 and double2 double3 and double4 vectors.

f) I welcome contributions to the lib... and especially benchmarking of it.
g) I have provided all the intrinsic functions within Cg (cos, lerp, etc)--they
also work on the intrinsic float,double and real types.
h) this lib really pushes the digital mars compiler to its limit--adding one or
two functions causes the linker to crash under windows.
of course gdc is golden
i) The lib is created using a single template class and a *lot* of
instantiations of that class (so the user mustn't type vec!(real,4)  of course
that syntax works as well)
--Daniel


In article <c86boa$2r88$1@digitaldaemon.com>, hellcatv@hotmail.com says...
>
>I have implemented Cg's float2 float3 and float4 classes in D they're exactly like Cg
>
>I suggest people just use the standard pioneered by Microsoft and Nvidia for the
>vector format :-)
>if we can build it into the compiler, great
>
>download it here (it's GPL right now, but as the author I'm willing to relicense
>it at your request)
>http://cvs.sourceforge.net/viewcvs.py/deliria/deliria/vec.d
>
>http://cvs.sourceforge.net/viewcvs.py/deliria/deliria/matrix.d
>
>
>In article <c851kq$v01$1@digitaldaemon.com>, Simon Hobbs says...
>>
>>If you want D to gain a great advantage (at least for games) over modern c++
>>compilers  I believe it would be a smart move to add a built in type for float4
>>(and I guess double2 for completeness.)
>>
>>CPU support for these types is getting to be pretty ubiquitous and making them built-in has all the advantages of c++ intrinsics and far more besides:
>>
>>1. consistency across implementations
>>
>>2. native support for constants
>>
>>3. debug and release code won't have the huge (order of magnitude) speed disparity that they do in the c++ method. In c++ it is really a pre-requisite to make a class wrapper for the intrinsic functions because they are entirely un-usable in their native form. This works fine but a vector add, for example, calls a 12 instruction function in a debug build and in a release build is a single vector instruction. Trying to debug a 60fps game at 10fps is a royal pain in the arse.
>>
>>4. the possibility of adding built-in support for vector swizzling/write masking/element access (a la Cg/HLSL) although I guess this is rather contencious
>>
>>I would be inclined make dot3, dot4, cross, etc. into intrinsic functions rather than trying to invent dodgy operators for them.
>>
>>Another issue that arises is the ability to keep temporary single scalar results in a vector register so that they don't keep being transferred to and from FPU registers. Would the optimizer be able to factor this problem away, or would an explicit float1 (or whatever) type be better?
>>
>>Si
>>
>>
>>
>
>