Getting the best N64 experience on a Pi 4

Ka

I have to say I’m really impressed by the performance of Goldeneye on Parallels. It runs so much better than on any other emulator; you can even run it at 60fps! It’s not perfect at full speed like that - it slows down a fair bit, and you get a lot of screen tearing. But it slowed down a lot on original hardware anyway, and Goldeneye looks and plays wonderfully at 60fps. It feels incredibly responsive, and the animation is fantastically smooth.

The only real issue is that some of the textures have huge black lines across them, like tramlines. It’s particularly noticeable on the open Siberian levels, where the black lines cover the snow textures, but it’s not too distracting.

AdamBeGood

@Nakynaw said in Getting the best N64 experience on a Pi 4:

Its seems like the only consensus is about hybrid filter off and overclocking with hdmi_enable_4k60=1, v3d_freq=800ish and arm_freq+2000ish...

I thought there was some controversy around 4k60=1 also, I am sure someone questioned the benefit of that.

It's really good that you are asking the questions though, it would be good to have this stuff nailed down to some degree.

Also does everyone agree on «color to rdram is set to async»?

Where is this option? Is this in the standalone mupen config, or is this a Retroarch menu setting? Not sure what I have mine set as.

ReadyPlayaWon

@AdamBeGood said in Getting the best N64 experience on a Pi 4:

Where is this option? Is this in the standalone mupen config, or is this a Retroarch menu setting? Not sure what I have mine set as.

you can find it in ... /opt/retropie/configs/n64/mupen64plus.cfg

if you search within the mupen64plus.cfg file for rdram you'll find multiple references, but the one relating to color is this one ...

# Enable color buffer copy to RDRAM (0=do not copy, 1=copy in sync mode, 2=Double Buffer, 3=Triple Buffer)
EnableCopyColorToRDRAM = 1

or just disable in the menu

alt text

Nakynaw

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

@Nakynaw You don't need to overclock the CPU at all to run N64. V3D overclocking is the only part of the GPU that a Pi4 needs for any emulation currently. My V3D is set very high, perhaps too high for some. It is stable on MY Pi, in the sense that I Have not encountered games won't work or any instability generally. However I have never run my Pi through a genuine stress test.

And what frequency is that, if you do not mind sharing?

(I just received my second Pi4 (extreme kit) will soon run some test for sure on my side!)

AdamBeGood

@Nakynaw said in Getting the best N64 experience on a Pi 4:

And what frequency is that, if you do not mind sharing?

(I just received my second Pi4 (extreme kit) will soon run some test for sure on my side!)

@Nakynaw It is in his signature at the bottom of his posts! I thought about asking this question too, before I checked there.

@ReadyPlayaWon Thanks for the info!

akamming

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

@Nakynaw You don't need to overclock the CPU at all to run N64. V3D overclocking is the only part of the GPU that a Pi4 needs for any emulation currently. My V3D is set very high, perhaps too high for some. It is stable on MY Pi, in the sense that I Have not encountered games won't work or any instability generally. However I have never run my Pi through a genuine stress test.

I have a different experience. I had some sound stuttering in games like cruis'n exotica which were solved by overclocking the arm to 2000. (in combination with the kms driver and v3d overclock to 815).

AdamBeGood

@akamming said in Getting the best N64 experience on a Pi 4

I have a different experience. I had some sound stuttering in games like cruis'n exotica which were solved by overclocking the arm to 2000. (in combination with the kms driver and v3d overclock to 815).

I hate always being the guy with these questions, but what is "kms driver"?

akamming

@AdamBeGood said in Getting the best N64 experience on a Pi 4:

I hate always being the guy with these questions, but what is "kms driver"?

it's discussed here quite a lot

basically a different display driver for the pi which offloads some work from the gpu to the cpu, which comes in handy when the gpu is the performance bottleneck, like in n64 emulation.

you can enable it in boot/config.txt. This is my config:

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d-pi4,noaudio

be aware: not all software (e.g. kodi, omxplayer) will work with this driver.

AdamBeGood

@akamming Cool, I'll try it out! I only use the Pi for gaming.

Edit: Emulation Station wouldn't load with that in the config, so I've taken it out now.

mitu

Note that this configuration - pure KMS driver - is going to remove support for the emulators relying ondispmanx and they'll not work.

The driver is still marked as experimental right now by the RPI engineers - though it's in a fairly usable state.

basically a different display driver for the pi which offloads some work from the gpu to the cpu, which comes in handy when the gpu is the performance bottleneck, like in n64 emulation.

That's not 100% correct, while the pure KMS has some advantages over the F(irmware)KMS driver, the CPU will not be boosting the GPU performance.

From: https://www.raspberrypi.org/forums/viewtopic.php?p=1507622#p1507247

Kinda offtopic but what is the difference between vc4-fkms-v3d and vc4-kms-v3d?

