Beta Mupen64Plus

[HackModford]

So basically the only way to keep better compatibility/speed is to mess with gles2n64?

 

[ari64]

So basically the only way to keep better compatibility/speed is to mess with gles2n64?

Yeah, there isn't much left to do on the dynarec. If I get bug reports, I'll investigate, but I've fixed all the problems that I know of.

 

[HackModford]

Okay Great work Ari64 (you are one of the Gods of the emulation scene of the Pandora)

I'll go pick on Adventus

 

[milkshake]

At some point I will probably look into merging the dynarec with 1.99.3. I haven't done anything on that yet, so if someone else wants to try it then go ahead.

Would this have any benefits for the pandora version? as in are there any improvements to come from merging with 1.99.3?

 

[ari64]

Would this have any benefits for the pandora version? as in are there any improvements to come from merging with 1.99.3?

There are a few improvements in the new version, but the overall compatibility rate hasn't changed much. The reason for moving to the new version would be to use future plugins that are designed for v2.0. There isn't any immediate benefit, it's more of a long-term goal.

 

[IzzehO]

Just a slightly OT question:
With the release of the Panda Board and it's awesome specs: How well is this emulator going to scale across a dual core and would you consider performance increase to be significant on the newer OMAP4430's? I'm definitely looking forward to what the next generation will do for console emulation and am seriously considering picking up a Panda Board just to be the first to try getting GoldenEye at 30fps

 

[ari64]

Just a slightly OT question:
With the release of the Panda Board and it's awesome specs: How well is this emulator going to scale across a dual core and would you consider performance increase to be significant on the newer OMAP4430's? I'm definitely looking forward to what the next generation will do for console emulation and am seriously considering picking up a Panda Board just to be the first to try getting GoldenEye at 30fps

The faster memory access and larger cache of the OMAP4 might improve performance. Currently there is limited multi-thread support so there would be little to gain from dual cores. It would be possible to do graphics or audio on the second CPU, but the current code is not written that way.

I don't think the SGX540 drivers have been published yet, so you won't be playing Goldeneye on your PandaBoard.

 

[Loon]

Just tried Mupen64Plus and I'm seriously impressed. It was a very pleasant surprise to see how well F Zero X works, what really shone for me was how well the Pandora handled the 3D side of things.

This was also my first experience of gaming with the nubs, they have proved to be excellent.

I'm using this version from the Pandora 'App store'.

I've got a couple of questions :

1) What version of the software is this, I'd like to add to the compatibility list but don't think it would be much use without knowing the correct version number.

Edit : Looks like it's version 1.5 from the window title.

2) Do you have to do something unusual to use the keyboard for pausing / quitting etc. when in a game? I can't seem to get it to recognise any key presses when the emulator is running. All the gaming controls work fine though.

Huge thanks to everyone who has worked on this.

 

[HackModford]

Fn-Q or Q or the pandora button quits it. Thats it AFAIK

 

[Schnatterplatsch]

Works great in Mario64, I'm having a lot fun here in the moment. Thanks for that, it's really enjoyable.

Since I haven't watched the developement, can somebody tell me how much space for (I guess you could kill this word) "optimations" there still is? What are the next steps?

Anyway, thanks again for the work you did for us!

 

[Exophase]

The faster memory access and larger cache of the OMAP4 might improve performance. Currently there is limited multi-thread support so there would be little to gain from dual cores. It would be possible to do graphics or audio on the second CPU, but the current code is not written that way.

I don't think the SGX540 drivers have been published yet, so you won't be playing Goldeneye on your PandaBoard.

You don't think the higher clock speeds, OoOE, and shorter pipeline length will help too?

It'd be cool if a really, really optimized software renderer could run on one of the 1GHz Cortex-A9 + NEON cores. I don't really know if this is feasible or not, but I have a good feeling that it'd have to use some radically different techniques than anything yet done for software rendering N64.

All of the hidden costs that could pile up when you start interfacing OGL ES 2 make me nervous.

 

[ari64]

