Mupen64Plus

[ari64]

I have no idea how many old x86 games use self modifying code, but its usage has certainly lowered since the advent of modern cached, pipelined platforms. Ari64 already mentioned that he hasn't seen it legitimately used on the N64.

I haven't seen any cases where code will modify other code within the same page or execution block. I have seen cases where code will replace a function with another function at the same address.

HLE is only used for the RSP/RCP. Every MIPS instruction is executed.

Given the small amount of 64bit code used by games (and I hear that a lot of it is library code) it could offer a substantial speedup if you're capable to HLE out these sections then recompile the rest of the code as strictly 32bit.

Only if you think you can rewrite these sections better than the recompiler. In that case, the compiler could be improved.

 

[Exophase]

Only if you think you can rewrite these sections better than the recompiler. In that case, the compiler could be improved.

I'm not sure you understand what I'm getting at. The point isn't to beat the recompiler, it's to provide an artificially known barrier between 32bit and 64bit code (assuming one does exist in the game - but it probably almost always does). This wouldn't necessarily have to be done by HLE'ing the 64bit parts either, but it'd have the same result. If the 64bit portions have 32bit interfaces then the 32bit code can be compiled without ever touching the upper halves of the 64bit registers. I'm pretty sure that there have been N64 emulators that have done this, by HLEing common 64bit code out.

It's possible to detect this in a recompiler, but it'd require a lot of global/interblock analysis and probably dropping blocks once you find that they depend on 64bit operation.

 

[ari64]

I'm not sure you understand what I'm getting at. The point isn't to beat the recompiler, it's to provide an artificially known barrier between 32bit and 64bit code (assuming one does exist in the game - but it probably almost always does). This wouldn't necessarily have to be done by HLE'ing the 64bit parts either, but it'd have the same result. If the 64bit portions have 32bit interfaces then the 32bit code can be compiled without ever touching the upper halves of the 64bit registers. I'm pretty sure that there have been N64 emulators that have done this, by HLEing common 64bit code out.

It's possible to detect this in a recompiler, but it'd require a lot of global/interblock analysis and probably dropping blocks once you find that they depend on 64bit operation.

Yes, some games are structured like this. The compiler is actually pretty good about figuring out what's 32-bit code. There are occasionally some problems when returning from 64 bit code to 32 bit code where it's not clear that it can ignore data in the upper halves of registers. I suppose it might be possible to extend the jump_* data structures to flag blocks which require 32-bit registers as input, so we don't drop those blocks when we know that we're passing 32-bit data. It would require some changes to the linker.

The amount of global analysis that can be done is limited since there is always the possibility of code being replaced. However, marking a block (or certain registers thereof) as 32-bit or 64-bit when we compile it may be feasible.

BTW it doesn't drop blocks when it finds they depend on 64-bit operation, it drops blocks when it finds they depend on 32-bit operation. You can extend the 32-bit registers, but you can't arbitrarily truncate 64-bit values.

 

[ari64]

I did the movw/movt thing. Speedup is about 3%.

http://hotfile.com/dl/11894548/d78fdc8/mupen64plus-arm-20090909.tar.gz.html

 

[silver]

I did the movw/movt thing. Speedup is about 3%.

http://hotfile.com/dl/11894548/d78fdc8/mupen64plus-arm-20090909.tar.gz.html

Nice to see you've picked up a 5% and then another 3% on that through various suggestions in the thread. Maybe not your prime concern, but always nice to see...

Can I ask if you are submitting your core the mupen64plus project to incorporate, or will it be a branch project? I note that mupen64plus is currently (aug 09) restructuring the project for v2.0...

Thanks for months the hard work, hope it is/was interesting.

 

[ari64]

I did the movw/movt thing. Speedup is about 3%.

http://hotfile.com/dl/11894548/d78fdc8/mupen64plus-arm-20090909.tar.gz.html

Nice to see you've picked up a 5% and then another 3% on that through various suggestions in the thread. Maybe not your prime concern, but always nice to see...

Can I ask if you are submitting your core the mupen64plus project to incorporate, or will it be a branch project? I note that mupen64plus is currently (aug 09) restructuring the project for v2.0...

