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.
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
That sure sounds like it’s switching with the override, which is a big surprise 
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?
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!
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…
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!
Sure, you can make an issue on the ParaLLEl github repo.
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.
Done, let’s see what happens.
Thanks!
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).
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.
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
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.
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
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.
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!
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.
Hi,
Very interesting, thanks for posting your findings. When I get home later I will try changing the buffer swap option to see if it makes any difference for me with my Intel setup on Linux. Will keep you posted…
I tried the buffer swap option, but it didn’t make too much difference for me. In the opening credits for Perfect Dark the audio stuttered less, but as soon as the actual intro kicked in the audio was all over the shop again. This is when using Glide64 and HLE.
This core is definitely a lot slower than I would have expected, but hunterk is suggesting performance between the two should be similar. For me the experience is vastly different between standalone mupen64plus standalone and parallel-n64 when using the same GL plugins. The same applies to the mupen64plus-libretro, this performs better than parallel-n64 too, which is even more confusing.
Hey, sorry to necro the topic but i have the same problem and was wondering if anyone has found a solution over the past year. Not sure if my System is the problem in my case. I only have a dedicated graphicscard with 512Mb VRam … Quadcore 3Ghz CPU should hopfully be fast enough to run it. I can reach like 45-50 fps in F-Zero with Angrylion + cxd4…which makes the sound choppy of course. Dont know how my performance is with Mupen64…the game becomes unbearably slow after starting it, not sure if i have to install the Glide64 plugin manually, cant find an option to set the plugin for the core…so im not even sure if i have the plugin.