That Sucked. Waste Of Two Days?

[zodttd]

I've spent the past two days trying to figure out if what Admin@FreeDO was true...

I had a private conversation with him about the FreeDO project, which still sounds promising.

Basically what he said was the interrupts on the GP2X Linux distro were being polled way too fast and sucking up CPU time. Disabling interrupts was said to give a 35%-40% increase in CPU performance. This is why HH was being used in his project. I decided to try it out.

I spoke with Squidge and he and I got it worked out. Our code uses his MMU uname patching to get us the ability to write to CPSR and SPSR's control field and either ORR (disable) or BIC (enable) the IRQ and FIQ bits.

It seems to work, and disables IRQs on load, and enables them on exit of psx4gp2x. The problem is there is extremely (less than a single FPS) little to no performance gains from this.

Maybe it's my implementation or maybe it truly isn't disabling IRQs. I even downgraded the GP2X from fw3.0 to fw2.0 to be more sure the uname address used in Squidge's code was correct. When exiting the emulator without re-enabling IRQs the emulator will crash indicating they were disabled. Strangely though, SD access still works.

Thinking maybe IRQ's get re-enabled occassionally, I did exactly what Admin@FreeDO said, and enabled/disabled IRQ's on each branch in my dynarec. This causes a good amount of slowdown, about a 75% DECREASE in performance.

So I'm not sure if that statement is quite factual yet. If anyone has expierence with using HH over Linux for GP2X dev let me know if performance is better. And if possible, let me know if it's due to the IRQs being the reason.

Squidge is in the process of doing his own testing, I believe. Hopefully he gets different results.

Two days wasted? Hope not!

 

[Jaguarandine]

Wow, that's very interesting stuff zodttd. Sounds like a big breakthrough if you can get it working. This is just the kind of thing I was hoping for when we intially had interest in the 3DO emulator.

 

[zodttd]

I'll wait for Squidge to get his tests done before I get this finalized. But the point I was making was that there is no performance increase from disabling the IRQs from my tests. So it seems there's nothing to get working.

Jaguarandine: I actually got this information about IRQs being helpful to performance if disabled, from Admin@FreeDO. So even if somehow it does prove to be helpful somehow, I'd assume it's covered in FreeDO for the GP2X. Like I said though, I didn't see it affect performance at all.

 

[Jaguarandine]

I see.. Well I hope you haven't wasted your time. Maybe you can follow-up with Admin@FreeDO if he's not too busy. Thanks for the effort.

Edit: Linux being that inefficient doesn't make sense though. Wouldn't we have caught this before?

 

[evol]

hmm i wonder if that cpu sucking irq polling is what Epicenter stumbled upon ?
(if i recall correctly he was hitting a performance wall when testing how many sprites that the gp2x could handle)

 

[zodttd]

Jaguarandine: It sounded sort of weird, but I relayed what Admin@FreeDO said to DJ Willis (Open2x guy) and we were thinking it might actually be true and Squidge and I decided to test the theory out. I'll follow-up with Admin@FreeDO and see what he can input on this.

evol: Not sure, I learned about this from Admin@FreeDO. That performance wall could be caused by many things, but if I can find more information leading to this being the case, that IRQs are polled way too often, that'd be great!

From what I understand though, so far tests have shown that IRQs polling timing from GP2X's Linux distro isn't affecting performance.

 

[notaz]

I spoke with Squidge and he and I got it worked out. Our code uses his MMU uname patching to get us the ability to write to CPSR and SPSR's control field and either ORR (disable) or BIC (enable) the IRQ and FIQ bits.

Wouldn't it be easier to just mask out all IRQs and FIQs on MMSP2's IRQ controller? Or will Linux unmask them itself? Can't test this myself right now because I'm at work (must finish some stuff). CPSR/SPSR is probably changed by other system calls our programs do, so I wouldn't rely on that uname() patching method.

I really doubt Linux slows down stuff that much, unless GPH/Dignsys screwed something really badly.

 

[Squidge]

I've not had time to test stuff properly yet, but I do remember when the gp2x first came out and I was messing with the second core, that the performance on it was almost identical to the performance on the 920, and Linux was running on the 920.

So I still seriously doubt that Linux is stucking up more than about 1% of CPU usage. The only advantage to be had by HH mode is cache efficiency - rather than Linux continually changing the TTB and screwing up your cache, you can more easily fine tune it. HH mode is also essential for stuff like Spot. The disadvantages to HH mode are that you loose usb (which includes all networking services), sd support, timers, etc, and therefore you need JTAG for debugging and write those all yourself, and when you do, you can guarantee some people will complain that they can't load there roms from a 300GB Harddisk they've attached to a BOB via USB.

Personally, I think Admin@FreeDO is assuming without first trying, or maybe he isn't a Linux guy so prefers to toss Linux (and all the benefits Linux gives) away.

 

[skeezix]

