ParaLLEl-RDP plugin for N64 not available on PC

I looked to see if there was any discussion of this anywhere on this forum, but surprisingly there doesn’t appear to be. My question is, why is this plugin not available for use on either the Mupen64Plus-Next or ParaLLEl cores bundled with Lakka? Mupen64Plus-Next only comes with GLideN64 and the HLE RSP, while ParaLLEl comes with just about everything except the ParaLLEl plugins it derives its name from. From the scripts on github, I can see they appear to be intentionally built without it.

Is ParaLLEl-RDP not working properly with Lakka? Or am I missing something? If I am, I apologize. I have been completely out of the loop for the past 5 years because of real life stuff, and I am barely catching up on all the amazing developments made since then (Vulkan, for example, was barely just being implemented experimentally in RetroArch, last I used it). I decided to build a Lakka box to take full advantage of everything RetroArch now has to offer, but this one thing appears to be out of reach unless I build Lakka myself. Would that be the only option here? Do let me know.

Thank you for the feedback.

Please open an issue next time so that we don’t forget.

We have enabled it, so you can check nightly builds if you want to make some test.

Thank you.

1 Like

Thank you very much. I did ponder opening an issue, but I was unsure whether there was an intentional reason for ParaLLEl-RDP not being included and I didn’t want to clog up the Issues tracker if that was the case, so I erred on the side of caution. In any case, I have tested the latest nightly, and I am glad to say ParaLLEl-RDP works wonderfully with both N64 cores. Unfortunately, my hardware (an Intel Core i5-7500 with integrated Intel 630 HD GPU) appears to be unable to run games above 2x resolution without massive slowdown (and even 2x stutters at times on Mario 64), but that’s on me. Most likely a GPU upgrade is in order here.

I do have a question, however. Which of the two cores is recommended for using ParaLLEl-RDP? From the brief testing I did, it appears ParaLLEl-N64 is faster than Mupen64Plus-Next using roughly the same settings. Other than that, what is the difference? I apologize if this is documented elsewhere, but as I said in the OP, I am a bit behind on all the recent developments in the scene.

mupen64plus-next is based on a much newer mupen base (ParaLLEl-N64 core was forked off many years ago), and, as such, it has a variety of accuracy improvements. This makes some games, such as Pokemon Snap, actually function.

1 Like

Alright, so I ended up getting a cheap ol’ AMD R7 250 to see if that would improve performance with the 3D cores, and after a whole lot of finangling (see the following issue on the Lakka tracker and accompanying discussion), I managed to get it to work with Vulkan. I am happy to say it definitely outperforms the integrated GPU, but unfortunately the drivers do not appear to play nice with the ParaLLEl-RDP plugin, and so the core does not load with that plugin enabled. Something about a lack of support for 8/16-bit storage, per the log.

Looking on Maister’s github page for ParaLLEl-RDP, he does mention for at least the AMDGPU-PRO drivers that they do not work correctly with 8/16-bit arithmetic, and so it has to be switched off. Obviously I am not using AMD’s closed-source drivers, but I AM having to use the amdgpu kernel driver to utilize Vulkan at all, since my card is of the Southern Islands GCN1 family, and it appears the mesa radeon vulkan driver does not fully support it without appending radeon.si_support=0 amdgpu.si_support=1 first. I am wondering if this is at the root of the issue. Might disabling 8/16-bit arithmetic support on ParaLLEl-RDP do something here, as per Maister? How about trying a different driver altogether? RetroArch reports the driver being used as AMD RADV, so it still appears to be using mesa, just with the amdgpu kernel driver underlying. Or am I wrong?

I realize, of course, this isn’t so much a Lakka issue as it is with the drivers and perhaps my card itself, it being something of a special case requiring special arguments to even work with Vulkan, which is why I have not opened another issue on the tracker. Any feedback would be welcome.

Can you make a test with radv llvm backend ?

systemctl stop retroarch
RADV_DEBUG=llvm retroarch -v

Source : Mesa environment variables

If it still does not work you can try to disable 8/16-bit arithmetic support as specified in the README ? As by default, it seems it will now use radv aco backend


Thank you.

1 Like

Alright, I tried those options. First with the llvm backend, then with PARALLEL_RDP_SMALL_TYPES=0, then both combined. None of them work. RetroArch itself works fine with LLVM, and I can boot into cores using Vulkan just fine, but ParaLLEL-RDP always throws the following error before crashing RetroArch altogether:

[ERROR]: Failed to allocate RDRAM. Segmentation fault

Interestingly, the following always appears first, whether using llvm or aco:

WARNING: radv is not a conformant Vulkan implementation, testing use only.

I thought RADV was compliant? Or so Themaister says.

Would the full AMD open source driver work here, I wonder? Recall that I appear to be using only the amdgpu kernel driver to get Vulkan working on this card.

EDIT: Just noticed the following in the log when using the llvm backend:

[INFO]: Selected Vulkan GPU: AMD RADV OLAND (LLVM 12.0.0)

Themaister says the LLVM driver that’s compliant is version 20.0.6. If the log is to be believed, Lakka is using a much older driver. Could this be the issue?

1 Like

Thank you for your tests.

Themaister says the LLVM driver that’s compliant is version 20.0.6. If the log is to be believed, Lakka is using a much older driver. Could this be the issue?

The version number is related to Mesa version and we are using latest stable Mesa which 21.2.2.

You may try to open an issue with the logs of both commands ?

RADV_DEBUG=llvm retroarch -v

And we will know if we have to open an issue to Mesa or not ? :wink:

1 Like

I get the same error when using the ParaLLEI-RDP plugin with Mupen64Plus-Next. The default behavior is a segfault after selecting ParaLLEI-RDP plugin. I’m using the new Lakka 3.5 stable release. My device is a generic PC, with an AMD Renroir APU. Driver in use is AMDGPU.

This is the error message:

[ERROR]: Failed to allocate RDRAM. [libretro ERROR] This device probably does not support 8/16-bit storage. Make sure you're using up-to-date drivers! Segmentation fault

This didn’t work for me:


However, this does work:


It seems the problem isn’t with the 8/16-bit arithmetic, but rather GPU memory allocation. Perhaps a driver issue with implementing VK_EXT_external_memory_host?

Is there any way to set that option at boot?

1 Like

I can confirm that setting PARALLEL_RDP_ALLOW_EXTERNAL_HOST=0 retroarch -v does work on my end as well. Glad to know it’s probably a driver issue and not my card being old as sin! You saved me from splooging on a more expensive RX 550 with the inflated prices being what they are :unamused:.

That said, here’s what the log says, with the game up and running:

[WARN]: VK_EXT_external_memory_host is not supported on this device. Falling back to a slower path.

As well as the following:

[WARN]: Current open-source AMD drivers are known to be slightly faster without 8/16-bit integer arithmetic.

That last bit goes away if I set PARALLEL_RDP_SMALL_TYPES=0, though I do not see an appreciable gain in speed. May have to test further, though.

Overall, even with this supposed “slower path,” this card still destroys my iGPU. I can actually run Mario 64 at 4x resolution with very occasional drops, where the Intel would struggle with 2x. Very nice overall!

EDIT: OoT and Star Fox 64 also run VERY well at 4x. Very, very occasional dips, but not enough to justify going down to 2x. I don’t think I have much if any headroom for shaders, but I’ll try it out later. What are some games that could be worth testing to see if setting PARALLEL_RDP_SMALL_TYPES=0 makes a difference?

1 Like

I was able to figure out how to boot Lakka with these settings, thanks to other messages on this forum.

Simply add this line…


…to this file location.


The Retroarch service will start with the option set.