GP2X Squidgesnes_0.37 Code Comments


Looking at the snippets people posted I see it uses some doubles? Without FPU that would be pretty slow, but wouldn't floats be faster?

Also is there a list of known bugs somewhere? (I couldn't find it)
 
cxzuk: I've always had problems with gprof - it always seems to generate the file, but it's empty :(
 
Hey dood,

Empty? Hmmm.. Could be due to ARM arch? - If someone could send me a gmon.out file ill have a look, (unless its 0bytes "empty")...

Daid:
does the gp2x not have a FPU? - If so, give this a try

change the (from memory, i think its in gp2xmain.c?)...

Code:
#include "dsp1emu.c"

to

Code:
#include "dsp1emu_fixed.c"

this should then use int32's instead of floats.

Mike
 
yaustar posted on Aug 7 2006 at 07:10 AM said:
How expensive is the '%' operator on the GP2X?
Also, can we use gprof for GP2X executables?

IIRC it's quite expensive, just as expensive as a divide I think.
 
Last edited by a moderator:
Mudi posted on Aug 7 2006 at 04:09 AM said:
IIRC it's quite expensive, just as expensive as a divide I think.
In that case, something very minor: gfx.cpp line 618
Code:
	if (++IPPU.FrameCount % Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}
could (?) be changed to
Code:
	if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}
 
Last edited by a moderator:
yaustar posted on Aug 7 2006 at 04:48 PM said:
Mudi posted on Aug 7 2006 at 04:09 AM said:
IIRC it's quite expensive, just as expensive as a divide I think.
In that case, something very minor: gfx.cpp line 618
Code:
	if (++IPPU.FrameCount % Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}
could (?) be changed to
Code:
	if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
	{
		IPPU.DisplayedRenderedFrameCount = IPPU.RenderedFramesCount;
		IPPU.RenderedFramesCount = 0;
		IPPU.FrameCount = 0;
	}

lol!!!!!! ... ok read it ... It says...

Is the remainder of IPPU.FrameCount / ROMFramesPerSecond = 0? ... so if ROMFramesPerSecond = 2... FrameCount can be any mult of 2.. so 2,4,6....

Now heres the thing... IF it = {2,4,6,...} then set FrameCount = 0!! so it will only EVER reach "2"

basically, my point is, With that snippet, you should be able to change it to,

Code:
if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)

Might have to check to see if other factor's come into play.. but that should work with the code above. =)

Mike
 
Last edited by a moderator:
Slightly OT, what would be faster on an ARM chip:
Code:
// a bitwise operation and comparing to 0
if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
or
Code:
// comparing to a non 0 value?
if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)
 
If compare to 0 is faster..

Code:
if (--IPPU.FrameCount == 0)
{
	IPPU.FrameCount = Memory.ROMFramesPerSecond;
}

=)

Mike

yaustar posted on Aug 7 2006 at 05:35 PM said:
Slightly OT, what would be faster on an ARM chip:
Code:
// a bitwise operation and comparing to 0
if (++IPPU.FrameCount & Memory.ROMFramesPerSecond == 0)
or
Code:
// comparing to a non 0 value?
if (++IPPU.FrameCount == Memory.ROMFramesPerSecond)

I think we should start a page on the wiki with coding tips, such as whats faster.
 
Last edited by a moderator:
Hi all,

Looking in tile.cpp.

it seems to have lots of functions like..

Code:
__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
   		uint16 *Screen = (uint16 *) GFX.S + Offset;
   		
		  Screen += 7 * 320;

   		#define FN(N) \
   			if (!(solid&(1<<(7-N)))) *Screen = *Pixels; \
   			Screen -= 320; Pixels++;
   		FN(0)
   		FN(1)
   		FN(2)
   		FN(3)
   		FN(4)
   		FN(5)
   		FN(6)
   		FN(7)   		
   		#undef FN 
}

surely defining code, running it 7 times, then undefining it must be slower than a normal loop?

Code:
  ...
// create lookup[x] table (1<<(7-x))
uint8 FN_lookup[7] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01};
  ...

__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
  uint16 *Screen = (uint16 *) GFX.S + Offset;
   		
  Screen += 7 * 320;

  for(int c = 7; c != 0; c--) {
	if (!(solid & FN_lookup[c])) *Screen = *Pixels;
	Screen-=320; Pixels++;
  }
}

am i wrong?

Mike
 
I am afraid so. #define and #undef are preprocessors and are done at before compile time. It won't matter at runtime. What it comes out as before the compiler sees it:
Code:
__inline void FLIPPED16_T (uint32 Offset,uint16 *Pixels,uint32 solid)
{
		   uint16 *Screen = (uint16 *) GFX.S + Offset;
		   
		  Screen += 7 * 320;

				 if (!(solid&(1<<(7-0)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-1)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-2)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-3)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-4)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-5)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-6)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
				 if (!(solid&(1<<(7-7)))) *Screen = *Pixels; 
			   Screen -= 320; Pixels++;
}
In which case your code will be slower as the orignal code unrolls the loop whereas yours is in a for loop with one extra variable and two extra operations per loop.
 
Actually it's exactly the same, because the makefile I use with this has a -funroll-loops.
 
Well, it pretty much unrolls any constant-iteration loops. That's about all there is to it.
 
yaustar posted on Aug 8 2006 at 12:12 AM said:
In which case your code will be slower as the orignal code unrolls the loop whereas yours is in a for loop with one extra variable and two extra operations per loop.

Not only that, but because you are branching, your affecting the prefetch and causing it to be emptied and refilled at the new location.
 
Last edited by a moderator:
Hi all,

Ive read over the code, and its pretty basic algorithms and coding. Pretty hard to optimise.

Someone mentioned rewriting the gpu.

I would prolly say a complete start again, converting over the current code into GP2x optimized code is prolly the best way to go, and replacing as much as pos with ASM. (such as the sound core mentioned).

I just think the current code is too full of other useless code.

What do u think?

Mike
 
Squidge posted on Aug 8 2006 at 03:23 PM said:
I agree, but rewriting the GPU is a huge task.

I would be willing to help, but i have no real idea as to how it works. And im sure theres lots of others that would help.

If it was to be done, it would more than likely need a "todo" list, or a project leader.. or both. If you could provide that im sure the work would be done much quicker.

Mike
 
Last edited by a moderator:
Back
Top