Mupen64Plus

[levi]

Wow - I never expected the first video of this to run so well - congrats all!

Looks to me like disabling sound doesn't speed things up much, or perhaps more optimistically I should say, enabling sound doesn't slow things down much at all

 

[Adventus]

I feel slightly cheated . Congrats.

Its been a problem with the dynamic loading of the library. Adding a RTLD_GLOBAL to the second parameter was enough.

What the hell. That's all it was... Wow.

Now the hard part begins. I will be adding NEON optimisations to gles2n64 soon, that might improve the speed. I think with frameskip, this will be very playable. I'm not sure whether the graphics plugin or the emulator should handle frameskip?

 

[JayFoxRox]

Congrats Adventus, you deserve it! Both are great, wes and this plugin (not to mention your Math-NEON project..).
I was also going to add NEON support to it, but you are probably a lot better at it than I'm.
I also started playing with wes to generate dummy shaders to see if the SGX was the bottleneck but that didn't give me any speedup.
Tomorrow, I'll try to use OProfile to get some stats and see where the bottleneck is as I couldn't find it yet without profiler.

Personally I think the graphics plugin should handle frameskip because the emulator is just there to emulate and forward information to the plugins as soon they are available. Wether the plugin will process the data must be decided by the plugin.

 

[noonioo]

It doesn't look to much faster on 850MHz than it does for me with 500MHz... I guess this is an SGX issue. But its just a guess.
I'll probably look into it if I find time for it (Looking for slow parts in wes).
I also started putting my Pandora-PSP controller functions in a N64 input plugin so it can be played.

great job......

we are all desperately looking forward to further improvements of this emulator...

thx

 

[Adventus]

Thanks,

I was also going to add NEON support to it, but you are probably a lot better at it than I'm.

It's more that I've already written and tested NEON-ized 2,3 & 4 dimension matrix-matrix mul and matrix-vector mul for the math-neon project. So i should be able to just drop them in with very little modification.

Some profiling would be great. Here's some simple tests that could be useful:
1. Lower resolution (400x240 would be most interesting). There should be a file called "glN64.conf" in the plugin folder (otherwise you can change it in the Config_nogui.cpp file). You can also disable fog from this file.
2. Disable the use of discard in fragment shaders (or replace with alpha=0). If memory serves me correctly, the "push start" on SM64 is rendered using discards (this may be why mario kart is faster than sm64). You would need to change the wes_frag_alphatest() function in "wes_fragment.c".
3. If floats are the bottleneck, Enable Runfast mode:

void 
enable_runfast()
{
#ifdef __arm__
	static const unsigned int x = 0x04086060;
	static const unsigned int y = 0x03000000;
	int r;
	asm volatile (
		"fmrx	%0, fpscr			\n\t"	//r0 = FPSCR
		"and	%0, %0, %1			\n\t"	//r0 = r0 & 0x04086060
		"orr	%0, %0, %2			\n\t"	//r0 = r0 | 0x03000000
		"fmxr	fpscr, %0			\n\t"	//FPSCR = r0
		: "=r"(r)
		: "r"(x), "r"(y)
	);
#endif
}

 

[ari64]

Wow - I never expected the first video of this to run so well - congrats all!

Looks to me like disabling sound doesn't speed things up much, or perhaps more optimistically I should say, enabling sound doesn't slow things down much at all

Removing the audio plugin doesn't eliminate all the audio processing. There was some prior discussion of this here: http://www.gp32x.de/board/index.php?/topic/49358-mupen64plus/page__view__findpost__p__753190

The beagleboard is also connected to the PC via the S-Video cable which leads to a Capture-Card. And whatever the capture-card captures is shown in "MPlayer"

So I have my normal desktop opened (On 2 screens by the way) and I have a simple window for the beagleboard output and terminals to control it (No additional digital display necessary, simple solution and easy to use)

How did you get s-video working? It doesn't work with the angstrom kernels, and I didn't want to go back to 2.6.22.