This is entirely off topic, but I just fired up NJ's CPS2PSP .. damn, thats a pretty smooth emulation. He's released sourece for all his.. not sure what its based on or if its fro scratch, but it might be a worth port, too. (Instead of or in addition to fdave's Final Burn

<kernel discussion remove;d hell, it sjust rambling. Without all the daemons, the kernel (*assuming you're not coding like an idiot and using lots of kernel space calls) is insignificant; shoudln't be more than .5%, or maybe up to 5% at worst. You guys are already aware of the issues so why stumble in and fall down on them I say.. >

But I'm freaking rambling right now, no sleep in 2 days now woowoo Why must the sun come up at the worst of times

jeff

Maybe he just likes to hack on the hardware

 

[Ravnos]

I thought NJ's CPS2 emulator was ported already by ell as cps2emu? Either way, we've got a pretty nice CPS2 emulator right now, but Final Burn will still be nice for all the other stuff it supports.

 

[zodttd]

skeezix: That post reminds me of your avatar

 

[Jaguarandine]

Well, he was telling me how much he liked Linux as a programming environment. I dunno, maybe his strategy will only work as intended with the 3DO emulator. Assuming FreeDO runs fullspeed, he'll probably be doing something right

Anyway, like Squidge said this would open up another can of worms. When using HH mode everything would have to be created again from scratch. I suppose all but the most demanding programs would not use it.

 

[Exophase]

Honestly this doesn't surprise me, I was really skeptical. 35-40%??

Getting rid of Linux means that you get full control of IRQs (so you can have low latency exceptions), MMU w/o restrictions, ability to invalidate and lock cache directly as you please, manage the TLB and MMU regions in a maximal way...

But because of all the reasons Squidge said I wouldn't go for it unless people start doing their own support libraries for it so more people can dive in. A set of syscalls for interfacing with hardware. It'd be like more like DOS. I don't even have a working SD slot so I don't know how I'd write an SD driver.. a NAND driver would be first (actually, is NAND mapped to the address space? Because that'd be swell. :c)

Going to have to repeat what has been said, unless the kernel is doing some crazy things on interrupts then there's no way it's taking up a dire amount of CPU time. This also goes to show that the people who keep saying that code for PC's is much worse off because of OS overhead don't know what they're talking about.

Personally I'd love to have a Linux-free environment that lets the user map address space and have full control of everything, while still giving some library routines to easily use the other stuff. FreeDO is undoubtedly benefitting from the things I mentioned, especially MMU. If you can setup the address space comfortably in addition to setting up an exception handler that can do everything the main code can then it might not be hard for emulators to take advantage of it. This would especially benefit emulators of machines with relatively fast CPUs like GBA and PS1.

Actually, I have to wonder how FreeDO works, it has an ARM CPU like GBA that is clocked similarly (12.5MHz), is it interpreted or..? I wouldn't mind talking to the author myself.

 

[Rivroner]

Well, he was telling me how much he liked Linux as a programming environment. I dunno, maybe his strategy will only work as intended with the 3DO emulator. Assuming FreeDO runs fullspeed, he'll probably be doing something right

Anyway, like Squidge said this would open up another can of worms. When using HH mode everything would have to be created again from scratch. I suppose all but the most demanding programs would not use it.

FreeDO is running fullspeed in GP2X ? In my 2ghz PC no
Well, i will play it in the GP2X

 

[Orkie]

Honestly this doesn't surprise me, I was really skeptical. 35-40%??

Getting rid of Linux means that you get full control of IRQs (so you can have low latency exceptions), MMU w/o restrictions, ability to invalidate and lock cache directly as you please, manage the TLB and MMU regions in a maximal way...

But because of all the reasons Squidge said I wouldn't go for it unless people start doing their own support libraries for it so more people can dive in. A set of syscalls for interfacing with hardware. It'd be like more like DOS. I don't even have a working SD slot so I don't know how I'd write an SD driver.. a NAND driver would be first (actually, is NAND mapped to the address space? Because that'd be swell. :c)

Have you looked at SDK2x? It's not complete, but it is still useful.

 

[Squidge]

Nope, nand isn't mapped to an address space. There are i/o locations for it, but it's more for a "write command, write address, read result from fifo" type of operation.

SDK2x was built to create apps without Linux, and the end result was intended to be a full replacement (nand, sd, sound, display, etc, etc). But it was abandoned before it was completed. I've looked at it multiple times, but didn't really understand it's trampoline technique, nor the reasons why a lot of the code was written the way it was. That's why I wrote a kernel module for Spot - it's basically my own version from scratch that I fully understand, and has a lot of advantages.

Strangely enough, the author of FreeDO states he has no interest in the MMU:

"mmu doesn't give me any advantage, since 3do doesn't have it and all space is linear." - goto post

"2nd core == ARM60 emulator -- loads and modifies the code for ARM60 (takes into account R15 usage as operand) for direct execution. replaces hardware access with unique SWI. SWI handler besides handling 3DO SWI calls, recognizez HW access SWI and directs them to 1st core." - goto post

It seems he's not using linux because he has his own RTOS he wishes to use, for which he's already written a load of routines - goto post

 

[Shadowsithe]

This might sound weird but beyond Policenauts... what's actually worth playing on the 3DO? I'm not familiar with it as I was too young when it came out.

 

[Jaguarandine]

Go to the FreeDO GP2X thread. In the first post, there's a link to the older 3DO thread. That should help and let's stay on topic here.

 

[rokdcasbah]

from cruft^H^H^H^H^Hwikipedia:

QUOTE
The most well-received titles were commonly ports of games from other systems, such as Alone in the Dark, Alone in the Dark 2, Myst, Out of This World, Return to Zork, and Star Control II. Other notable titles include Need for Speed, Road Rash, Jurassic Park Interactive, Crash N' Burn, Gex, Slayer, Killing Time, and the first console port of Super Street Fighter II Turbo


anyway...myst would be killer. just seeing the thing in action would be killer...i hope this pans out.