looks like the ds has a maths CoProssesor in Console Homebrew Forum

Author

Comment

nino1234

looks like the ds has a maths CoProssesor

Lead

[-]

Posts: 1109

(29/12/2005 00:39:26)

genio

Tags : None

Remove this ad

looking through the latest libnds ive just found new defines for a maths coprossesor they look like this.

 #ifndef MATH_ARM9_INCLUDE#define MATH_ARM9_INCLUDE#include <nds/jtypes.h>//  Math coprocessor register definitions#define DIV_CR                                                (*(vuint16*)(0x04000280))#define DIV_NUMERATOR64                (*(vint64*) (0x04000290))#define DIV_NUMERATOR32                (*(vint32*) (0x04000290))#define DIV_DENOMINATOR64        (*(vint64*) (0x04000298))#define DIV_DENOMINATOR32        (*(vint32*) (0x04000298))#define DIV_RESULT64                        (*(vint64*) (0x040002A0))#define DIV_RESULT32                        (*(vint32*) (0x040002A0))#define DIV_REMANDER64                (*(vint64*) (0x040002A8))#define DIV_REMANDER32                (*(vint32*) (0x040002A8))#define SQRT_CR                                                (*(vuint16*)(0x040002B0))#define SQRT_PARAM64                        (*(vint64*) (0x040002B8))#define SQRT_RESULT32                        (*(vint32*) (0x040002B4))#define SQRT_PARAM32                        (*(vint32*) (0x040002B8))//  Math coprocessor modes#define DIV_64_64                        2#define DIV_64_32                        1#define DIV_32_32                        0#define DIV_BUSY                        (1<<15)#define SQRT_64                                1#define SQRT_32                                0#define SQRT_BUSY                        (1<<15)//  Fixed Point versions//  Fixed point divide//  Takes 1.19.12 numerator and denominator//  and returns 1.19.12 resultstatic inline f32 divf32(f32 num, f32 den){        DIV_CR = DIV_64_32;        while(DIV_CR & DIV_BUSY);        DIV_NUMERATOR64 = ((int64)num) << 12;        DIV_DENOMINATOR32 = den;        while(DIV_CR & DIV_BUSY);        return (DIV_RESULT32);}//  Fixed point multiply//        Takes 1.19.12 values and returns//        1.19.12 resultstatic inline f32 mulf32(f32 a, f32 b){        long long result = (long long)a*(long long)b;        return (f32)(result >> 12);}//  Fixed point square root//        Takes 1.19.12 fixed point value and//        returns the fixed point resultstatic inline f32 sqrtf32(f32 a){        SQRT_CR = SQRT_64;        while(SQRT_CR & SQRT_BUSY);        SQRT_PARAM64 = ((int64)a) << 12;        while(SQRT_CR & SQRT_BUSY);        return SQRT_RESULT32;}//  Integer versions//  Integer divide//  Takes a 32 bit numerator and 32 bit//        denominator and returns 32 bit resultstatic inline int32 div32(int32 num, int32 den){        DIV_CR = DIV_32_32;        while(DIV_CR & DIV_BUSY);        DIV_NUMERATOR32 = num;        DIV_DENOMINATOR32 = den;        while(DIV_CR & DIV_BUSY);        return (DIV_RESULT32);}//  Integer divide//  Takes a 32 bit numerator and 32 bit//        denominator and returns 32 bit resultstatic inline int32 mod32(int32 num, int32 den){        DIV_CR = DIV_32_32;        while(DIV_CR & DIV_BUSY);        DIV_NUMERATOR32 = num;        DIV_DENOMINATOR32 = den;        while(DIV_CR & DIV_BUSY);        return (DIV_REMANDER32);}//  Integer divide//        Takes a 64 bit numerator and 32 bit//  denominator are returns 32 bit resultstatic inline int32 div64(int64 num, int32 den){        DIV_CR = DIV_64_32;        while(DIV_CR & DIV_BUSY);        DIV_NUMERATOR64 = num;        DIV_DENOMINATOR32 = den;        while(DIV_CR & DIV_BUSY);        return (DIV_RESULT32);}//  Integer divide//        Takes a 64 bit numerator and 32 bit//  denominator are returns 32 bit resultstatic inline int32 mod64(int64 num, int32 den){        DIV_CR = DIV_64_32;        while(DIV_CR & DIV_BUSY);        DIV_NUMERATOR64 = num;        DIV_DENOMINATOR32 = den;        while(DIV_CR & DIV_BUSY);        return (DIV_REMANDER32);}//  Integer square root//  takes a 32 bit integer and returns//        32 bit resultstatic inline int32 sqrt32(int a){        SQRT_CR = SQRT_32;        while(SQRT_CR & SQRT_BUSY);        SQRT_PARAM32 = a;        while(SQRT_CR & SQRT_BUSY);        return SQRT_RESULT32;}//  Trig Functions  1.19.12 fixed point// Cross product// x = Ay * Bz - By * Az// y = Az * Bx - Bz * Ax// z = Ax * By - Bx * Aystatic inline void crossf32(f32 *a, f32 *b, f32 *result){        result[0] = mulf32(a[1], b[2]) - mulf32(b[1], a[2]);        result[1] = mulf32(a[2], b[0]) - mulf32(b[2], a[0]);        result[2] = mulf32(a[0], b[1]) - mulf32(b[0], a[1]);}// Dot Product// result = Ax * Bx + Ay * By + Az * Bzstatic inline f32 dotf32(f32 *a, f32 *b){        return mulf32(a[0], b[0]) + mulf32(a[1], b[1]) + mulf32(a[2], b[2]);}// Normalize// Ax = Ax / mag// Ay = Ay / mag// Az = Az / magstatic inline void normalizef32(f32* a){        // magnitude = sqrt ( Ax^2 + Ay^2 + Az^2 )        f32 magnitude = sqrtf32( mulf32(a[0], a[0]) + mulf32(a[1], a[1]) + mulf32(a[2], a[2]) );        a[0] = divf32(a[0], magnitude);        a[1] = divf32(a[1], magnitude);        a[2] = divf32(a[2], magnitude);}#endif