Since I haven't watched the developement, can somebody tell me how much space for (I guess you could kill this word) "optimations" there still is? What are the next steps?

The recompiler is pretty efficient. It might be possible to do some sort of HLE, but I don't have any really good ideas.

You don't think the higher clock speeds, OoOE, and shorter pipeline length will help too?

A lot of the time is spent waiting for the L2 cache. Higher clock speed is helpful if it speeds up the cache. OoOE might help if the processor can do something else while waiting for a memory access.

It'd be cool if a really, really optimized software renderer could run on one of the 1GHz Cortex-A9 + NEON cores. I don't really know if this is feasible or not, but I have a good feeling that it'd have to use some radically different techniques than anything yet done for software rendering N64.

All of the hidden costs that could pile up when you start interfacing OGL ES 2 make me nervous.

It would solve a lot of the issues that have come up with the SGX530 drivers.

Given the relatively small textures and low polygon count on the N64, a software renderer would primarily be fill rate limited. I don't have a really good idea of how many million pixels/sec this would require at various resolutions.

 

[HackModford]

Does anyone have any updates for the graphics plugin? I'm really wishing Ocarina of Time worked (and hoped for some more speed improvements...)

psx4pandora got some love so it's time for this emulator too

 

[Exophase]

Sorry, I missed your responses before.

A lot of the time is spent waiting for the L2 cache. Higher clock speed is helpful if it speeds up the cache. OoOE might help if the processor can do something else while waiting for a memory access.

The point I'm making is precisely that on Cortex-A8, a blocking in-order architecture, a bulk of the time spent stalling for memory is not spent doing something else, so that's always time spent in additional to the time spent NOT doing that. In other words, improving the instructions per cycle during and decreasing the cycle time during the times when you are not stalling will still improve throughput even if you stall for the same amounts. Memory access is not a "bottleneck", even if it's the largest contributing factor to performance degradation (technically I don't think you've proven this). OoOE will also reduce the stall amounts like you say.

The load-use time hasn't changed from Cortex-A8 so of course the L1 cache is faster (or effectively so anyway). The branch misprediction penalty being lower a lot since that's not something that can be hid with OoOE.

It would solve a lot of the issues that have come up with the SGX530 drivers.

Given the relatively small textures and low polygon count on the N64, a software renderer would primarily be fill rate limited. I don't have a really good idea of how many million pixels/sec this would require at various resolutions.

I wasn't really thinking about software rendering at higher than N64 resolutions. The bilinear filtering is what's going to really cost you, since you don't have any kind of scatter gather in the SIMD and have to do all those loads per-pixel. The DSP might be better at it.

 

[ari64]

The point I'm making is precisely that on Cortex-A8, a blocking in-order architecture, a bulk of the time spent stalling for memory is not spent doing something else, so that's always time spent in additional to the time spent NOT doing that. In other words, improving the instructions per cycle during and decreasing the cycle time during the times when you are not stalling will still improve throughput even if you stall for the same amounts. Memory access is not a "bottleneck", even if it's the largest contributing factor to performance degradation (technically I don't think you've proven this). OoOE will also reduce the stall amounts like you say.

I'm not sure exactly what the bottleneck is, but the OMAP3530 is using many more cycles than the number of instructions executed.

The load-use time hasn't changed from Cortex-A8 so of course the L1 cache is faster (or effectively so anyway). The branch misprediction penalty being lower a lot since that's not something that can be hid with OoOE.

The branch misprediction penalty can be reduced by resolving the branch early. I don't know if A9 is capable of that, but other chips do this (eg PowerPC).

I wasn't really thinking about software rendering at higher than N64 resolutions. The bilinear filtering is what's going to really cost you, since you don't have any kind of scatter gather in the SIMD and have to do all those loads per-pixel. The DSP might be better at it.

The bilinear filtering on the actual N64 hardware isn't perfect, and there are some noticable artifacts when viewing textures at oblique angles. I doubt it really does all those loads per pixel. It probably just does one load and interpolates against the previous values if the increment is less than one texel. It looks weird at angles where you've got interpolation along one axis and aliasing along the other.

 