It's down to what actually drives the video scaler (HVS), pixel valves, and output display blocks (HDMI/VEC/DSI/DPI).
With vc4-fkms-v3d this remains with the firmware, and the firmware still allows DispmanX or MMAL to add extra layers.
With vc4-kms-v3d, the Linux kernel is driving all that lot, and DRM prohibits multiple clients adding layers at the same time.

George Spiggott

I seem to be having a bit of luck with turning off overscan on Mupen64 Plus Next. It doesn't seem to affect screen size on my TV and both SotE and Perfect Dark seem to run faster, Perfect Dark runs fast enough to run in 16:9 640x360 with MSAA without too much slowdown.

@Nakynaw It's in my sig, thanks @AdamBeGood.

dankcushions

@George-Spiggott the overscan option is a bit of a misnomer. you have to adjust the various overscan left/right/etc settings to see an effect. the overscan setting on its own just turns the VI emulation on, which is the part of the n64 that converts the game image to a TV signal. as part of this, it forces it to certain resolutions, sometimes different from the game resolution, which can cause scaling artefacts/blurring. also, i suppose it's an additional graphical operation that could cause some performance issues.

i'll look to getting it disabled by default.

AdamBeGood

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

I seem to be having a bit of luck with turning off overscan on Mupen64 Plus Next. It doesn't seem to affect screen size on my TV and both SotE and Perfect Dark seem to run faster, Perfect Dark runs fast enough to run in 16:9 640x360 with MSAA without too much slowdown.

@Nakynaw It's in my sig, thanks @AdamBeGood.

I see too much screen tearing on Mupen64 Plus Next, and sometimes the Night Vision doesn't work, other times it does.... on my Pi at least. I don't have that kms driver like you do though.

George Spiggott

@AdamBeGood I never got any good results out of MSAA before upgrading to the KMS driver. MSAA delivers some nice improvements to low res N64 games for very little overhead, much less overhead than increasing the resolution. I can see why you would want to wait though.

AdamBeGood

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

@AdamBeGood I never got any good results out of MSAA before upgrading to the KMS driver. MSAA delivers some nice improvements to low res N64 games for very little overhead, much less overhead than increasing the resolution. I can see why you would want to wait though.

I don't want to wait as such, my Emulation Station just didn't load when I turned that setting on in the Config!

lvl0: Error creating SDL window!
    Could not initialize EGL
lvl0: Renderer failed to initialize!
lvl0: Window failed to initialize!

akamming

@mitu said in Getting the best N64 experience on a Pi 4:

That's not 100% correct, while the pure KMS has some advantages over the F(irmware)KMS driver, the CPU will not be boosting the GPU performance.

ok... this is how i understood it. Anyway i am just a user, so i tried to write it down as how i perceive it. apparently not 100% correct.

but to be factual: these are my experiences with the kms driver / 5.x kernel. I'll try to avoid explaining why i have the experiences.

indeed not everything works with kms (as expected).
but i noticed better framerates on serveral emulators (including N64) as of kernel 5.x (don't know the exact number.) in combination with kms driver. So that's why kept on using it.
as of this kernel in combi with kms i was able to overclock the v3d clock more (now stable at 815. Before that i could not go over 750 without making my system unstable). Not 100% sure if this is caused by this kernel / kms driver: I always upgrade to latests supported versions (sudo apt update && sudo apt upgrade -y). And tried to overclock more at the time i got the new kernel and started using this driver. But ofcourse another upgraded component (e.g. firmware) might be the cause of this. This better overclock of v3d led to better performance of several emulators (including N64).
And when i overclocked my arm clock to 2000 i got even better results. (e.g. no more sound stuttering in cruis'n exotica. When i remove the arm overclock it's back...)

George Spiggott

@akamming said in Getting the best N64 experience on a Pi 4:

And when i overclocked my arm clock to 2000 i got even better results. (e.g. no more sound stuttering in cruis'n exotica. When i remove the arm overclock it's back...)

It could be that KMS has changed the load on the CPU significantly. I can't test my overclock setting at the moment but I'd like to investigate this when I can.

Pre-KMS Mupen64 definitely did not benefit from overclocking the CPU as the CPU load on a Pi4 was IIRC around 50%.

akamming

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

Pre-KMS Mupen64 definitely did not benefit from overclocking the CPU as the CPU load on a Pi4 was IIRC around 50%.

it is in my config (using lr-mupen64plus-next) around 55%. but in my experience not having 100% cpu does not mean you cannot benefit from overclock. that depends on the how the code is written. if by turn the gpu and cpu are waiting for each other the cpu load coud be 50% and the emulation would still benefit from a faster cpu.

shavecat

Hey
@rufus
i did your over clock
But im still getting this error after im playing some games .
The temp goes no more then 50 deg'.
Its just writing this error on the left top screen non stop.

DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Failed to create scanout resource

any idea maybe ?

akamming

@AdamBeGood said in Getting the best N64 experience on a Pi 4:

Edit: Emulation Station wouldn't load with that in the config, so I've taken it out now.

weird in that other thread i see a lot of people having a better emulation station performance with that config. On my system emulation station also works fine

Might be that you have omx player enabled in your settings (omx player does not work with kms driver)