now im not sure how a maths coprossesor works but my thinking is that you can mabey do one calc on the coprossesor and one on the cpu thus doing two at once
and this might be good for like perspective correct mapping as it would enable you to smuther out the extra divide per pixel either that or its just a supper fast way of doing divides and stuff.

or am i just beeing stupid?

jimshaw

Re: looks like the ds has a maths CoProssesor

[-]

Posts: 5230

(29/12/2005 09:16:57)

Cool! It looks like there's some parallel division and sqrt hardware. You set off a division, and in the meantime you could do something else (possibly not a divide, but maybe).

Looks like the way it works is
1) set the control register for what kind of command you want.
2) wait for the division (or sqrt) unit to become idle.
3) set the parameters.
4) once the final parameter has been set, the command will begin executing.
5) wait for the division unit to become idle.
6) read the result.

I've marked these steps in the division routine.

// Integer divide
// Takes a 64 bit numerator and 32 bit
// denominator are returns 32 bit result
static inline int32 div64(int64 num, int32 den)
{
DIV_CR = DIV_64_32; (1)

while(DIV_CR & DIV_BUSY); (2)

DIV_NUMERATOR64 = num; (3)
DIV_DENOMINATOR32 = den; (4)

while(DIV_CR & DIV_BUSY);(5)

return (DIV_RESULT32);(6)
}

Obviously there're two places where this routine sucks! (2) and (5) are "busy waits" they're waiting for the hardware to become idle and just "spin" until that happens. This is where a skillful programmer will make up some speed. He will never try to use the unit if it was previously busy ie, eliminating the wait in step (2). And, between steps (4) and (5), he will put some other calculation. How much you can actually do in there will vary with what kind of operation (div, sqrt) you're doing and perhaps what the parameters are (some div's are easy, eg, anything divided by 1 might pop out the hardware real quick!), but it's likely to be in the order of 10s to 100s of instructions.
Taking advantage of this parallel processing is going to be really tough. FYI, the PS1 had hardware that worked like this too (it could do vector dot products on the GTE while other things were happening).