Its been a problem with the dynamic loading of the library. Adding a RTLD_GLOBAL to the second parameter was enough.
However, many sources say that this is not the best thing you can do because it could lead to problems.
But hey.. works fine for now. I could imagine that the plugin system is going to be removed later anyway because we have unified hardware and other plugins don't work neither.

Did you compile the latest code from http://code.google.com/p/gles2n64/ with just this one-line change, or are other changes needed to get this working?

The Mupen developers are redesigning the plugin system in the next version. I suppose we can look into merging some of this stuff once things are more stable.

Personally I think the graphics plugin should handle frameskip because the emulator is just there to emulate and forward information to the plugins as soon they are available. Wether the plugin will process the data must be decided by the plugin.

How hard would it be to do rendering in a separate thread?

 

[Adventus]

How hard would it be to do rendering in a separate thread?

Upon further inspection, I think glN64 already has this option under WIN32. We could probably port it to SDL_threads pretty easily.

 

[God Ginrai]

This is great news. Thanks you guys.

Is it me, or is the audio plugin a bit buggy?

-God Ginrai

 

[JayFoxRox]

Adventus: Already tested 2 (I just commented out these lines which have a "discard" in it.) To my surprise there wasn't any visible change on the title screen of SM64. I thought this would have a greater impact after reading so much on it. I expected it to be faster, even if the CPU would be the bottleneck because it should still have slowed down rendering (if "discard"s were included).
I also placed printfs on the texture convert functions of wes to see if anything of that gets called (I know its kinda useless, but I didn't have a profiler and just wanted a quick test).
Going to test the other 2 right now!
//Edit: Changing the resolution didn't work because its depending on the SDL part it seems (without checking the code, but SDL destroys my framebuffer and therefore TV-Out will fail). Atleast 160x120 and 320x240 did not look any different compared to 640x480. I assume its working with 704x480 because thats my framebuffer size (Most other things fail because either timing is not right for TV or the SGX complains about buffer-width not beeing multiple of 32 pixels)
However, recompiling everything with runfast and cortex related gcc switches made it a good bit faster! I'm pretty sure that was a major bottleneck. I'm still running 500MHz and it looks a lot smoother.

Ari64: A lot of stuff in the makefile was just for Adventus his setup so you have to change the compiler etc (I had to do in pre.mk), then the video initialization had 2 OpenGL ES things in wrong order which gave me a warning in the OGLES Emulator (I think eglBindAPI was too late) and SDL destroys my framebuffer so I removed the SDL part.

I'll write a blog entry on TV-Out and SGX asap as it took me a long time to figure it out too.

God Ginrai: Its probably fine, but only stuttering because the emulation is too slow so it can't provide a good audiobuffer all the time (Just guessing)

//Edit:

Some additional screens from SM64 ingame:

Again: Everything in MPlayer comes straight from the BeagleBoard via S-Video (Thats also the reason for the interlacing and why these aren't pixel perfect)

 

[rohezal]

How many FPS do you get with your recompile?
How many did you get before your recompiled?
Has the beagle board a gpu or is it all software rendering?

What FPS would you guess will have the first useable version? Will "normal speed" playing possible?

EDIT: Great work guys. Realy Realy great . You must have spent much time for it. Big thank you

 

[Dead1nside]

Simply amazing work. Well done to all involved, it is eagerly anticipated and much appreciated. Keep up the good work - thank-you!

 

[Exophase]

Looks like SGX is not the bottleneck afterall then. If runfast made a big difference then NEON is an absolute must. No surprise here though.

 

[Adventus]

However, recompiling everything with runfast and cortex related gcc switches made it a good bit faster! I'm pretty sure that was a major bottleneck. I'm still running 500MHz and it looks a lot smoother.

This is great news. Based on what i've done with my math-neon tests runfast gives maybe 10 - 20% improvement, so if that was noticeable NEON optimisation should be fairly significant. I get a 1000% improvement for NEON 4x4 matrix matrix mul and about 600% improvement for matrix-vector mul. Almost every vertex undergoes at least one matrix-vector mul for transformation.... more if you have lighting, etc.

I also noticed that while the graphics can be rendered in another thread on WIN32 its running 100% synchronized to the emulation thread.... so full independence of graphics and emulation threads will probably require some reworking.

BTW: If you want to get the fps outputted every second on stdout, replace OpenGL.cpp line 1076 with "printf("%s", caption);" .

 

[Pickle]

However, recompiling everything with runfast and cortex related gcc switches made it a good bit faster! I'm pretty sure that was a major bottleneck. I'm still running 500MHz and it looks a lot smoother.

This is great news. Based on what i've done with my math-neon tests runfast gives maybe 10 - 20% improvement, so if that was noticeable NEON optimisation should be fairly significant. I get a 1000% improvement for NEON 4x4 matrix matrix mul and about 600% improvement for matrix-vector mul. Almost every vertex undergoes at least one matrix-vector mul for transformation.... more if you have lighting, etc.

I also noticed that while the graphics can be rendered in another thread on WIN32 its running 100% synchronized to the emulation thread.... so full independence of graphics and emulation threads will probably require some reworking.

BTW: If you want to get the fps outputted every second on stdout, replace OpenGL.cpp line 1076 with "printf("%s", caption);" .

I also saw some good improvement with the neon and runfast. I also think sound plugin does eat of some time too
Mario Kart without the sound plugin can average 20+ fps, playable in my opinion.
Ive also tried skipping every other VI_UpdateScreen (UpdateScreen) RSP_ProcessDList (ProcessDList), but im not sure its working since I get above 15 fps.

 

[ari64]

I also saw some good improvement with the neon and runfast. I also think sound plugin does eat of some time too
Mario Kart without the sound plugin can average 20+ fps, playable in my opinion.
Ive also tried skipping every other VI_UpdateScreen (UpdateScreen) RSP_ProcessDList (ProcessDList), but im not sure its working since I get above 15 fps.

When I experimented with frameskip on x86, I ran into a problem where dropping frames would cause the audio to be output too quickly. Then the whole process would block in the audio plugin while it waited for the output buffer to empty. This is why I suggested using separate threads.

 

[Dunny]

I also saw some good improvement with the neon and runfast. I also think sound plugin does eat of some time too
Mario Kart without the sound plugin can average 20+ fps, playable in my opinion.
Ive also tried skipping every other VI_UpdateScreen (UpdateScreen) RSP_ProcessDList (ProcessDList), but im not sure its working since I get above 15 fps.

When I experimented with frameskip on x86, I ran into a problem where dropping frames would cause the audio to be output too quickly. Then the whole process would block in the audio plugin while it waited for the output buffer to empty. This is why I suggested using separate threads.

I'm having trouble imagining how a separate audio thread could be done.

Currently, in my own code, I have three threads - one runs the windows messaging, and spawns two others:

The emulation thread, which contains the audio code. This runs at high priority - emulates a frame of opcodes, and fills the audio buffer. When the frame is done, it sends that buffer to the audio device and then sits there sleeping until that block of audio commences playing (it's always one buffer behind). During that sleeping period, the third thread - the low-priority graphics thread - renders the frame output to the screen. This works well, because if the second emulation thread isn't ready, the graphics thread does not run. This has the rather nice effect of providing an automatic frameskip if necessary. I have some very complex graphics manipulations being done, and they don't subtract CPU time from the emulation and hence you don't get audio glitches. The whole emulator is synchronised to the audio buffer's play rate.

How would you synchronise a fourth thread that just plays audio? Getting proper synch without sound glitches is a nightmare if you don't use the audio for synch.

D.

 

[ari64]

Dunny: Yes, that's the idea. I was referring to a separate thread for graphics, not a separate thread for audio.

 

[ldesnogu]

Making audio clearly distinct from the rest of the code could ease a potential port to DSP. Though I agree synchronisation might be a real nightmare.

 

[silver]

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

 

[ldesnogu]

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

Sorry, but your question makes no sense

Why would you want to disable Thumb exactly? What would it bring?

Thumb is just another instruction set and with Thumb2 you can do more or less the same things as in ARM mode.
You can switch to Thumb mode and switch back to ARM whenever you want (for instance, by using bx with lower bit set to 1 or 0).