Input Lag guide

mediamogul

i don't like 'cautionary tweaks' as it now implies that we endorse them, even tacitly. that is the opposite of my intention in documenting them. i don't think anyone should use these tweaks under any circumstances. if they do use them, they are now using their own version of retropie and should ask themselves for help from now on :)

Maybe I'm underestimating the situation, but surely these settings don't qualify as being particularly dangerous do they? I mean, they're not really anywhere near the level of caution that should be observed from an overclock and we support those users who have chosen to do so. Granted, if they come here with troubles related to overclocking we should always recommend they be adjusted, or abandoned outright, but I've never seen it as being grounds to prohibit support altogether.

for example, those settings will get you lost frames when you use even the light crt-pi, etc shaders we suggest elsewhere in the wiki.

I had first posted about Brunnis' initial findings regarding limited shader impact, but missed where he has since rethought the issue. Still, with dispmax enabled, shaders aren't going to be an issue, as they aren't supported with that particular driver. Also, the worst that can happen if performance is affected by shaders is that the user has to make a decision whether input lag, or visual presentation is more important to them. Personally, I prefer to prioritize how a game plays, but each user is going to be different. Allowing a choice here would seem ideal.

what about with bluetooth, or wifi, or anything else that puts (slight) added load to the CPU/bus?

I make use of both and have been actively testing the NES-specific settings I posted on the wiki for several months and I've never dipped below 60fps on a Pi 3.

dankcushions

@mediamogul said in Input Lag guide:

@dankcushions said in Input Lag guide:

i don't like 'cautionary tweaks' as it now implies that we endorse them, even tacitly. that is the opposite of my intention in documenting them. i don't think anyone should use these tweaks under any circumstances. if they do use them, they are now using their own version of retropie and should ask themselves for help from now on :)

Maybe I'm underestimating the situation, but surely these settings don't qualify as being particularly dangerous do they? I mean, they're not really anywhere near the level of caution that should be observed from an overclock and we support those users who have chosen to do so.

perhaps “dangerous” is the wrong word. a moderate overclock can provide a totally safe global benefit (typically invisible but anyway). even an extreme/unsafe overclock cannot damage your system (pi will downclock, etc) so is not “dangerous”.

none of these tweaks can give a wholesale global benefit - they all have a performance cost which will cause a subset of games to drop frames.

i don’t know of a better way of heading that section.

Granted, if they come here with troubles related to overclocking we should always recommend they be adjusted, or abandoned outright, but I've never seen it as being grounds to prohibit support altogether.

i guess i have been doing the support dance for a while now and i find overclocking and input tweaks to be the most tedious to support. they are blindly added and presumed safe, so hard to diagnose. i really like having a link i can just paste in that broadly says “here’s why you messed up”. i think now the link says “here, let us help you mess up” :)

for example, those settings will get you lost frames when you use even the light crt-pi, etc shaders we suggest elsewhere in the wiki.

I had first posted about Brunnis' initial findings regarding limited shader impact, but missed where he has since rethought the issue. Still, with dispmax enabled, shaders aren't going to be an issue, as they aren't supported with that particular driver. Also, the worst that can happen if performance is affected by shaders is that the user has to make a decision whether input lag, or visual presentation is more important to them. Personally, I prefer to prioritize how authentically a game plays, but each user is going to be different. Allowing a choice here would seem ideal.

i don’t think the typical user will connect the dots. same with overclocking. our wiki pages on overclocking/n64 tweaks are a weapon as far as i’m concerned. the benefit is approaching zero, yet the crashing threads are legion.

what about with bluetooth, or wifi, or anything else that puts (slight) added load to the CPU/bus?

I make use of both and have been actively testing the NES-specific settings I posted on the wiki for several months and I've never dipped below 60fps.

are you sure? because it can be subtle. the clouds during motion in mario is a good test. i need to get the benchmarking suite done...

if we’re confident that the settings are safe for pi3 + nes, then they should be defaulted for pi3 + nes (not dispmanx), right? we all run the same hardware.

mediamogul

@dankcushions

You make strong points and beyond anything else, you're the original author of the article. I was hoping that by reworking it, we might open up a few advantages to those extra difficult games that need tighter input timing, but it may very well be that no matter how it's worded, users will apply them without care. I certainly don't want to make support any more difficult and I completely understand that it might. I'm about to sit down to eat, but I'll look into reverting the changes later this evening.

Darksavior

Maybe change it to unsupported tweaks or have the word "unsupported" mentioned in there.

herb_fargus

