1ghz pandora dreamcast emulation

[craigix]

I am quite happy to donate a 1Ghz unit to this, sounds like a great project.

 

[Exophase]

*forehead smack*

 

[Wrath Of Khan]

consider the 1ghz pandora an incentive then.Would one not be better able to test games that require more overclocking to run properly etc?

 

[Exophase]

consider the 1ghz pandora an incentive then.Would one not be better able to test games that require more overclocking to run properly etc?

I keep trying to tell you all that these "incentives" do not work.


I think there's a massive psychological concept that if you spend money or give goods to someone you're making a positive difference in causing something to happen. Instead of just running wild with this why not first ask if giving him a 1GHz Pandora will have any influence at all. Or are you afraid of what you may hear?


nullDCe is closed source and drk||Raziel probably has full rights to it. If he were to release something largely playable on Android and Apple phones - which are now usually going to be at least as powerful as the DM3730 Pandora - then he could make at least tens of thousands if not hundreds of thousands of dollars. You really think your puny $700 Pandora is going to be the final incentive he needs to get this work done?


No, the reason we haven't seen releases yet is because it's hard and a lot of work, drk has standards for what he wants to release, and he probably isn't compelled to spend his whole waking life working on it. Regardless of what the reward might be. This is complex work and sometimes even if you really enjoy a lot of it that enjoyment will only come after a whole lot of crap that's laborious and not enjoyable.

 

[drkIIRaziel]

Craig might donate a 1ghz pandora to you for this emulator.I pm'd him a week ago about this and he was game.Me and Zuk also offer a bounty of 300 euros and 200 dollars also zuk is willing to pay for a 1ghz pandora for you to get this emu running on the 1ghz pandora.There is loads of interest in dreamcast emulation from users here on the forums.What do you think?

Dude, he already has a Pandora. He doesn't need a new one. I don't think you are understanding that you don't need a 1GHz Pandora to develop software that works on it. It runs the SAME SOFTWARE.

80% at 1Ghz (with sound). I'll try to update the pandora libs to see perfm. (i updated OS, and angstrom has wayy too old std libs ..).


The SGX driver loves to eat cpu time, doing ... no idea what exactly. CPU is always a bottleneck, as is poor cache perfomance and low (effective) bandwidth to ram. But hey, thats what gets you into low power


Since nothing beats real numbers ...


@ 800 mhz


bios main menu: 101%


recv ingame: 74, intro 65~70, with HEAVY freamskipping (SGX was at around 7 fps out of 18 or so -- the game runs at 25 normally).


Recv is one of the fast games (and happyly gets into tripple digits with A9 at similar clock).

This is interesting, and seems like a big improvement over the performance in MWeston's video which ran at about 40% realtime with no audio, at 800MHz. But you say this is one of the less demanding games, so I guess people should take this as a best case.


I'd love to hear more information, of course. I have some specific questions like usual..


1) How are you handling emulated instructions/second these days? Is there some timing depending on instruction type or a fixed number? Are you adjusting it based on game? If so is this done manually, stored in profiles, or what? Is there idle loop detection or some variability based on hardware sleep?


2) You say there's a lot of frameskip in your test, and seem to be implying that it's determined automatically. Since you aren't reaching real time speed with it, what is your cutoff exactly? Is it being driven by lack of CPU time or lack of GPU time? If it's the latter, is it a matter of preparing the display list then not sending it if the last display list is still being rendered? The 1GHz Pandoras have a 200MHz SGX so it should render a lot more quickly.


3) You seem to think softfp is a big performance limiter. That should only be the case if you're calling a lot of C (or some other high-level) functions with float return values (there's a little bit of a penalty for float parameters but it's not nearly as bad). Are you calling these functions frequently from recompiled code? If so, it seems like you'd gain a lot more from writing the functions in ASM than from hardfp alone, since you'd get a lot more control over the ABI overall..

1) predefined (very) pesimistic calculation + idle loop detection


2) There's a render thread, if it gets more than one frames queued for rendering it simply discards them


