No replies to this topic

[dsh]

I changed a bit the standard dingux kernel so now i hava my root fs on an ext2 partition on the sd. I need this to ease the development process, a read-only filesystem which needs to be rebuilt everytime I add/change a file is a no-go for me.

1) Where's the code that mounts /boot/local and launches /usr/local/sbin/main? I grepped the kernel source for every possible keyword I could think of but I can't seem to find it. And it must be in the kernel, right? This code also mounts the root as ro. Of course I can do mount -o remount,rw / in the main script but this way all of this is getting uglier and uglier.

2) Anybody tried measuring performance gains with size-optimized kernel? I realize JZ4740 doesn't have much cache?

3) What does the SDL use for blitting? Is it pure-software? Or maybe software with hand-crafted mips assembly to speed things up?

4) I'd like to write a sw blitter optimized (cause I'm not satisified with SDL, and I know the hw can do better) for 16bit with alpha channel support, tinting, blending, rotation, scaling (maybe bilinear as an option too). I've looked at the xburst specs and it seems that couple of this SIMD could speed things up drastically. I've never done any asm, but ingenic provides nice macros that wrap MXU instructions with sw implementation as a fallback. What does it mean that data should be 4-bytes aligned? Does it mean that the address%4 == 0? If yes, then a aligned malloc routine could look something like this:

[just a sketch, simplification - i know, it can't be done like this if we don't want leaks and problems freeing mem]

void *aligned_malloc(size_t sz)
{
   void *ptr = malloc(sz + 3);
   int shift = ptr % 4;

   if(shift)
      return ptr + shift;

   retur ptr;
}

5) I'm thinking about something like a simple package manager (without dependency handling), so you drop a package in a folder on the sd, then just open some install menu in dingux and choose it. It would allow people to easily add/remove features like swap and stuff without editing scripts. Instead of downloading whole localpack they could just download single items...

Of course that needs a rootfs which isn't readonly, and that means more complicated dingux installation process, but I think we could wrap a simple app up for that...

6) And what about this static linking stuff? Isn't that a waste of memory? Gmenu itself uses SDL so it's loaded at all times, right (or does it unload itself while launching an app?)? So now every app that uses sdl and has it statically linked loads it once more to memory.

7) Okay, rw rootfs means that we need the get rid of the memcard corruption bug, what's the progress on this? Anybody nailed it? Is it memory-card-brand-or-model specific or does it concern everyone? I found some info scattered on the net, but it would be nice if somebody could sum up for me the current status report on this. Are these corruptions massive, meaning, wouldn't an fs with journaling be sufficient to avoid complete reinstallation every couple of days/weeks?

8) What about the use of STL under dingux? I recently read a blog post of guy who ported aquaria to PSP, he was complaining about about STL causing massive memory fragmenation because it does a lot of tiny mallocs. Dingux too has small amount of ram so is this a problem?

I would like to port my (WIP) 2d game creation framework to dingux someday, and it's c++-oop-based with heavy use of STL containers...

9) I read that the dingoo CPU lacks an FPU, is this a serious performance concern with a game engine which uses floats for animations, storing coords, collision detection and all that vector arithmetics that are needed for a standard lib like this?

10) I'm a bit confused, because my knowledge is lacking in this areas. Does the current dingux kernel do virtual memory (it does swap, right?). Do we have the whole 32bit address space available or not? Is the mem allocated by malloc guaranteed to be physically continugous or not (isn't this a prerequisite for using dma transfers and the simd instructions)? Or maybe I have to write the blitter in kernel space and use kmalloc?


about 4) It seems that memory alignement to 4 bytes is not a problem. Quoting glibc docs:

The address of a block returned by malloc or realloc in the GNU system is always a multiple of eight (or sixteen on 64-bit systems).

I assume the same is with uclibc. Is this correct?

Edited by dsh, 06 July 2010 - 06:58 PM.