GP32 8bit Or 16bit Render Target?


MadDog

Member
Joined
Mar 4, 2006
Messages
262
Age
54
Location
UK
Website
www.maddoggames.com
I'm just getting a 'prof of concept' of my game engine running, and I can't decided to run with a palettised frame buffer or a 15 bit native one. The last time I did some ARM coding was on a pocketPC I had, the memory was slow so the speed up was almost 2x. I turned the 8bit to 16bits when the framebuffer was flipped.

I'm going to run the textures and the framebuffer tiled so having an 8bit FB will fit nicley. But for modern 3D I need alpha blend ops, and for a palattised framebuffer your need lookup's and i'm worried that this would cancel out any benifits of the smaller bandwidth for rendering.

Is any one bothering with 8bit rendering?
 
If you hit the hardware directly, the advantage of 8-bit rendering over 16-bit is nothing more than needing to write a smaller amount of memory to get a screen update.

If your using SDL, then 8-bit rendering will most likely be slower, as I think SDL converts your 8-bit screen to 16-bit before passing it to the hardware due to the fact that the linux frame buffer driver doesn't support 8-bit. This may have changed in one of the community hacked versions of SDL though.

And if your using neither of the above, then I guess your on your own :)
 
MadDog posted on Mar 22 2006 at 04:16 PM said:
I'm just getting a 'prof of concept' of my game engine running, and I can't decided to run with a palettised frame buffer or a 15 bit native one. The last time I did some ARM coding was on a pocketPC I had, the memory was slow so the speed up was almost 2x. I turned the 8bit to 16bits when the framebuffer was flipped.

That isn't so with GP2x. The cpu can fill memory at 150MB/s so with framebuffer at 320x240x16 bpp there is lots of bandwith.
(GP2x has 32 bit memory bus at 100MHz as I know)

MadDog posted on Mar 22 2006 at 04:16 PM said:
I'm going to run the textures and the framebuffer tiled so having an 8bit FB will fit nicley. But for modern 3D I need alpha blend ops, and for a palattised framebuffer your need lookup's and i'm worried that this would cancel out any benifits of the smaller bandwidth for rendering.

Is any one bothering with 8bit rendering?

If you are going to do 3D rendering for GP2x then you will be rather limited by cpu cycles than memory bandwith. And for alpha/transparency lockup tables they will be faster than alphablending but color add/sub will be fastest of them all (with some masking tricks they can fly).

I would rather worry about the texture access as going to low bbp values (4 bit for an example) will allow to fit more of texture into cache but at cost of decoding it back to the destination format. But it only will be apparent after some profiling what will be working best.
 
Last edited by a moderator:
Thats intresting did not expect the memory to be that quick, too use to working on consoles where look up tables can suck. On the ps2 for instance its quicker to build a face normal for the physics on the fly than to read in the extra data. I think i'll get the texture pipe right first, as this will be the same what ever the frame buffer depth.

I would say it depends on what a game is doing on which would be best, i'll need to make sure that if I can support both it don't mess the code up too much. ( and waste my time )

I've made the asumption that i'll beable to take total control of the hardware and run the second cpu as a gpu. Been reading up on the 940 and its perfect for the job. If the textures and FB are swizzled then the smaller cache should not be too much of an issue. The write back buffer looks like it needs a bit of care to get it going full speed.

The down side of this is that i'll have to write all the services that game will need. But thats why I got a gp2x, a nice hobby project to get my teeth into.
 
MadDog posted on Mar 23 2006 at 11:29 AM said:
Thats intresting did not expect the memory to be that quick, too use to working on consoles where look up tables can suck. On the ps2 for instance its quicker to build a face normal for the physics on the fly than to read in the extra data. I think i'll get the texture pipe right first, as this will be the same what ever the frame buffer depth.

The PS2 has slower memory comparably with its EE's processing resources. There is R5900, FPU, very wide vector units inside the EE and caches are only 40kB (including the SP).

The high latency Rambus isn't making it easier I suppose?

I never programmed PS2 and I'm just an amateur but it's clear that GP2x has more bandwith per its CPUs' processing power (400MB/s/400mips) than PS2 (3.2GB/s/6.2GFlops). There are no FPU/Vects to feed in GP2x and caches are 40KB (counting for both cores) too.

And GP2x isn't plagued with Rambus high latency menace either. :)
 
Last edited by a moderator:
Back
Top