GP2X Performance Issues With V2 Firmware

[scorpio]

Hi,

I've split this off from the V2 sound issues thread to try and keep it all together if it turns into a worthwhile discussion:

Rather than having versions of emu's and apps for various versions of the firmware, I'm thinking of scrapping Linux completely and jumping on the hardware. Hopefully the hardware itself is not going to change for a while, whilst the firmware seems to change things constantly.

I've noticed that when the menu starts, it appears to start a second instance of itself, which I guess is for automatic respawning. Successive instances seem to share a large portion of memory with the first one, but I'm sure it still has an impact on the efficiency of the system. This could end up being a memory leakage issue since most game startup scripts restart the menu themselves, and now any time you run one of these, you get additional menu processes running. I think gp2xmenu needs a bit of work to make it a bit more self-aware...

I know it's tempting to think about ditching Linux, especially when the hardware platform is a known quantity, but if you look at the problems people have with getting their firmware updated, I'm not sure I'd want to be writing the code for reading the SD-card, for a start, although I guess we can copy a lot of stuff from the kernel.

Maybe there's some work that can be done with the new kernel to try and minimise its performance footprint. Do you know who's looking after the kernel now? I think I saw a post somewhere which suggested that Dignisys are no longer in control of it.

I've been wondering for a couple of weeks whether it might be an idea to have a kernel module which can shut the system out to a certain extent, so that games could allocate interrupts and have control over the scheduler. After all, it's unlikely that the telnet and samba daemons would need to be scheduled particularly often while a game is running.

It might also be nice if it could provide a standard interface for allocating blocks from the upper memory region, but I'm not talking about something that provides all sorts of services, just important things like giving access to request_irq() and suchlike. I'm sure it would help battery life if games could run with a vsync-driven interrupt, instead of busy-looping for it. What do you think?

 

[Squidge]

The problem we seem to be getting is that writing stuff that places high demands on the system seems to be less compatible when written with Linux in mind than it would be when written with just the hardware in mind. For example, Reesy has a version of DrMD for fw1.2, 1.4 and now 2.0, due to the way GPH have changed various bits of the kernel in each firmware version. I'm having the same problem. If we hacked the hardware instead, it would run on all current GP2Xs, as the hardware is identical in all of them.

This is exactly the opposite to what it should be - writing for the OS should mean your code runs on all versions (possibly with an exclusion saying "Requires at least os x.y") regardless of hardware changes, as the OS is expected to handle the hardware changes.

On top of this, Linux still doesn't allow access to the upper 32mb in a nice manner - you have to mmap it, and live without caching or buffering, and it still doesn't allow access to irq's, or other useful parts of the mmsp2.

 

[scorpio]

The problem we seem to be getting is that writing stuff that places high demands on the system seems to be less compatible when written with Linux in mind than it would be when written with just the hardware in mind. For example, Reesy has a version of DrMD for fw1.2, 1.4 and now 2.0, due to the way GPH have changed various bits of the kernel in each firmware version. I'm having the same problem. If we hacked the hardware instead, it would run on all current GP2Xs, as the hardware is identical in all of them.

I haven't been able to look into that in depth, but as far as I know, DrMD brings the CPU speed right down for the menu, so any latency or stalls incurred by the scheduler is going to be exacerbated. Ideally, the menu should be able to run on the vsync interrupt and put the CPU into sleep mode when it's not running. My thinking is that this would help in that particular case, but again we have the problem that you can only install an interrupt handler from the kernel. I see that there is already a vsync interrupt handler installed by the system (DPC_VSYNC, attached to dpc_vsync_interrupt() somewhere in the framebuffer driver I think), so I wonder how difficult it would be to hook into that.

I know what you're saying as regards portability across firmware versions by using the OS, but one of the tradeoffs of portability is usually efficiency and/or performance, which is why I thnk we need to find the best way to bend the OS towards our interests. That way, we should be able to get control when we need it.

