Rice2gles and frameskip - do you notice better speed on your devices ?

[scorpio16v]

Just out of curiosity, did framskip remarkable improve speed on other device.
Did anyone a test ?

Here is a comparsion with gles2rice. First without frameskip, second part with frameskip.

Ok, it's not smooth as it should be. But you can say now it's playable.

<a href="http://www.youtube.com/v/DVmBMycAjVs" target="_blank" class="new_win">http://www.youtube.com/v/DVmBMycAjVs</a>

I did the test on Tegra 2.

You only need to add this in mupen64plus.cfg

Code: [Select]

[Video-Rice]

SkipFrame =1

 

[Epic_bubble]

Awesome find scorpio! After enabling frame skip with rice it runs much faster.

[Paul]

I think I'll add in the plugin-specific settings stuff before I release the next update (just in case this setting breaks things on some devices - it probably is a good idea to have a GUI option for disabling it).

[Kris]

I've been a bit unsure what to focus on, for me rice is the faster plugin and any changes I've looked into have only made a small impact, as a percentage a 2-3 fps increase isn't that bad I suppose. The stats show gfx consumes the most amount of time but I guess that doesn't automatically mean it is the bottleneck. Maybe releasing some experimental builds would help me gauge other peoples devices. I've been comparing with frameskip off on both plugins btw.

I had a look at the rice makefile and didn't see any of the compiler options for optimisation I guess they're inherited from elsewhere? If not they can make a big difference even on the desktop version.
-O3 -ffast-math -fsingle-precision-constant -fomit-frame-pointer -ftree-vectorize
and
-mfpu=vfpv3 or -mfpu=neon

[Epic_bubble]

Is there an option to force screen clear with rice? I get the same junk graphics with some games that gles2n64 gives me when that option is disabled.

[Paul]

I had a look at the rice makefile and didn't see any of the compiler options for optimisation I guess they're inherited from elsewhere? If not they can make a big difference even on the desktop version.
-O3 -ffast-math -fsingle-precision-constant -fomit-frame-pointer -ftree-vectorize
and
-mfpu=vfpv3 or -mfpu=neon

Wow, I totally forgot to add those.  I'll put them in and see how it does (probably a lot better...)  Thanks for noticing that!

[Kris]

Is there an option to force screen clear with rice? I get the same junk graphics with some games that gles2n64 gives me when that option is disabled.

There is a rom specific setting to force clear but currently that is ignored and it always clears. I think the garbage might be scissor related and should be simple enough to fix.

Wow, I totally forgot to add those.  I'll put them in and see how it does (probably a lot better...)  Thanks for noticing that!

I'm using those command line options for every library! I don't know if building without symbols will affect your bug reports.

[Epic_bubble]

Wow, I totally forgot to add those.  I'll put them in and see how it does (probably a lot better...)  Thanks for noticing that!

The frame skipping alone made a lot more games playable, with the optimisations added too I could see rice overtaking gles2n64 in performace.

[Paul]

Darn, the flags didn't have a noticeable effect on performance.  I added them to all the native libraries as well.  One flag I'm not sure about is the -mfpu=neon/ -mfpu=vfpv3.  There is no way to know at compile-time whether or not neon will be available (eg. Tegra 2 is ARM7 without neon).  I'm pretty sure I'll have to use -mfpu=vfp instead.  Like I said, no noticeable effect on performance anyway.  At least the frame-skip option helps.

I'm thinking the APP_OPTIM option in Application.mk might be doing some of these flags in the background.  There is a very noticeable difference between options "debug" and "release".  I'll see if there is a way to make ndk-build a bit more verbose so I can see exactly what compiler options it is using.

[Kris]

I can see how the other options didn't really affect it but I would have thought -O3 would have made a difference, it was worth a try anyway. I'll see if I can sort out some variations to try and track down the issue with mario kart issue soon.

[Paul]

Hey, I just noticed that one of those flags (not sure which one yet) fixed the "RAM full of zeros" bug that I was having when APP_OPTIM=release is set in Application.mk.  I'm wondering if it's the -O3 flag.. I'll do some testing to see.  Anyway, thanks - that bug has been bothering me for a long time (eliminating it is way better than the two workarounds I came up with, and should improve performance of the core by not being an unoptimized debug build).

Anyway, sorry to get off topic, scorpio16v.  The frameskip option does improve performance on both of my devices as well.  I'll have an interface to it in the next update.

[scorpio16v]

Oh, off topic isn't bad at all. 

So, I have a audio related question. What does this logcat message mean ?

Code: [Select]

W/AudioTrack(18954): obtainBuffer() track 0x2733c8 disabled, restarting
That's an output, that comes up on every mupen start.
Did you ever play with the different SDL-audio settings ?
All I get are buffer overflow messages, if I set to low values. My goal was to reduce audio quality to speed up emulation.

I realized, that there are many changes possible over config textes. So that's a point I can play with. 
But most times, I had no clue what I did....

[Paul]

I've not done much with SDL audio, but what comes to mind when I read that message is something that OpenAL does.  Basically, when you go to queue a buffer of audio data, if the stream is not playing or runs out of data, you must call "start" on it again (or the buffer just sits in the queue rather than playing).  This is usually a symptom that you're not queuing audio quickly enough, and usually results in audio skipping.

[Paul]

Hey, I just noticed that one of those flags (not sure which one yet) fixed the "RAM full of zeros" bug that I was having when APP_OPTIM=release is set in Application.mk.  I'm wondering if it's the -O3 flag.. I'll do some testing to see.

hmm.. I seem to have broken it with the tests, and can't get it to work again.  Probably just some cached version that was making it work before.  Phewy.

[shuy3n]

FastTexture​CRC=0 makes some 2d elements look better