[notaz]

It seems we have "speculative accesses on AXI" enabled in Cortex, and according to this:
http://lists.denx.de/pipermail/u-boot/2010-February/067534.html

it should be better disabled. What do you guys think?

BTW, if you look at 3.2.43 in the manual, there are some cool performance counters supported by A8, and it's possible to have user mode access to then. I can give a module that enables user mode access if anyone wants to play with this.

 

[Exophase]

I'm not sure exactly what the bottleneck is, but the OMAP3530 is using many more cycles than the number of instructions executed.

My point is that there is no "bottleneck", several things contribute to the performance and improving any of them will improve performance.

The branch misprediction penalty can be reduced by resolving the branch early. I don't know if A9 is capable of that, but other chips do this (eg PowerPC).

That's not OoOE per-se. PowerPC is the only popular architecture I'm aware of that can do this implicitly. The ISA design (multiple CRs and a much closer match between flags and conditions) there lends itself much better to this than a traditional flags design. ARM at least has the benefit of letting you not set flags on ALU operations, but you still don't know which condition code you're going to have to predict for. I guess you'd predict all 14 and have the BTB encode the condition code and use the two to predict.

The bilinear filtering on the actual N64 hardware isn't perfect, and there are some noticable artifacts when viewing textures at oblique angles. I doubt it really does all those loads per pixel. It probably just does one load and interpolates against the previous values if the increment is less than one texel. It looks weird at angles where you've got interpolation along one axis and aliasing along the other.

What I've read is that N64 uses a triangular pattern, ie 3 loads per pixel instead of 4. What you're describing would still be almost as bad in software rendering, don't you think?

 

[Exophase]

It seems we have "speculative accesses on AXI" enabled in Cortex, and according to this:
http://lists.denx.de...ary/067534.html

it should be better disabled. What do you guys think?

Definitely worth a shot. The TRM doesn't give any more information on what this does, I guess it's a hint to perform a prefetch on both destinations of a conditional branch.

BTW, if you look at 3.2.43 in the manual, there are some cool performance counters supported by A8, and it's possible to have user mode access to then. I can give a module that enables user mode access if anyone wants to play with this.

Would be appreciated.

 

[notaz]

http://notaz.gp2x.de/misc/pnd/ko/hf4/mod_en_perf_user.ko

it will fail to load but will do it's stuff. After this you should enable counters in Performance Monitor Control Register and Count Enable Set Register at least to get the cycle counter. Other details in the manual.

 

[ari64]

That's not OoOE per-se. PowerPC is the only popular architecture I'm aware of that can do this implicitly. The ISA design (multiple CRs and a much closer match between flags and conditions) there lends itself much better to this than a traditional flags design. ARM at least has the benefit of letting you not set flags on ALU operations, but you still don't know which condition code you're going to have to predict for. I guess you'd predict all 14 and have the BTB encode the condition code and use the two to predict.

What Intel does is to fuse a compare+branch into a single macro-op. This then goes into the reorder buffer and can be issued early if there are no dependencies.

What I've read is that N64 uses a triangular pattern, ie 3 loads per pixel instead of 4. What you're describing would still be almost as bad in software rendering, don't you think?

I don't know what it's actually doing, I just remember seeing the odd glitches. It's very noticable in OoT where you can walk right up to the walls.

It seems we have "speculative accesses on AXI" enabled in Cortex, and according to this:
http://lists.denx.de...ary/067534.html

it should be better disabled. What do you guys think?

Definitely worth a shot. The TRM doesn't give any more information on what this does, I guess it's a hint to perform a prefetch on both destinations of a conditional branch.

I don't know what it does, but I assumed it was doing data prefetches (which could potentially block code fetches).

N64 emulation causes a lot of i-cache misses since doing 64-bit operations with 32-bit instructions tends to be not too good for code density. It'd be better to test this with some other software besides mupen64plus.