What the hell. That's all it was... Wow.Its been a problem with the dynamic loading of the library. Adding a RTLD_GLOBAL to the second parameter was enough.
JayFoxRox said: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.
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.I was also going to add NEON support to it, but you are probably a lot better at it than I'm.
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
}
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__753190levi said: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![]()
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.JayFoxRox said: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)
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?JayFoxRox said: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.
How hard would it be to do rendering in a separate thread?JayFoxRox said: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.
Upon further inspection, I think glN64 already has this option under WIN32. We could probably port it to SDL_threads pretty easily.How hard would it be to do rendering in a separate thread?
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.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.
Adventus said: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.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.
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);" .
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.Pickle said: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 said: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.Pickle said: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.
Sorry, but your question makes no sensesilver said: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?