Jim

Bibo ergo sum

nino1234

Re: looks like the ds has a maths CoProssesor

[-]

Posts: 1109

(29/12/2005 15:04:06)

genio

wow! cheers for that jim i had previously over looked the two wait loops but i see what you mean in that its going to be a pain. i wouldnt be supprized to see these functions change and grow in the near future though as they have only just been added.

in future even though i might not need the parrellel processing should i use this unit instead of the cpu its just i cant quite see the benifits of this if i was only doing a single calc on the maths coprocessesor as the cpu would have to wait on the unit returning an answer wouldnt it? unless this unit executed quicker than the cpu in which case it would be worth while.

im going to have to do some test to see if i can get parrellel prossesing going and how well it works.

i know another guy has managed to multithread the arm9 cpu theres a lib been released so who knows what else may become availible / possible with this thing.

jimshaw

Re: Re: looks like the ds has a maths CoProssesor

[-]

Posts: 5230

(30/12/2005 01:16:01)

Remove this ad

Multithreading might help, as long as only one thread uses these new commands. Otherwise you'd never know when to wait and which thread has control of the fpu.

The skill is to come up with two things that can happen at the same time which don't depend on each other at a really fine grained (instruction) level but depend on each other at a block level. On the PS1, you did the geometry in the GTE whilst using the last lot of results to create the triangle packets that got sent to the GPU. That worked extremely well. Of course, you need to do it in asm, and any time you need to make the slightest change to the way the code works you end up re-writing it almost wholesale!

Maybe you could get some milage out of it. Render a few pixels, do a divide, render a few pixels...In Quake for example, the perspective correction was done on 16 pixel spans. ie. Only every 16 pixels was corrected. While those 16 pixels were being written, the divide for the next 16 was going on in the background. But coding that way is tricky at best. I've never tried to achieve it myself.

Also, I see in your GBA demo you're setting up a DMA xfer for every individual pixel. Are you sure that's faster than just the write in plain ordinary C? I would doubt it. But I would expect a massive speed up using it to do the clear screen! That might be hiding the fact you've actually slowed down the pixel writing. The only thing you might have to do if you mix these things is to wait for the DMA screen clear to finish before you write any pixels. Maybe I'm wrong, but it's worth a look.

Jim

Bibo ergo sum

nino1234

Re: Re: looks like the ds has a maths CoProssesor

[-]

Posts: 1109

(30/12/2005 22:08:38)

genio

now you mention it i tried out the gba demo before i used the dma transfer on every scanline pixel and the routine definitly felt faster but i thought i was imagining it but now im thinking i see how these can be slower when used like this as the dma controller has to be activated for every pixel told what to do then wait on it becoming idle before moving to the next pixel and the only reall speed gain is by tranfering lots of pixels at once.the ham lib waits on the controller idling so you can definitly mix the c plotting and the dma tranfer up.

as for these maths defines would it be a good idea to write some tests using the console print functions and seing just how fast diffrent divides operate at?

one more thing if writting a test app will i just count cpu ticks and print out how many ticks it takes to do diffrent combos of divides?

im trying lots of new things with the hardware now to really get to grips with it before i make any new projects.

jimshaw

Re: Re: Re: looks like the ds has a maths CoProssesor

[-]

Posts: 5230

(31/12/2005 01:23:54)

DMA for a scanline or sprite row makes sense, but single pixels I would guess are slower.

The easiest way to do the timing is to do several 100,000 of them in a row, and use the wall clock to time them. Then you can divide by 100,000 to see how long each one took. Make it so that each run takes a few seconds to complete.
Perhaps the C function time() or clock() works? If you try to time a single one, it probably won't be consistent. This way you get an average.

Jim

Bibo ergo sum

nino1234

Re: Re: Re: looks like the ds has a maths CoProssesor

[-]

Posts: 1109

(31/12/2005 13:20:57)

genio

Remove this ad

right thanks jim ill give it a try and post up my findings!

Yuku free message boards

looks like the ds has a maths CoProssesor

looks like the ds has a maths CoProssesor