Thanks for months the hard work, hope it is/was interesting.

It's still using around half the CPU time on the Cortex-A8, but hopefully these speedups will provide a little more room for smoother framerate/audio.

I suspect a lot of people will want to see this merged into mupen64plus, as it is considerably faster than when they have now (even on x86). However it needs more testing first. I know there are some games that don't work. Mostly this is because of games doing strange things such as reading from memory addresses where there is no memory. So I need to figure out what is supposed to happen in these cases.

The restructuring work is mainly to correct some problems with the user interface and plugins, so this is a somewhat separate project from the dynamic recompiler.

 

[silver]

It's still using around half the CPU time on the Cortex-A8, but hopefully these speedups will provide a little more room for smoother framerate/audio.

I suspect a lot of people will want to see this merged into mupen64plus, as it is considerably faster than when they have now (even on x86). However it needs more testing first. I know there are some games that don't work. Mostly this is because of games doing strange things such as reading from memory addresses where there is no memory. So I need to figure out what is supposed to happen in these cases.

The restructuring work is mainly to correct some problems with the user interface and plugins, so this is a somewhat separate project from the dynamic recompiler.

Well 50% free for the audio/video/overhead sounds quite good at this stage. (esp as I think you are running on a 600MHz Beagleboard).

Interesting this is faster than the x86 mupen core. And yes, would make sense to mature the code before incorporating back into anything else. Thanks for your response.

 

[borgqueenx]

im curious how many frames a second the emulator got right now. For super mario 64 for example. Can we know?

 

[Enverex]

im curious how many frames a second the emulator got right now. For super mario 64 for example. Can we know?

At the moment they are using NULL (as in -no-) video or audio out plugins, which means the emulator is running without video or sound, not really in a state to bench games, plus there's nothing to actually -see- at this point (to anyone asking for videos or screenshots).

 

[borgqueenx]

im curious how many frames a second the emulator got right now. For super mario 64 for example. Can we know?

At the moment they are using NULL (as in -no-) video or audio out plugins, which means the emulator is running without video or sound, not really in a state to bench games, plus there's nothing to actually -see- at this point (to anyone asking for videos or screenshots).

ah ok, sorry to have bothered then.

 

[WizardStan]

im curious how many frames a second the emulator got right now. For super mario 64 for example. Can we know?

Depending on your definition of frames, he's either getting 0 or 100%

 

[Exophase]

I think that the overhead for the graphics won't be bad at all for a majority of games. Of course this relies on the plugin being well optimized - I guess what I mean to say is that it has the potential to be pretty low overhead.

There should be only two things that the CPU has to spend a noteworthy amount of time on: the ucode interpretation engine (ie, geometry/lighting and clipping resulting in display list generation) and texture caching. UltraHLE, Corn, and others were able to pull off both well enough on x86 CPUs quite a bit weaker than Pandora's, using only scalar floating point arithmetic. An optimized GPU plugin for Pandora can use NEON, and can also potentially offload some or all of the per-vertex operations to the SGX if necessary.

Everything else will be offloaded to the SGX, which will probably be able to manage the (usually) 20-30fps N64 games require, while rendering at 640x480. 60fps games may need to be rendered at 320x240. Some amount of per-pixel shading work is going to be necessary to emulate the N64's blend modes. Hopefully games won't use quite too many textures with holes in them, which the plugin will ideally tag (via the texture cache) and sort into a separate render group.

Writing a shader to handle the color combiner generically might tax the SGX too much. But even if you only isolate the per-pixel options (and have the per-vertex ones handled via attributes) there are still a ton of possible combinations. For this reason ig might be better to generate and cache shaders. All of this has nothing to do with CPU load, though. Unless you were crazy enough to try using a software renderer.

 

[Adventus]

I had a look into porting one of the various plugins. I don't think we will get great performance with a direct port. So all those expecting a video of fullspeed N64 should have some patience. Looking at Glide64 i'm surprised it works very well even on x86, it seems to begin/end render a lot of geometry a triangle at a time... like this:

for(i = 0; i < num; i++){
glBegin(GL_TRIANGLES)
glTexCoord2f(...); glVertex4f(....);
glTexCoord2f(...); glVertex4f(....);
glTexCoord2f(...); glVertex4f(....);
glEnd();
}

This is generally very inefficent and i can see no reason why this is neccessary. It also does most vertex transformations in software instead of using modelview matrix, etc. It does however do some nice things, for instance the glide wrapper dynamically generates fragment shaders to emulate blend modes. I actually compiled Glitch64 (the Glide Wrapper) with my OGL wrapper, but i'm currently just getting a black screen.

My biggest worry is we'll hit some crucial feature which is simply not present in OGLES 2.0 or EGL, I've already hit a few features in Glitch which aren't supported. I think it might be better if i try my wrapper on rice_video or something a little bit better written, either way it probably wont be fullspeed until a native port is done.

 

[Exophase]

Adventus, bear in mind that N64 is cited to only handle about 100,000 polygons per second, and there are popular games that push significantly less than even that. The ones that do manage significantly more are probably largely using custom RSP code that the plugin can't support anyway, unless the game is reverse engineered. Really when you think about it, you're going to need a good amount of pixel shader time on more complex combine modes (especially dual-cycle ones). It'd be a shame if you sacrificed framerate or resolution for something further than you need to because of the USSEs handling vertex shading, something they're not really that great at.

Have you looked at glN64? I don't think it has any shader code, but it has a combiner compiler that should make it pretty straightforward to generate shaders with. I wouldn't consider a lack of frameskip that much of an immediate concern. It shouldn't be that difficult to add later.

 

[Pickle]

The things ive seen that cause compiling probelms is the texture combiner in glN64 and the shader programs in rice_video.

 

[Exophase]

Doing a combiner to shader compiler for glN64 would also be of benefit to it on other platforms, since without it it can't accurately support all combiner modes.

 

[Adventus]

Doing a combiner to shader compiler for glN64 would also be of benefit to it on other platforms, since without it it can't accurately support all combiner modes.

Can they be simulated with the glTexEnv() commands? My wrapper is already generating fragment shaders for these.... it might be easier to just add extension to my glTexEnv commands for the modes that aren't supported in OGL.

It'd be a shame if you sacrificed framerate or resolution for something further than you need to because of the USSEs handling vertex shading, something they're not really that great at.

The code i was refering to actually has both a modelview matrix transform and software transformation. Basically all I'm saying is that glide64 is messy and inefficent, a better porting target would be rice_video or, as you say, glN64.

I will have a proper look sometime soon.

 

[Exophase]

Doing a combiner to shader compiler for glN64 would also be of benefit to it on other platforms, since without it it can't accurately support all combiner modes.

Can they be simulated with the glTexEnv() commands? My wrapper is already generating fragment shaders for these.... it might be easier to just add extension to my glTexEnv commands for the modes that aren't supported in OGL.

No. What's offered is much more complex than what is provided in OpenGL's fixed function pipeline. Check out the very information blog post by MooglyGuy for more on the subject:

http://moogle-tech.com/blog/?tag=color-combiner

(it's the one labeled "Combination"; the others are insightful too)

I will have a proper look sometime soon.

Thanks :>

 

[renejr902]

aaaaaaaaaaaaahhhhhhhhhhhhhhhh WOW

i cant believe that people working on N64 for pandora and wiz. HURRAY


thanks Ari64 and pickle.


My wiz is ready to try the n64 emulator pickle


i read all the 16 pages. is it normal i dont understand anything ??? well i understand probably 1 to 3 % not so bad. LOL

HURRAY HURRAY HURRAY HURRAY HURRAY

HURRAY HURRAY HURRAY HURRAY HURRAY

HURRAY HURRAY HURRAY HURRAY HURRAY

HURRAY HURRAY HURRAY HURRAY HURRAY




Is mupen64 a HLE emulation ?? thanks for answer

 

[ldesnogu]

Has Wiz been mentioned in this thread? If so, I have some bad news: the generated code is using some instructions that are not supported by the older processor in the Wiz.