Slowdown after update to 4.2
-
@dankcushions
No, I can't say that I did, must not have seen that one on the wiki page. But why would I suddenly need the speed hack when running 4.2 while 4.1 runs perfectly 99% of the time without it? -
@IronAvocado said in Slowdown after update to 4.2:
@dankcushions
No, I can't say that I did, must not have seen that one on the wiki page. But why would I suddenly need the speed hack when running 4.2 while 4.1 runs perfectly 99% of the time without it?you would have enabled it on your 4.1 install. there's no way a pi3 handles it without the speed hack.. it just doesn't have the power.
-
I'll have to fire up the pi to see for sure. Literally the only thing I did to the pie after installing 4.1 was to add the controller, Road Rash, the bios and manually modify these lines:
pcsx_rearmed_neon_enhancement_enable = "enabled"
pcsx_rearmed_neon_enhancement_no_main = "enabled"Nothing else was changed, maybe it was installed by default?
Thank you for the help btw.
-
@IronAvocado the latter setting is the speed hack.
-
@dankcushions
Huh, did not know that, thanks. I just confirmed that both versions of my install 4.1 and 4.2 have bothpcsx_rearmed_neon_enhancement_enable = "enabled"
pcsx_rearmed_neon_enhancement_no_main = "enabled"Yet only 4.2 is experiencing slow down.
-
Being a newbie, I didn't know any better until after the install from source was underway. :(
-
@IronAvocado No worries there. On my x86 instance everything has to install from source and it takes around two hours to update everything. On my Pi 3 it only takes a few minutes.
-
To be blatant, everything after 4.1.5 (or there about) has been much slower. I notice this the most because I'm mainly messing around with Pi Zero's where every little change in the programming is noticed 4 times as much (since it's ~25% of the Pi 3's power). I've also noticed this, albeit to a much less degree, on how smooth things play on my Pi 3's as well.
There's several topics which mention this from different people if you want to look around - I'm sadly one who always complains (and then am told I'm the only one and if it happened to more people - since the RetroPie image has been downloaded over 500,000 times - that more people would be complaining....OR that it's an upstream problem that has nothing to do with RetroPie)....so I don't know what to tell you besides to stay with 4.1 for the foreseeable future.
-
@IronAvocado 4.1 (afair) had a bug that the dynamic recompilation was disabled by default. It was fixed with a a binary update. It's worth testing with the core settings on 4.2 switching this setting on / off. I don't see any other upstream changes that should affect performance but I will test.
-
@Dochartaigh said in Slowdown after update to 4.2:
To be blatant, everything after 4.1.5 (or there about) has been much slower. I notice this the most because I'm mainly messing around with Pi Zero's where every little change in the programming is noticed 4 times as much (since it's ~25% of the Pi 3's power). I've also noticed this, albeit to a much less degree, on how smooth things play on my Pi 3's as well.
No it hasn't. Everything has not been slower. There may be some issues on some emulators, but not everything (and I need real test cases, not generalisations).
There's several topics which mention this from different people if you want to look around - I'm sadly one who always complains (and then am told I'm the only one and if it happened to more people - since the RetroPie image has been downloaded over 500,000 times - that more people would be complaining....OR that it's an upstream problem that has nothing to do with RetroPie)....so I don't know what to tell you besides to stay with 4.1 for the foreseeable future.
I'm getting a little tired of you repeating this -when there are reproducible performance issues they are looked into. You were the only one reporting slowdowns with that particular emulator (fceumm as I remember), and I was unable to see any significant/noticable performance decrease when I did some testing. The quicknes emulator is a better fit for the zero anyway. There was some alignment code changed in fceumm, but I tested with and without it, and it seemed the same.
Other issues that multiple people have reported have been fixed. CoolCV which was due to an SDL2 bug. a previous lr-pcsx-rearmed performance issue due to an error in an upstream commit (which I fixed).
-
@BuZz
BuZz, you know I appreciate what you and your team do, right? - and how I've said that numerous times before because I mean it. Take that as the truth please. And that's why I'm still on here posting (hopefully helpful) things when I can.My only complaint is how I follow the scientific method with repeatability to the extreme (you've read the type of tests I do on multiple hardware, multiple computers, multiple setups all the way around) - and can reproduce every single one of my problems on like 6+ systems (which I've literally done), yet still get told it can't be reproduced...then read about other peoples same issues on the like 10 different forums I'm on...
But anyway, I'm giving up on this pursuit, ok? You have my word. Not another word has to be said about it– as I still want to be welcomed on this forum and not be shunned and not get help when I need it. Fair enough?
/end rant/end thread crapping
-
It doesn't come across as though you appreciate it.
Regarding performance issues - You tested on multiple machines, but you left out plenty of configuration details, and I was unable to reproduce - perhaps you can provide me with two minimal images illustrating the problem (on another thread - of course, don't include any roms).
I've certainly not seen many people on here reporting the same issue as you, and often issues are totally urelated- I need to be able to reproduce an issue to fix it (or report it upstream).
-
@IronAvocado Please can you provide me the output of this command typed into a terminal over ssh
grep "^pcsx_rearmed" /opt/retropie/configs/all/retroarch-core-options.cfg -
pi@retropie:~ $ grep "^pcsx_rearmed" /opt/retropie/configs/all/retroarch-core-op tions.cfg pcsx_rearmed_frameskip = "0" pcsx_rearmed_region = "Auto" pcsx_rearmed_pad1type = "default" pcsx_rearmed_pad2type = "default" pcsx_rearmed_pad3type = "default" pcsx_rearmed_pad4type = "default" pcsx_rearmed_pad5type = "default" pcsx_rearmed_pad6type = "default" pcsx_rearmed_pad7type = "default" pcsx_rearmed_pad8type = "default" pcsx_rearmed_multitap1 = "auto" pcsx_rearmed_multitap2 = "auto" pcsx_rearmed_drc = "enabled" pcsx_rearmed_neon_interlace_enable = "disabled" pcsx_rearmed_neon_enhancement_enable = "enabled" pcsx_rearmed_neon_enhancement_no_main = "enabled" pcsx_rearmed_duping_enable = "enabled" pcsx_rearmed_spu_reverb = "enabled" pcsx_rearmed_spu_interpolation = "simple" pcsx_rearmed_pe2_fix = "disabled" pcsx_rearmed_inuyasha_fix = "disabled" pcsx_rearmed_show_bios_bootlogo = "disabled"This is what I get when I SSH in.
-
@IronAvocado please can you post your
/opt/retropie/configs/all/retroarch.cfgand/opt/retropie/configs/psx/retroarch.cfg(use a code block - http://commonmark.org/help/ - or external pastebin site) -
I just tested with those core options on my RPI3 development set-up.
800x600 video, no overclocking, retropie 4.2
road rash plays smooth, and retroarch shows a pretty constant 60fps.
So must be something else different with your set-up
(I'm going to test building from source also). Did you try re-installing the emulator from binary ?
-
Still 60fps when building from source too.
-
@IronAvocado Please also post your
/boot/config.txtand the output ofuname -a -
I thought I knew what I was doing but I guess not. When I try to open either of those files I get a permission denied error. Are those the exact lines I need to enter on the command line? Thank you for your patience, I'm pretty stupid.
-
Pretty much confirmed that I'm too stupid to handle diagnostic work, sorry Buzz. Everything I'm doing is returning permission denied errors and I can't get anywhere. I setup root access, logged in as root with my new password and I still get access denied errors when trying to open those files. The only thing I was able to get a result from was when I ran uname -a
Linux retropie 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/LinuxWill probably wind up doing more damage to the pi the longer I continue down this path.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.