ParaLLEl-n64 performs badly but other emulators ok - any ideas why?!

RetroArch Linux devices
#1

Hi,

I am working on getting my n64 emulator working the best I can via an x86 install of RetroPie. All other emulators targeted at x86 are working well, Dolphin, etc. I also have Vulkan working nicely for Dolphin and libretro-beetle-psx-hw.

However, with n64 using the ParaLLEl emulator, the performance really isn’t great. It doesn’t matter which gfxplugin I use, or whether I run Retroarch with the GL or Vulkan driver, it’s nowhere near as strong as either the Mupen64plus standalone or the mupen64plus-libretro emulators.

In fact, using the Vulkan driver, the performance is an absolute disaster on the default settings, and i’ve tried using the ParaLLEl plugin. However Vulkan works ok with Dolphin and Beetle-HW. Angrylion is better with the tweaks mentioned on the blog, but still no good. Going back to GL works better, but the audio is choppy some games and in general, games like Perfect Dark (the intro for example) really seem to underperform.

Now I know ParaLLEl is more focused on accuracy and perhaps it is more taxing than mupen64plus-libretro, but there is a light and day difference between using ParaLLEl and any other n64 emulator. It’s quite strange.

I am running Ubuntu MATE 16.04, Intel Core i5-4590T Processor (4th Gen), 8gb RAM, Intel HD Graphics HD4600. I know the graphics card is not exceptionally strong, but it does run Dolphin, upscaled Dreamcast, PSX, PSP, very well, and I can run n64 titles with no issue in the other emulators. I can even ramp the resolution up a fair bit with no obvious drop in fps.

I did try running Mupen64plus with both GlideN64 and Glide64, these work well, as does mupen64plus-libretro, even just leaving everything at default. But if I run the same game with the Glide64 plugin on ParaLLEl, the performance is nowhere close, although of course i’m sure it is more accurate. The same goes for other plugins. I have tried to turn the accuracy down on the emu, but it seems to make little difference.

Does anyone have any ideas? Perhaps there are some settings I have missed which will transform ParaLLEl into something usable? Or is it really just massively heavier and resource hungry than Mupen64plus? Maybe there is a performance issue with the emulator on Linux?

I guess I am trying to work out whether to pursue using ParaLLEl with this project, or whether I should just stick with one of the other emulators. With ParaLLEl under constant development and having most of the GFX plugins all under one roof, I figured this would be the best one to use, but i’m a bit stuck as to why the performance is so poor.

Thanks!

#2

The ParaLLEl RDP (vulkan) plugin is very demanding in one specific area: async compute. AMD cards are awesome at this, and my crappy workstation GPU (like a 240 or something…?) gets full speed with plenty of headroom. However, it also requires the cxd4 RSP, which is a very big CPU bottleneck.

On linux, threaded Angrylion is still only barely usable, as it requires both the cxd4 RSP and it doesn’t gain as much benefit from the threading as on Windows for some still-to-be-determined reason.

The OpenGL plugins (mostly Glide64; the others aren’t particularly interesting, IIRC) don’t require the LLE RSP, which helps a lot, and their requirements should be relatively modest. I’m suspecting that it’s not actually using those plugins when you’re trying it, as it will transparently switch to vulkan if the vulkan video driver is active. To use the GL plugins, you need to go to settings > driver and change the video driver to “gl”, exit RetroArch and then reopen it, then load the N64 core/content.

Mupen64plus-libretro is still a good core, despite not getting any updates since last February. I still use it for most things because it’s easy to use and doesn’t require much/any tweaking of settings. A small handful of games don’t work with it vs upstream (Resident Evil 2, Rogue Squadron, a couple more), so it’s still great for the vast majority of games. Otherwise, standalone m64p with GLideN64 is apparently quite nice, though I haven’t used it.

#3

Hi there,

Thanks a lot for the reply.

Regarding the OpenGL plugins, as it stands now, my Retroarch is already configured for GL as default, because i’m only using Vulkan for Beetle-PSX-HW, Dolphin (which is configured separately anyway) and my experimentation with the Parallel-n64 core.

So at the moment, i’m using core overrides for PSX and N64 to change the video driver to Vulkan for these emulators only.

I’m sure the plugins are loading fine in GL, because if you have the Vulkan driver active - the performance is not as good all round on any plugin. Angrylion is sort of ok-ish for some games when implementing the tweaks, but it does slow down too much and things like the Perfect Dark intro stutter all over the shop. Switching back to GL by removing the core override yields better performance on plugins like Glide64, but the performance is still poor when compared to using Mupen64plus-libretro on GlideN64, or when using standalone Mupen64plus with either GlideN64 or Glide64. The Perfect Dark intro is a good example, the only way I can get this to run smoothly with ParaLLEl is to use the RICE plugin. All other plugins are really poor whether you use GL or Vulkan drivers. In contrast, Mupen64plus-libretro or standalone with GlideN64 or Glide64 seem to be fine on GL, out of the box.