I think generally over clock/input lag are "advanced user" stuff. That's kinda why I put them in that section(or thought i did) in the wiki. Fact is people are trying to use an underpowered device to do things it's not really meant to do and then wonder why it sploded. I'm personally fine with a giant disclaimer on both pages saying : UNSTABLE: ADVANCED USERS ONLY! then in fine print: if you break it don't come the forum- just reimage and stop while you're ahead ;)

mediamogul

@herb_fargus said in Input Lag guide:

I'm personally fine with a giant disclaimer on both pages saying : UNSTABLE: ADVANCED USERS ONLY!

I'm fine with disclaimers as well, but shouldn't they read as being 'potentially unstable', given that they're also potentially stable under the right circumstances? Something akin to @Darksavior's suggestion of labeling the tweaks as simply being unsupported would remain neutral to the potential outcome, no matter what.

lilbud

@mediamogul I personally think the potentially unstable tweaks shouldn't even be on the page in the first place. Because Gods perfect idiot will come along, screw up their build using settings from the do not use section, then come to the forum kicking and screaming about how their build is screwed.

But, ya know, just my silly personal opinion.

mediamogul

@lilbud

That is one way to go. I mean, there are a few suggestions for reducing input lag listed above that are guaranteed not to cause trouble. Although games like 'Battletoads' and 'Mike Tyson's Punch-Out!!' become considerably easier with the adjustments, I'm fairly confident both games could be beaten without them given some extra practice and memorization. In fact, outside of those two examples and perhaps a few more, there's really no other situations where this is even an issue.

markwkidd

Have you all been tracking the new run-ahead lag reducer function for libretro/RetroArch cores that just debuted around the beginning of the month?

My understanding is that it should be able to shave a frame or two off of the lag for older console emulators even with low-power architectures like rpi.

mediamogul

@markwkidd said in Input Lag guide:

Have you all been tracking the new run-ahead lag reducer function

I have to say I have not, but it sounds like the cat's pajamas. I take it that this is it in action?

markwkidd

That's the very one!

caver01

@markwkidd And this wasn't an April Fool's joke?

markwkidd

@caver01 said in Input Lag guide:

@markwkidd And this wasn't an April Fool's joke?

nope, it's real. this functionality is IMO a landmark in emulation but it happened so recently that history hasn't quite noticed yet

there has been quite a bit of testing. there are likely some bugs still to be found but I think things are reasonably proven in terms of the major classic consoles and the higher performance libretro emulators for NES/Famicom, Genesis/Megadrive, SNES/Super Famicom

markwkidd

The new stable release of RetroArch 1.7.2 has been pending for weeks now because all of these major new features have hit and are still getting little bugfixes

Wait till you see what is about to hit in 1.7.3 in terms of native CRT support in RetroArch

pjft

@markwkidd I struggle to imagine that the look ahead frame improvements on RetroArch will work on the pi, as it has a non-negligible load on the CPU. But I have no facts to base that assumption on, it's just from reading the original technical release.

mediamogul

I read up on it a bit myself and it really does appear to be a tall order for the Pi. Something I found interesting is that the developer behind this feature also created PocketNES for the GameBoy Advance. In it's day, it was a technical marvel with all of it's features and Nintendo even... borrowed the code for their 'Classic NES' line of GBA releases. I'm not sure if the license permitted it, but I remember him being very upbeat about it regardless. Nice guy and a great programmer.

dankcushions

@darksavior said in Input Lag guide:

Maybe change it to unsupported tweaks or have the word "unsupported" mentioned in there.

i like this! that's good wording. i think with this change I would be happy with the rest of the updates. i think that's a good middle ground until such time as we can fully test the settings and use them as defaults for pi3+ nes.

dankcushions

@markwkidd said in Input Lag guide:

Wait till you see what is about to hit in 1.7.3 in terms of native CRT support in RetroArch

i don't think this helps retropie - pi uses a bespoke API for CRT resolutions and the current PR is only relevant to windows, right?

dankcushions

@markwkidd said in Input Lag guide:

Have you all been tracking the new run-ahead lag reducer function for libretro/RetroArch cores that just debuted around the beginning of the month?

My understanding is that it should be able to shave a frame or two off of the lag for older console emulators even with low-power architectures like rpi.

it needs 100% headroom, right? do we have any cores that have 100% headroom on a pi3 (eg, fast forward runs at 2x)?

mediamogul

@dankcushions said in Input Lag guide:

i like this! that's good wording. i think with this change I would be happy with the rest of the updates.

I reworked the headers and added a message regarding their status as specifically being unsupported on the forums. Let me know if you can think of anything else that would make this come across more clearly, and of course, feel free to change any of my wording yourself as you see fit.