Mupen64Plus

[ari64]

In fact, removing the PLD instructions actually increased performance, which was unexpected and the opposite of what happens on other CPUs.

That's odd: Mans Rullgard who writes the NEON code for FFmpeg said PLD increased performance (you can take a look here git). You should probably schedule these preloads well in advance.

They're scheduled as soon it's known that an address will be needed from the hash table, which is during the JAL instruction.

If the location is already in the L2, then it just wastes 3 slots in the pipeline and 12 bytes of i-cache.

 

[Exophase]

That's odd: Mans Rullgard who writes the NEON code for FFmpeg said PLD increased performance (you can take a look here git). You should probably schedule these preloads well in advance.

NEON streams directly from L2 cache. The actual NEON pipeline happens so far in advance of the main ARM pipeline (where NEON load/stores are done, also why they can appear to be issued simultaneously). So NEON loads are not only zero load-use penalty but hide the entire latency of an L2 cache load. So PLD is probably going to often benefit NEON code more than normal ARM code. Of course, this is a totally different application - when you're streaming a bunch of data preloading is going to have a more obvious benefit than if you're trying to anticipate a single value.
I have a good feeling that what Ari64 is preloading, hash targets for indirect branches, are already in L2 cache a lot of the time because the location was returned from not that long ago.

The Cortex-A8 can be configured with either 16K+16K or 32K+32K of L1 cache. TI did the former, which seems like a very poor design decision.

L1 cache ain't transistor cheap, I'm sure going with 32/32 wouldn't have come for free. I'm kinda disappointed too, though. But it's not as bad as the N64's memory limitations which you defend ;p

 

[Adventus]

Ummm, Just thought i should mention that I've began the glN64 port. You can find the sourcecode here:

http://code.google.com/p/gles2n64/

What I've done:
- Ported to gl-wes-v2.
- Significantly debugged gl-wes-v2.
- Added optimisations to fragment shader generation.
- Added relevant ATI and NV extensions to glTexEnv.
- Rewritten Context Creation.

What needs to be done:
- Debugging!
- Frameskip
- NEON-ized Math3D code.
- More Fragment shader optimisations. If the nVidia Drivers are any indication, I'm beginning to suspect that the OGLES2 shader compiler will do very little optimisation.
- Utilise less gl-wes-v2 and more native OGLES2 code.

Luckily most the required functionality was already present in my wrapper, so i was able to get it working pretty fast. Currently I've only ran it on X86 Win32 + Mupen64 (the original) + gl-wes-v2 + PowerVR OGLESv2 Emulator. Heres the games I've tested:

Super Mario 64 - No glitches.
Super Smash Bros. - No glitches.
Golden Eye 007 - Some glitches (slightly messed up menus and skybox)
Perfect Dark - Glitchy skybox.
Legend of Zelda: OoT - No glitches
Legend of Zelda: MM - No glitches
Banjo Kazooie - Glitchy (Character models are rendered black).
Banjo Tooie - Glitchy (Character models are rendered black).
Paper Mario - Occasional Flicker + some glitchy Menu Effects.
Pilot Wings 64 - No Glitches
Conkers Bad Fur day - Extremely Glitchy (i think there's missing microcode)

The glitches in Conkers bad Fur day, GoldenEye, Perfect Dark and Paper Mario also exist in the normal glN64. The problem with the Banjo games is probably the most pressing, they work well in glN64, i suspect its something to do with an Alpha Combiner not being set correctly. If any one is really keen they can try to run it on a Pandora, though realise that my context creation will probably not work, otherwise i'll do a proper test when my hardware arrives (soon-ish hopefully).

 

[craigix]

Michael will be shipping your pandora today (14th).

 

[ari64]

The glitches in Conkers bad Fur day, GoldenEye, Perfect Dark and Paper Mario also exist in the normal glN64. The problem with the Banjo games is probably the most pressing, they work well in glN64, i suspect its something to do with an Alpha Combiner not being set correctly. If any one is really keen they can try to run it on a Pandora, though realise that my context creation will probably not work, otherwise i'll do a proper test when my hardware arrives (soon-ish hopefully).

Conker and Paper Mario crash the dynarec (execute in unmapped memory) so these will need some more work. I couldn't get either Banjo game to work right in glN64, so I'm not sure you really did anything wrong there. Mario 64 & Zelda should be testable.

 

[Pickle]

. If any one is really keen they can try to run it on a Pandora, though realise that my context creation will probably not work, otherwise i'll do a proper test when my hardware arrives (soon-ish hopefully)

Trying now have it built and debugging

Update:
So close, im not sure if this is a bad driver issue?
[glN64]: (II) Initialize WES...
./mupen64plus: symbol lookup error: /usr/lib/libglslcompiler.so: undefined symbol: PVRSRVAllocUserModeMem

Update 2:
small patch on the changes I did to get this far. Sorry theres some useless edits in it.
pickle.gp2x.de/pnd.patch

 

[midna25]

This all makes me very happy

 

[Adventus]

Conker and Paper Mario crash the dynarec (execute in unmapped memory) so these will need some more work. I couldn't get either Banjo game to work right in glN64, so I'm not sure you really did anything wrong there. Mario 64 & Zelda should be testable.

Seemed to work for me, but i only played a few min. Maybe its because I'm using the original Mupen64.

So close, im not sure if this is a bad driver issue?
[glN64]: (II) Initialize WES...
./mupen64plus: symbol lookup error: /usr/lib/libglslcompiler.so: undefined symbol: PVRSRVAllocUserModeMem

Either that or its because your linking with libOGLESv2.a even though i'm dynamically linking in gl-wes-v2. On the emulator, I have to do this because the EGL functions are actually within that lib, not libEGL.a as you might think :blink: ....

Anyway, I was feeling lazy today so after a few bug fixes (and many downloads) i did some more quick tests, roughly from good to bad:

Diddy Kong Racing - No Glitches.
Mario Kart 64 - No Glitches.
F ZERO X - No Glitches
Star Fox 64 - No Glitches.
San Francisco Rush 2049 - No Glitches
Wave Race 64 - Skybox occassionally flickers.
Ogre Battle 64 - No glitches except inverted alpha on smoke in titlescreen.
1080 Snowboarding - Fine ingame, occasional missing textures in menu.
Mario Party - Minor blending issues.
Jet Force Gemini - Renders fine except draws additional character models in top left corner of screen. Same as glN64.
Doom 64 - Blending is wrong (appears additive instead of mutiplicative), occasional glitches.
Starwars Episode 1 Racer - Geometry is being transformed incorrectly, same as glN64.
Body Harvest - Glitchy, Textures changing place. Weird effect.
Excitebike 64 - Fine Menu, but missing textures in game. Same as glN64.
Starcraft 64 - Alpha blending is not occuring.
Yoshi Story - Menu looks good, but ingame is very glitchy (no buffer clearing is occuring). Same as glN64.
Mario Golf - Many Glitches, worse than glN64
Tony Hawk Pro Skater 3 - Texture Corruption. Same as glN64.
Mario Tennis 64 - Many Glitches, same as glN64
007 - The world is not enough - All the ingame textures are missing.

Keep in mind that this is running through the PowerVR emulator, i cannot guarantee that these will work (or run fast) on the Pandora.

 

[Vorporeal]

Still, it sounds like you're making good progress. Can't wait to see the first benchmarks on real hardware - I'm interested in seeing how well it runs at such an early stage. It'll give us a good idea as to whether or not it's realistic to expect full-speed (or even playable speed) N64 emulation any time in the near future.

 

[Pickle]

Conker and Paper Mario crash the dynarec (execute in unmapped memory) so these will need some more work. I couldn't get either Banjo game to work right in glN64, so I'm not sure you really did anything wrong there. Mario 64 & Zelda should be testable.

Seemed to work for me, but i only played a few min. Maybe its because I'm using the original Mupen64.

So close, im not sure if this is a bad driver issue?
[glN64]: (II) Initialize WES...
./mupen64plus: symbol lookup error: /usr/lib/libglslcompiler.so: undefined symbol: PVRSRVAllocUserModeMem

Either that or its because your linking with libOGLESv2.a even though i'm dynamically linking in gl-wes-v2. On the emulator, I have to do this because the EGL functions are actually within that lib, not libEGL.a as you might think :blink: ....

You mean your dynamically linking at runtime (using dsym)? I actually thought of this after i was done last night, i did it with nanogl to get sround linking issues but I didnt see that you did with the EGL functions. I will try without linking in glesv2.so and see if that issue goes away.

 

[matzesu]

i have here on my usb stick some other roms like: pilot wings, yoshis story, blast corps, harvest moon 64, and rigde racer 64, i would like if thy would run on the pandora..

and thangs you for the great work on the muppen64 for pandora ari64 :rolleyes:

 

[Pickle]

Adventus: I sent you email about this too. I was dynamically linking to glesv2.so for the EGL calls. Ive added the EGL calls to the dsym structures and not linked to glesv2 through LD, maybe this will get around the problem.

 

[fusion_power]

TUROK would be also a very fine Game to test... ^_^
Uh, do we have now 2 Emulators in the Works? "Mupen64Plus" and "glN64"? Well, from the PC Side I've never heard of booth but if they run as good as "Project 64" does (except some glitches here and there) I think it will be superb for the Pandora.
I hope there will be some good ammount of deep Hardware-Access for these Emulator(s) to accelerate everything that is possible to accelerate. The SGX Unit has to sweat!

 

[Pickle]

TUROK would be also a very fine Game to test... ^_^
Uh, do we have now 2 Emulators in the Works? "Mupen64Plus" and "glN64"? Well, from the PC Side I've never heard of booth but if they run as good as "Project 64" does (except some glitches here and there) I think it will be superb for the Pandora.
I hope there will be some good ammount of deep Hardware-Access for these Emulator(s) to accelerate everything that is possible to accelerate. The SGX Unit has to sweat!

Did you get so excited you forgot to read the thread?

Mupen64Plus is the core emulation application (contains the recompiler), it sends/gets video,sound,input data from plugins. So in my case I ran Mupen64Plus with dummy plugins for video, since I didnt have anything to use that would work. This allowed the emulation core to run. Adventus has ported one of the video plugin called glN64. Now that this is ported we should soon be able to "see" the video emulation on the screen.
That was the main reason for this thread is that Ari64 was looking for help in finishing the next part of the n64 emulation, the video plugin.
The sound plugin works, the input plugin should (I have a small issue with linking).

 

[Adventus]

You mean your dynamically linking at runtime (using dsym)? I actually thought of this after i was done last night, i did it with nanogl to get sround linking issues but I didnt see that you did with the EGL functions. I will try without linking in glesv2.so and see if that issue goes away.

At the moment, The GLESv2 functions are dsym'ed, the EGL functions are not. This is because you must get an EGL context before you call any gl* functions like those in wes_init()->wes_shader_init() etc. You should be able to just link the EGL functions via libEGL.a on the pandora (however you cannot do this on the PVR emulator for the reason i mentioned previously).

Anyway there are going to be a few errors before this will work, the ones i know of thanks to Cpasjuste:
1. The DOS line endings in WES.vsh need to be changed.
2. There is a compiler bug which prevents me from using samplers in structs (as is done in the fragment shader). This will need some internal workarounds.

 

[Pickle]

You mean your dynamically linking at runtime (using dsym)? I actually thought of this after i was done last night, i did it with nanogl to get sround linking issues but I didnt see that you did with the EGL functions. I will try without linking in glesv2.so and see if that issue goes away.

At the moment, The GLESv2 functions are dsym'ed, the EGL functions are not. This is because you must get an EGL context before you call any gl* functions like those in wes_init()->wes_shader_init() etc. You should be able to just link the EGL functions via libEGL.a on the pandora (however you cannot do this on the PVR emulator for the reason i mentioned previously).

Anyway there are going to be a few errors before this will work, the ones i know of thanks to Cpasjuste:
1. The DOS line endings in WES.vsh need to be changed.
2. There is a compiler bug which prevents me from using samplers in structs (as is done in the fragment shader). This will need some internal workarounds.

I added code to do dsym the EGL functions(if your interested I can send it), its pretty much duplicate of the gles2, but different structures. But now I get farther maybe where Cpas is at.
I get a dump of the shader file and then this segfault:

0x41135980 in glTexParameteriv () from /usr/lib/libGLESv2.so
(gdb) where
#0 0x41135980 in glTexParameteriv () from /usr/lib/libGLESv2.so
#1 0x40513f04 in TextureCache_ActivateDummy ()
from /home/games/mupen/plugins/gles2n64.so
#2 0x405155a4 in TextureCache_Init ()
from /home/games/mupen/plugins/gles2n64.so
#3 0x40513654 in OGL_Start () from /home/games/mupen/plugins/gles2n64.so
#4 0x4051038c in RomOpen () from /home/games/mupen/plugins/gles2n64.so
#5 0x0800116c in ?? ()

 

[fusion_power]

TUROK would be also a very fine Game to test... ^_^
Uh, do we have now 2 Emulators in the Works? "Mupen64Plus" and "glN64"? Well, from the PC Side I've never heard of booth but if they run as good as "Project 64" does (except some glitches here and there) I think it will be superb for the Pandora.
I hope there will be some good ammount of deep Hardware-Access for these Emulator(s) to accelerate everything that is possible to accelerate. The SGX Unit has to sweat!

Did you get so excited you forgot to read the thread?

Mupen64Plus is the core emulation application (contains the recompiler), it sends/gets video,sound,input data from plugins. So in my case I ran Mupen64Plus with dummy plugins for video, since I didnt have anything to use that would work. This allowed the emulation core to run. Adventus has ported one of the video plugin called glN64. Now that this is ported we should soon be able to "see" the video emulation on the screen.
That was the main reason for this thread is that Ari64 was looking for help in finishing the next part of the n64 emulation, the video plugin.
The sound plugin works, the input plugin should (I have a small issue with linking).

my english is not the best and my time is limited so no, I didn't read the entire Thread.
But yo've explained it very good, thanx. I'm not so familar with this whole "plugin" Philosophy but I think it makes sense to use it.

 

[Luftwaffles]

I'm not so familar with this whole "plugin" Philosophy

Almost every emulator I can think of uses these so called "plugins"

 

[Exophase]

I'm not so familar with this whole "plugin" Philosophy

Almost every emulator I can think of uses these so called "plugins"

Maybe these days a lot of emulators have screen filter plugins but most don't require plugins to operate, outside of a majority of PS1 and N64 emulators, anyway. And on handhelds and other dedicated platforms almost nothing using plugins, for pretty obvious reason.

 

[god_at_hell]

Hm ... the whole bunch of plugins for all the n64-emus and psx annoyed me quite a bit. I prefer simple solutions of other emus like zsnes. Although the plugin system has some advancements.

Anyways: Thx for the effort Ari64 and Adventus and Pickle too. Also I enjoyed the techtalk quite a bit. (didn't read all of it though ... only the first 10 pages and the other thread, since i don't have so much time.)