I think part of the problem is that because we can't install interrupt handlers, a lot of the code that needs to perform well, has to do so by busy-looping on the vsync register, As a result, the scheduler has to force its way in, and of course Murphy's law states that it will do so when we least want it. I'm guessing that with the game (or whatever) trying to use 100% of the CPU, the time-slicing supervisor suffers as a result, but perhaps someone who knows more about the inner workings of Linux can enlighten me on that.

Even if there was some way of telling the scheduler to process all queues immediately, that would be a big help, since you could initiate that once your frame-critical code has run, and that should let the system manage its own housekeeping with less impact on the foreground process, and with less of a build-up of housekeeping tasks.

 

[FluffyPanda]

I'm hoping that the 2.x.x series of firmwares won't keep messing up now that they seem to have a more capable team (person?) managing the OS.

 

[scorpio]

I'm hoping that the 2.x.x series of firmwares won't keep messing up now that they seem to have a more capable team (person?) managing the OS.

Well, without wishing to appear negative, this has yet to be proved. The V2 source doesn't appear to be on the repository yet...

 

[Minkoff]

So, wait, with version 2, every time I run a game the firmware opens up another menu in the background?
Um... Is there a way around that? Like adding kill -9 `pidof gp2xmenu` to the top of my launcher scripts?

EDIT: I realize this doesn't really contribute anything to the topic, I just didn't think it would make sense making a new one.

 

[scorpio]

Hi,

So, wait, with version 2, every time I run a game the firmware opens up another menu in the background?
Um... Is there a way around that? Like adding kill -9 `pidof gp2xmenu` to the top of my launcher scripts?

EDIT: I realize this doesn't really contribute anything to the topic, I just didn't think it would make sense making a new one.

Yes, that's what it looks like to me. If I start and quit various games from the menu, and do a 'ps' after the menu comes back, I see more and more instances of the menu showing up. After a while you seem to hit a stage where there are multiple menus responding to the joystick, and you get multiple icons changing selection status, and it all gets a bit messy!

Like you say, it seems as if all the startup scripts will have to be modified to do a killall, or let the menu respawn automatically, or the gp2x menu will have to be fixed up to account for this.

 

[Minkoff]

That's interesting. I've been opening (without the launchers) squidgesnes, sterm, and a couple of other things, then using ps and not having gp2xmenu show up. This is the 2.0.0 fw.

 

[scorpio]

That's interesting. I've been opening (without the launchers) squidgesnes, sterm, and a couple of other things, then using ps and not having gp2xmenu show up. This is the 2.0.0 fw.

When you say "without the launchers" I presume you mean not using the shell scripts and launching the binary executable directly from the menu? If so, the behaviour you're seeing is what I would expect. The problem is when you use the shell scripts that come with a lot of games now. The script starts the game, and then when the game ends, the script assumes that a new instance of the menu needs to be started and is unaware that it's already running.

I think it's a fault, because it's a change in behaviour that doesn't take into account the workarounds for its previous incarnations.

 

[Minkoff]

You're right in thinking I was launching the binary directly, but the reason I pointed it out was that these were binaries that worked without shell scripts on earlier firmwares, which makes me assume they launch the menu at the end anyway and that the shell script would just launch a second one.

In other words, to me it looks like the firmware isn't launching the menu at all. Is that possible, or have you confirmed that it's actually the firmware behind it?

 

[scorpio]

Hi,

You're right in thinking I was launching the binary directly, but the reason I pointed it out was that these were binaries that worked without shell scripts on earlier firmwares, which makes me assume they launch the menu at the end anyway and that the shell script would just launch a second one.

That's an interesting point, and I'll check it out this evening. It could be to do with the way the menu is launched. I think the binaries launch it using the exec() function, which is probably different enough from the way a shell script starts it. My suspicion is that when the menu is launched from the binary, it sees its original owner process and reattaches itself to it, whereas from a shell script, the system launches a brand new process.

I'll do some in-depth checking later and get back to you on that.