Yeah, sadly, there are many cases that C functions are used w/ floats. Most of them are copying data around, so it might be possible to have the types changed to partially fix the issue -- and this might not be as much of a problem on newer gcc versions (and well, brute forcing with asm might work .. but then why write thousand lines of platform specific asm code to fix a tool issue ?).


The main issue is the drivers, on A9 moving from softfp to hardfp calling cut the driver overhead to almost half .. and generally sablised speed for the better, A8 could be even more affected...


On my last a8 benchmarks sgx driver was around 30 to 40% of the total cpu time, so either i'm doing something nasty (haven't checked the code that thouroughly, but i'm not doing anything too fancy) or somethings fishy (or, well, both). Its not a problem with shaders, or with textures as replacing them with nil doesn't solve the issue. According to the SGX tools the actual h/w load is minimal.


Does pandora has a package for oprof or smth ?


Before we all get too excited, there are still some issues that i don't have control over that need to be resolved. I don't need a new pandora (i got a beagleboard-xm & my old pandora) -- and there were also some donations last time which I didn't manage to put into good use and i don't want that happening again.

 

[Zuk]

Before we all get too excited, there are still some issues that i don't have control over that need to be resolved. I don't need a new pandora (i got a beagleboard-xm & my old pandora) -- and there were also some donations last time which I didn't manage to put into good use and i don't want that happening again.

I did promise to donate a 1Ghz unit to this cause. If you ever decide you want it, or have someone else that could help you out and doesn't have one, let me know.

 

[Exophase]

Thanks for your responses.

1) predefined (very) pesimistic calculation + idle loop detection

Pessimistic as in a very high number of instructions per second? Like 200M? 400M? Does the idle loop detection work for most games? Is it working for RE:CV? Can you post any statistics about instruction counts/utilizations for it?

2) There's a render thread, if it gets more than one frames queued for rendering it simply discards them

Ah okay.. so it's "GPU" based but it sounds like a lot of that is driver stuff. And that dual core would be a huge advantage..

Yeah, sadly, there are many cases that C functions are used w/ floats. Most of them are copying data around, so it might be possible to have the types changed to partially fix the issue -- and this might not be as much of a problem on newer gcc versions (and well, brute forcing with asm might work .. but then why write thousand lines of platform specific asm code to fix a tool issue ?).

Thousands of lines seems rather exacerbating.. you must be talking about a lot of individual instructions..


It's really not just down to hardfp, the fixed ABI is going to limit you. Especially for a bunch of float-only leaf functions. Your recompiled code has no idea about what registers they could be modifying and has to assume all the caller save regs (r0-r3 and r12) will be destroyed. It's not nearly as bad as on MIPS, where the temporaries are over half the register file. But it's still less than ideal.


You might be able to do custom ABIs/calling conventions with C functions starting with declspec __naked__ or something.. no idea where to go from there..

The main issue is the drivers, on A9 moving from softfp to hardfp calling cut the driver overhead to almost half .. and generally sablised speed for the better, A8 could be even more affected...

Do you know if most of those calls were internal to the drivers, rather than ones you were making? If you're calling the driver a lot it sounds like you have a large number of draw calls. Which will equate to a lot of driver overhead. If it's the former.. let's just say I'm pretty disappointed, not that I had high expectations for the driver's efficiency..


If softfp is much slower on A9 then A8 would surely be more affected. The penalty for moving from FP/NEON to ARM registers is much worse.

Does pandora has a package for oprof or smth ?

Not sure if you want typical statistical profiling or what, I think it's available but I haven't used it. I've personally only been interested in raw performance counter values, which have been made accessible in user mode. I have some C code for accessing them if you're interested.

 

[drkIIRaziel]

Pessimistic as in a very high number of instructions per second? Like 200M? 400M? Does the idle loop detection work for most games? Is it working for RE:CV? Can you post any statistics about instruction counts/utilizations for it?

Over 200 mips currently: (* idleskip reduces this ofcourse, so its 'up to')


1 cycle for every non-fpu opcode


0 cycles for every fpu opcode


(dc is clocked at 200 mhz)


And yeah, of corse idle skipping is enabled. I haven't found so far any game that doesn't work with it (in ~ 150 or so tested overall)