This is what is confusing me a bit - how the two emulators can be so different in performance even when you try to use the same plugin (Glide64) in GL mode. I assumed ParaLLEl must be more demanding in a few key areas i’m not aware of, or maybe it’s not well optimised for my hardware / OS. But as you say, the requirements for using Glide64 etc should be relatively modest, so i’m not sure why ParaLLEl struggles in some games when the others just work.

Any other ideas how I can improve ParaLLEl with any other preferences? Or do you think maybe I am best sticking with Mupen64plus-libretro, or using the standalone version with either the GlideN64 or Glide64 plugins? It would be good to improve ParaLLEl, but i’m a bit stumped as to why the performance is behind the others so much.

Thanks!

#4

To my knowledge, overrides aren’t enough to change the driver because the core is already initialized by the time it checks for them. If they were changing the driver, I believe it would crash because of an incompatibility with the menu driver/shader/context.

When you use Beetle-PSX-HW, does the texture filtering option work? I ask because it’s only functional with the GL renderer and does nothing with the vulkan one.

#5

Hi there,

Cheers for the response.

For me, Beetle-PSX-HW is loading the vulkan driver, because the filtering, 32bit and wireframe options do nothing when selected. Also, my Vulkan specific .slangp shader loads (which is also inside the override file). If I remove the video_driver = “vulkan” from my core specific retroarch.cfg, as well as the shader entry, it loads GL and the GLSLP shader - because these are specified in my global retroarch.cfg. I can then change the filtering and 32 bits modes and they take effect on the screen immediately.

Even though the renderer is still set to ‘vulkan’ (because of the core-options file), it doesn’t actually crash. But it is definitely rendering in OpenGL, presumably as a fall back because Vulkan is not available.

I’d have thought ParaLLEl works in the same way. Don’t forget my global retroarch options are GL as a video driver, and I only put Vulkan in my core specific retroarch.cfg file when I want it (like Beetle above). And when I have Vulkan in there, filtering does nothing, indicating the core is using this driver.

However - I did test anyway removing from my n64 retroarch.cfg file and changing the global driver to Vulkan. Vulkan loads just like it did previously so I think my core specific retroarch.cfg files are working fine.

When I have Vulkan as a driver, ParaLLEl is pretty awful (speed wise) in all modes, and out of the box it runs extremely slowly. When I remove it, it is better (because it’s now using GL and filtering options make a difference), but still nowhere near as good as the other emulators which also use GL. Perfect Dark intro for example stutters no matter what the settings, even on what would be considered baseline. But the other GL n64 emulators are fine, as is using Vulkan on Beetle and Dolphin.

I just cannot work out where this massive performance drop is occurring when trying to use ParaLLEl.

Any other ideas?

Hope this all makes sense.

Cheers

#6

That sure sounds like it’s switching with the override, which is a big surprise :open_mouth:

Moving on, there shouldn’t be anything that it’s doing specifically that would make it significantly slower than anything else with similar settings. Is there anything showing up in the log? Warnings being spammed, etc?

#7

Yeah i’m glad it switches with the override, this means I can have GL set as the global video_driver, but use Vulkan for the 1 (or possibly 2) emulators which use it within Libretro.

As for the log, RetroPie has it’s runcommand launcher which has a verbose mode which I think outputs what you are after.

Vulkan driver loaded, emulator defaults: https://pastebin.com/br64K2er

GL driver loaded, emulator defaults: https://pastebin.com/zUf2Q8Pq

This is for the first 30 secs or so of Perfect Dark, which seems to tax things the most on both renderers. Some other games are ok on ‘gl’ but hopeless on ‘vulkan’. If I use another GL core, they all perform much better and would be more in line with what i’d expect (eg. I can ramp things up a bit before performance starts to drop off). Mupen64Plus with GlideN64 standalone I think is probably the best performance wise, but the libretro one isn’t too far behind it.

Thanks!

#8

Ahh, if you’re launching through EmulationStation or whatever then, yeah, you can change drivers on load.

Nothing looks unusual about those logs, AFAICT. I think the complaints on the vulkan one are due to dropped frames (i.e., from the low framerate), so no surprise there.

Shrug, dunno man…

#9

Hi,

Thanks again. Ah yes, I forgot to mention I am launching via ES, sorry about that.

I know, I cannot see anything strange either with the logs. It shows what I would expect. And agreed, the complaints on the vulkan one coincide with the low framerate I get across the board.

Really confused! Not sure if it is a driver thing, something else related to my system or hardware, or OS. Or maybe there is an issue with the core, but only with certain hardware.

What do you think - is there a viable place to report this in case one of the devs wants to take a look?

