Been a while since I have had time to mess with retroarch. So just yesterday I upgraded to the latest git version in Arch Linux and rebuilt some cores and for some reason it kept crashing on me when I tried to switch games. Then all of a sudden upon a certain reload after said crash, the performance just massively dropped and I haven’t gotten it back since. I went from 60 fps with 3 shader passes to a mere 20 fps with no shaders at all. On top of this it seems to have wiped my playstation memory cards as well. This is in KMS of course. I have tried updating since then and still I can’t get my performance back. Messing with options in the config seems to have no effect. I can use threaded video but massive tearing. Any ideas why this happened all of a sudden? I could understand if it was a driver regression but I was getting good performance on this driver and literally after just restarting retroarch after a crash my performance is shit. I have no ideas.
Is this with all cores or just mednafen-psx? I ask because that core was just rebased and seems to have some issues.
I think it was happening with all cores. I remember trying bsnes and mupen64plus. I’ll try again to confirm.
okay so mupen works fine but bsnes and other cores are way slower than they used to be. Actually they work faster with the glx driver now than in kms? I dunno why though
Maister’s been doing some KMS work lately (past 2 weeks). How long had it been since you updated? Can you git-bisect to find the commit that killed your performance?
This is the first commit (I think) where the KMS work started: https://github.com/libretro/RetroArch/c … 027a1abcc4
You can use git bisect to track down regressions. No idea why things would suddenly be slow though. Try building with make PERF_TEST=1. When running with --verbose you’ll get a dump of performance metrics (frame times in gl_frame(), etc).
EDIT: Did you build RetroArch with make clean first? Build dependency system was recently changed, so that could have caused an issue when building from a pre-update checkout.
I built from the aur so it should have been built from a clean tmp directory. I’ll try the performance tests a little later. The strange thing is when I first started this build it was working fine. It wasn’t until after a crash and restart than performance took a major hit.
Also - regarding Mednafen - honestly, our entire libretro ‘fork’ needs to be rebased on mainline because the current thing is a big humongous mess.
Same goes for Gambatte BTW which is behind upstream by at least 3 years. I really would appreciate it if maister would do a rebasing of the Gambatte port based on sinamas’ current code - I currently have a shallow fork in the libretro organization which could be used for that purpose. It can just be a barebones port so that I can pick it up from there. I just don’t relish going through all the rings-within-rings C++ bullshit that I’ve encountered so far trying to rebase this thing - it’s such an utterly painful codebase really.
Above all, we really need to get more ports pushed upstream. If we do this right with Gambatte, we have that one covered at least - and Mednafen is probably possible as well if we don’t half-ass the port this time again and implement it ‘properly’.