The N64 situation

[apersonthinks]

I've found a few plugins/emulators can do the in game menu properly. Project64 w/direct3d 1.7, wii64 (mupen64plus based) w/gln64 and framebuffer textures enabled, and mupen64plus on the PC with Glide64. If a new video plugin is to be ported, i would vote for glide as it is open source and has the least gfx issues in my experience. Also, there are no gles2 ports of glide yet while there are open source gles ports of the rice and gln64 plugins

 

[rohezal]

This would mean that the clock of the GPU really does not matter and performance improvements should be minimal, because bandwidth/latency improvements are rather small compared to the huge frequency bump.

When the triangles are placed in RAM the newer omap is still better. They increased from 166 to 200 mhz i think.

 

[Askarus]

^


From 110MhHz to 200MHz

 

[Letalis Sonus]

^


From 110MhHz to 200MHz

Pretty sure he's talking about memory clock.


Higher memory clock often comes with higher latency, and with that usage scenario a higher latency is rather contra productive, negating the advantage of a higher potential bandwidth - that is actually the reason why you can often hardly notice any advantage of DDR3 over DDR2 over DDR1, the higher latency often simply kills the advantage.


However, the memory controller seems to perform slightly better.

 

[Askarus]

OK, I misunderstood him them.

 

[SNESFAN]

If the bottleneck is the gpu, and you have spare cpu cycles would it be possible to unload some of that work on the cpu instead? Or is that going to be really complicated or not that much return?


I sorry if im getting this wrong i only partially understand what is being said here.


Sent from my MB612 using Tapatalk 2

 

[mcobit]

I am still waiting for someone offloading soundemulation to the dsp

 

[notaz]

..which would likely be a waste as I don't think sound emulation is expensive, you'd waste more cycles synchronizing with the DSP than just plain emulating it on main CPU.

 

[mcobit]

I know, thats why I put the there.

 

[craigix]

If the bottleneck is the gpu, and you have spare cpu cycles would it be possible to unload some of that work on the cpu instead? Or is that going to be really complicated or not that much return?


I sorry if im getting this wrong i only partially understand what is being said here.


Sent from my MB612 using Tapatalk 2

Until we see some actual evidence about all this, that the CPU is idle and it is the GPU at fault, no one can do anything.

 

[Exophase]

Until we see some actual evidence about all this, that the CPU is idle and it is the GPU at fault, no one can do anything.

You didn't read WizardStan's post?


Whether or not anything can be done about it depends on how the GPU's being limited. If it's bandwidth or TMU limited there's nothing the CPU can do to help. If it's shader cycles then some of the load can be moved to the CPU if and only if the GPU is doing any real amount of vertex shading.

 

[craigix]

I read his post but wouldn't you like to see some FPS and further data to make sure it's accurate?


I've not done much programming with modern GPU hardware so I'm not up to speed on why passing the (presumably) low poly count N64 data could be taxing, but I'd like to understand what is going on to make it slow.

 

[EvilDragon]

That should be an easy task. Run N64 emulation and check the CPU usage.


I'll probably do that later tonight just for testing.


I'm also pretty sure it's the GPU and not the CPU though. I didn't even see a speed increase clocking my old Pandora from 800 MHz to 1000 MHz, which tells it's not CPU related.

 

[Exophase]

I don't need to see FPS, his claim that it was only using 70% CPU time at 1GHz is more than enough for me. What I'd want to know is resolution. But you yourself claimed that decreasing resolution makes it faster, that's 100% indicative of a GPU or memory bandwidth bottleneck and the latter is not likely in this case - but can be ruled out by checking if going between 16bpp and 32bpp changes performance.


It's not just polygon count but what the fragment shaders have to do per-pixel to emulate N64's combiners and what have you. You can get an idea of what the shaders can be doing here:


http://code.google.com/p/gles2n64/source/browse/trunk/ShaderCombiner.cpp


There's up to three texture accesses and one of them (noise) has dependent coordinates which is a performance penalty on SGX. SGX530 can only do 1 TMU operation per clock max, so it's not a texturing powerhouse. Also, any textures with any alpha can (depending on the hackAlpha setting) cause fragment discards which is another achilles heel of the architecture.

 

[craigix]

Getting some stats with different resolutions does seem like the best solution right now, I'd like to see that and how it effects FPS and also if the CPU idle changes.

 

[sebt3]

There's up to three texture accesses and one of them (noise) has dependent coordinates which is a performance penalty on SGX. SGX530 can only do 1 TMU operation per clock max, so it's not a texturing powerhouse. Also, any textures with any alpha can (depending on the hackAlpha setting) cause fragment discards which is another achilles heel of the architecture.

"attribute highp vec4   aPosition;                          \n"\

"attribute lowp vec4    aColor;                             \n"\

"attribute highp vec2   aTexCoord0;                         \n"\

"attribute highp vec2   aTexCoord1;                         \n"\

could be changed to :

"attribute mediump vec4   aPosition;                          \n"\

"attribute lowp vec4    aColor;                             \n"\

"attribute mediump vec2   aTexCoord0;                         \n"\

"attribute mediump vec2   aTexCoord1;                         \n"\

to gain a bit (as per the scale2x thread show)

 

[craigix]

Fingers crossed we can get some solid stats to show what does improve performance (without obviously ruining the experience), then the emulator could be defaulted to that set up.

 

[Wally]

Can the GPU do second texture?

 

[Exophase]

Can the GPU do second texture?

Yes. The GPU could've handled N64's texture formats natively too, but it'd just cost more GPU time that apparently isn't really available..

"attribute highp vec4 aPosition; \n"\

"attribute lowp vec4 aColor; \n"\

"attribute highp vec2 aTexCoord0; \n"\

"attribute highp vec2 aTexCoord1; \n"\

could be changed to :

"attribute mediump vec4 aPosition; \n"\

"attribute lowp vec4 aColor; \n"\

"attribute mediump vec2 aTexCoord0; \n"\

"attribute mediump vec2 aTexCoord1; \n"\

to gain a bit (as per the scale2x thread show)

Those are just vertex shader parameters though, the fragment shader is only mediump for texture coordinates. Changing it to mediump for vertex shading may be alright, although to be honest I'm surprised that mediump doesn't cause some problems for fragments, FP16 is kind of low precision where N64 uses 16.16 32-bit coordinates. Maybe it's enough given N64's small texture memory.


It looks like the vertex shader only scales the texture coordinates with the position passed through straight, so changing the latter to mediump probably wouldn't help as much. And it seems to cache the texture coordinate scaling. Not sure how much vertexes uRenderState is set to 1.0, I'm guessing it happens when texture coordinates are changed.. but it might be better to just do that in software w/NEON than even have to process those conditionals on vertexes.

 

[EvilDragon]

Okay, made the test with top - and it seems the stuttering IS CPU related, however, it's a bit weird.


I tried Super Mario Kart which runs perfectly except for some occassional stutterings.


The stutter occurs when CPU Idle goes to about 1% (so CPU is fully used).


Most of the time, mupen runs using about 40 - 70% CPU (even while playing). Sometimes it suddenly goes up to 90%, often just for half a second.


I wonder what causes these peaks? They're happening in gameplay and they seem random to me.


I remember an older version was suddenly hanging for 2 - 3 seconds when playing Mario Kart, after that continuing without any issues.


This seems to be the same thing, but the hang only occurs for a couple of milliseconds.


Is this some bug?