Otherwise, I do have alternatives to be fair. But would like to use ParaLLEl in the long term if it’s possible.

Thanks!

#10

Sure, you can make an issue on the ParaLLEl github repo.

#11

Sure, i’ll do that now and reference this thread. I am happy to provide any additional logs that may help just in case it is an issue with the core.

Thanks a lot for the assistance.

#12

Done, let’s see what happens.

Thanks!

#13

To me, it seems that’s all par for the course with your CPU and GPU. Running on Windows might make it a bit better, but overall ParaLLel with cxd4 RSP and vulkan RDP/Angrylion is just that demanding (yes, more than Dolphin).

#14

Hi,

Thanks for the reply. I can understand that to a degree when using the Vulkan driver, the framerate is atrocious when using the ParaLLEl gfx plugin, and somewhat better with angrylion but still not good enough to be usable. I didn’t necessarily expect Vulkan to work well on my hardware, but I hoped it would be usable after having such success with Dolphin and Beetle-PSX-HW.

The thing which is confusing though which makes me believe there is a more fundamental issue, is that when using GL, the performance is still really poor when compared to the other cores. So why would ParaLLEl using the Glide64 gfxplugin and HLE or any of the other non-vulkan plugins be much slower than mupen64plus w/ Glide64 or GlideN64 and also libretro-mupen64plus? Is ParaLLEl doing some other stuff in the background which is really taxing my hardware that the other emulators do not do? Or are there some other settings which I can disable to bring it more in line with the others? I have tried pretty much baseline settings in ParaLLEl to try and speed things up, but it makes no odds to the poor performance. I can run the other cores with higher resolution, texture filtering etc with no noticeable slowdown, so the gap is fairly big.

Thanks for the help.

#15

Also, just to mention not all games are unplayable in GL mode, but definitely the performance is less across the board. Vulkan is a non starter but I understand maybe that’s too much for my hardware under Linux. I certainly cannot get the Perfect Dark intro to run smoothly without extremely choppy audio unless I choose the RICE gfxplugin under any circumstance, whereas the other cores are good out of the box even with a few enhancements.

An unrelated question to this issue, do you happen to know what ‘auto’ chooses by default for GFX and RSP? Can this differ per game, or does it always default to, say, Glide64 and HLE?

Thanks

#16

I’m not an expert, but I don’t think ParaLLel was designed to be used with plugins other than cxd4 and angrylion. The fact that it can use glide64, for example, is just a coincidence.

I switched from vulkan to gl, forced glide64 and hle rsp and launched GoldenEye. The speed was wildly fluctuating between too fast and too slow (I have an i5 2500k and a 760 GTX) and it was most certainly not working correctly. It’s a low-level emulator meant for low-level emulation, I don’t think mixing it with HLE is a good idea.

#17

Hi,

That’s very interesting - it is sort of comforting to know you are getting performance issues on a machine with a better GPU than mine when running in the other GFX modes.

It was my understanding that ParaLLEL-n64 was borne out of the existing libretro-mupen64plus core, but that core still exists and is still occasionally maintained, however it only uses the GlideN64 plugin (which is unavailable on ParaLLEl). This is why I assumed that the ParaLLEl-n64 emulator would be at least comparable performance wise to the other cores, seeing as it was based on one of them, although it has different plugins, it still has Glide64, etc, etc. But none of them work well.

Do you see what I mean? Perhaps i’m wrong about the above, but either way I can see that ParaLLEl concentrates on being an LLE emulator, so maybe you are correct and it’s simply designed to be used with Angrylion and cxd4. If this is the case, maybe support for the others should be removed and users should be pointed to libretro-mupen64plus or mupen64plus w/GlideN64 if they need to run HLE based emulation for performance reasons.

Thanks

#18

I get approximately similar performance out of parallel-libretro with glide64 (RDP and RSP plugins set to ‘auto’) as I get out of mupen64plus-libretro.

#19

That is interesting too and exactly what I was expecting, given that ParaLLEl is originally based from mupen64plus-libretro (i believe?). But when I have the defaults set for the core, and either leave the plugins as auto for RDP and RSP or explicitly set them to Glide64 and HLE, the performance is definitely worse than mupen64plus-libretro. For me they are not close in performance.

Such a strange one!

#20

Hmmm… I spent some more time with it and it seems that my wild fluctuactions have something to do with the buffer swap option. If I switch it, the speed goes back to normal (but only in glide64, gln64 is still too fast, not to mention glitchy).

Performance is definitely better than with cxd4+angrylion; however, it is still slower than normal mupen64plus core. I didn’t do complete measurements, but GoldenEye works fine in m64p, while in ParaLLel+glide64 it slows down considerably when playing.

I’m using Windows 10, nVidia drivers 388.x and 390.65, latest Retroarch nightly and cores.