Thousands of lines seems rather exacerbating.. you must be talking about a lot of individual instructions..


It's really not just down to hardfp, the fixed ABI is going to limit you. Especially for a bunch of float-only leaf functions. Your recompiled code has no idea about what registers they could be modifying and has to assume all the caller save regs (r0-r3 and r12) will be destroyed. It's not nearly as bad as on MIPS, where the temporaries are over half the register file. But it's still less than ideal.


You might be able to do custom ABIs/calling conventions with C functions starting with declspec __naked__ or something.. no idea where to go from there..

Its mostly the vtx handling code, which is a complicated mess of ta fifo parsing, data parsing and coversion, and state handling -- i'm using templates for it right now to make it small-ish. Perhaps writing the vertex decoding in asm will solve the issue, perhaps not, but it is quite a bit of work. And there are still cases where hardfp will help in general.


Custom abi would rock, but its porbably too much work and not worth it .. if only those high neon regs were callee save ....

Do you know if most of those calls were internal to the drivers, rather than ones you were making? If you're calling the driver a lot it sounds like you have a large number of draw calls. Which will equate to a lot of driver overhead. If it's the former.. let's just say I'm pretty disappointed, not that I had high expectations for the driver's efficiency..


If softfp is much slower on A9 then A8 would surely be more affected. The penalty for moving from FP/NEON to ARM registers is much worse.

I use VBOs, and only do draw calls when i have to. Dreamcast is around 10k vtx/frame, so i'd say 100-500 calls/frame ? Nothing too terribly evil anyway. I have the drivers regularly hardlock on beagleboard -and- pandaboard .. even when running underspected with very good psu and no SD card ... so .. yeah ... In two of the pandaboards i have crazy taxi crashes within 30 seconds, always . They also locked up today on panda, but i was running @ 800 for testing so i can't blame them for that


Actually A9 has a huge issue if you mix neon w/ vfp -- over 400 cycles stall switching mode according to my results.. thats why i don't use neon at all anymore .. (which is actually bad on A8)

Not sure if you want typical statistical profiling or what, I think it's available but I haven't used it. I've personally only been interested in raw performance counter values, which have been made accessible in user mode. I have some C code for accessing them if you're interested.

oprofile does 'statistical' profiling using these perfm. counters instead of just cycles, which is pretty awesome

 

[CAZMIESTER]

Did you not start preliminary ports to android way back? would that work on the pandora build? PS drkIIRaziel loved Nulldc but could never get my zero gunner 2 to run but brill work.

 

[calc84maniac]

I'm kind of interested to hear about the dynamic recompiler. Are you using dynamic register allocation, mix of static/dynamic, or (doubtfully) no allocation? Have you been able to abuse ARM's 3-operand instructions to avoid generating any code for SuperH MOV instructions?

 

[drkIIRaziel]

Block local linear-scan-ish dynamic register allocation for all registers, excluding 4x1 and 4x4 vectors. And yes, i perfom register aliasing optimisations, as well as many other things (though it doesn't help much, sadly)

 

[mcobit]

Is the dynarec, that ari wrote for Yabause of any use for dreamcastemulation?

 

[kasp]

I was wondering if there is a bounty for dreamcast setup at the moment? I see people offering things here and there but can't seem to find a central spot for them?

 

[Halcyon]

I would be stoked to get a VMU emulator. I really enjoyed the mini games you got with Skies of Arcadia back in the day

 

[Cloudef]

I use VBOs, and only do draw calls when i have to. Dreamcast is around 10k vtx/frame, so i'd say 100-500 calls/frame ? Nothing too terribly evil anyway. I have the drivers regularly hardlock on beagleboard -and- pandaboard .. even when running underspected with very good psu and no SD card ... so .. yeah ... In two of the pandaboards i have crazy taxi crashes within 30 seconds, always . They also locked up today on panda, but i was running @ 800 for testing so i can't blame them for that

Actually A9 has a huge issue if you mix neon w/ vfp -- over 400 cycles stall switching mode according to my results.. thats why i don't use neon at all anymore .. (which is actually bad on A8)

Seems like you are draw call bound with the GPU. SGX's most notorious bottleneck is the bandwidth and doing over 20 draw calls to it will slow down everything.


There are other bottlenecks such as texture switches though, as you said already that was not a issue. You should do more batching if possible, seeing that I'm not familiar how most dreamcast games draw their geometry. Also, in case you don't know, VBO's in most SGX platforms are totally useless since most platforms that use SGX share the video memory with CPU which kills the point of VBO totally leaving you with no performance benefit (This is true for iOS platform as well, even though apple suggests using VBO's for some reason in their SGX documentation. Maybe for future proofing? Who knows.)

 

