GP32 Good Sw Render Doc.

[MadDog]

I found this the other day, very good read although targets the Intel x86 chips. But he talks about some ideas for speeding 3d prims up that I was thinking about, i've worked with 3d hardware for years so learnt some of thier tricks, which it sounds like after reading this they got from the old SW render days.

Has a bit of cut'n'paste code that works out of the box, not sure if there are faster ways now, the docs a bit old now.

fatmap.txt

 

[slygamer]

Note that the function doesn't move the vertex data to some local variables,
it uses pointers to each of the structures instead.

Exactly what it says not to do in the ARM optimal coding document.

 

[MadDog]

Yer, I thought that when I saw the code, but the theory is good. I've order three arm coding books today, so be intresting what else is non arm friendly.

 

[una-i]

I found this the other day, very good read although targets the Intel x86 chips. But he talks about some ideas for speeding 3d prims up that I was thinking about, i've worked with 3d hardware for years so learnt some of thier tricks, which it sounds like after reading this they got from the old SW render days.

Has a bit of cut'n'paste code that works out of the box, not sure if there are faster ways now, the docs a bit old now.

fatmap.txt

​

give a look also at this http://www.multi.fi/~mbc/sources/fatmap2.txt is the next rerease of the document ans talk more in depth on the texture tilling.


Unai.

 

[Inopia]

@una-i: here's something I wrote way back when I was playing with the GP32

http://www.cs.helsinki.fi/u/jikorhon/conde.../doc/thedoc.txt

One of the most important things I found out benchmarking was that because there's a seperate chache for code and data, it's in practice a very good idea to unroll your loops. On intel this was a bad idea because the large amount of data reads would contend with the code reads and cache miss mayhem would ensue. Not so on the ARM9, where they are seperate.