[DaMummy]

can someone explain to me why some of you devs hold back so much when it comes to releasing your work unless its perfect? Took us forever here to get Exophase to release any kind of build of Temper, and even then he refuses to put it anywhere official. And there's obviously something working with a Pandora build of nullDC but its obvious the customers won't and haven't seen anything for a while. At least Ari knows that while we hope for perfection, we will settle for anything less.

 

[sepp256]

can someone explain to me why some of you devs hold back so much when it comes to releasing your work unless its perfect? Took us forever here to get Exophase to release any kind of build of Temper, and even then he refuses to put it anywhere official. And there's obviously something working with a Pandora build of nullDC but its obvious the customers won't and haven't seen anything for a while. At least Ari knows that while we hope for perfection, we will settle for anything less.

I think Ari64 had worked on his mupen64 dynarec for something like 6 months before saying anything about it. He also didn't say a peep about his Yabause dynarec until it was ready to release.

 

[Exophase]

can someone explain to me why some of you devs hold back so much when it comes to releasing your work unless its perfect? Took us forever here to get Exophase to release any kind of build of Temper, and even then he refuses to put it anywhere official. And there's obviously something working with a Pandora build of nullDC but its obvious the customers won't and haven't seen anything for a while. At least Ari knows that while we hope for perfection, we will settle for anything less.

I didn't release Temper because it could already be used in ginge and there were already alternatives like Mednafen. I also didn't want to release something Pandora-only, but the new rendering code is C only and not suitable for platforms like GP2X/Wiz/Caanoo (in fact, I was supposed to give an ASM version of it to Slaanesh for GP2X). Even to get the release I did out I had to spend a few hours getting it ready and that's not really something I felt like doing.


I can't speak for anyone else but I'm fairly single focused and task oriented. For instance, when I play a new game I like focusing on it for a while until I beat it and then I'm done with it, at least for a long time. Projects are the same way. I have a goal and I work towards that. Then I move on to something else. I don't like working on a bunch of stuff and constantly making little updates. For me there's a lot of overhead in releasing something. You don't just have to deal with packaging it and writing documentation (or at least, I write documentation, a lot of people don't really bother) but you also have to deal with feedback including a lot of bug reports. I know in a lot of communities people really eat up rapid fire releases but these releases are also often plagued with bugs and even regressions, also half implemented features, because they're not thoroughly developed and tested first.


This doesn't mean I ever hold out for "perfection" (and have never really left something at a first release). For one thing I know no private testing can be anywhere as thorough as releasing something as a public beta. But I still have goals and standards and if they don't align with what you want then uh, oh well. For instance, gpu_neon was pretty much useless until a few weeks before it was released - until I finished proper code for all of it it was several times slower than peops. So I think you can see why I didn't release it. And while some people really revel in drumming up excitement by hyping their work I could really do without the hassle and pressure it generates when you don't meet expectations.

 

[Halcyon]

^ well said, I know nearly nothing about software but know some basic /mid level electronics skills and I dont like mentioning what im working on until it is nearly complete because of the unpredictable nature of development it is not always easy to know how much more work is left or if a small change basically will require a near full tear down and rebuild. good luck to all our dedicated developers thank you for making the pandora as good as it is!

 

[spaceharrier]

What a great selling piece for the 1GHz if it can emulate Dreamcast perfectly (or near perfect).


.....anyone care for some Shenmue or Space Channel 5 'on the go'?