Solved FBNeo lagge sur Odroid XU4Q

[Dric]

Bonjour,

Merci @barbudreadmon pour tes retours complémentaires.

J'ai continué mes investigations sur la base de ces échanges, en excluant le problème hardware (puisque je fais tourner sans problème Recalbox 6.0 sur l'une de mes SD).

J'ai ainsi réalisé plusieurs optimisations pour revenir à une configuration identique à celle qui fonctionnait bien en 6.0.

Ainsi j'ai retrouvé un framerate soutenu de 60fps et une bonne jouabilité sur tous mes tests Neo Geo et FBNeo.
Ca passe tout juste pour RTypeLeo et aucune optimisation n'est de trop

Je partage ci-dessous les optimisations réalisées pour aider ceux qui rencontreraient les même soucis que moi.

1) La configuration hardware dans le boot.ini
Le noyau et le fichier de configuration /boot/boot.ini ont été changés en passant à la 6.1, notamment pour intégrer un paramétrage de la DRAM qui n'existait pas sur le boot.ini de la version 6.0 :

# DRAM Frequency
setenv ddr_freq 900

# set DDR frequency
dmc ${ddr_freq}`

Cette configuration à 900 Mhz m'a laissé perplexe car la documentation de overclocking de RAM sur l'oDroid XU4 ne semble pas prévoir pas cette fréquence. Je l'ai donc modifiée pour la passer à 933Mhz comme prévu par la doc :

# DRAM Frequency
setenv ddr_freq 933

# set DDR frequency
dmc ${ddr_freq}`

L'impact sur le framerate est immédiatement visible sur RTypeLeo. Au final par contre je ne sais pas dire si je reviens ainsi à une configuration identique à celle qui existait en Recalbox 6.0 ou si j'overclocke maintenant ma DRam compensant ainsi une config noyaux moins performante sous 6.1. (Si quelqu'un a la réponse je suis preneur !)

2) Les shaders "RETRO" et de manière générale la config retroarch
Sous Recalbox 6.0, j'avais une configuration de shader globale "RETRO" qui appliquait crt-caligari_gamma_115.glslp dans\RECALBOX\share\system\configs\retroarch\retroarchcustom.cfg :

[...]
video_shader = /recalbox/share_init/shaders/crt-caligari_gamma_115.glslp
video_shader_dir = /recalbox/share_init/shaders/
video_shader_enable = true
video_smooth = false

ainsi qu'une surcharge pour fba_libretro et neogeo pour appliquer à la place scanline.glslp
dans\RECALBOX\share\system\configs\retroarch\neogeo.cfg et \RECALBOX\share\system\configs\retroarch\fba_libretro.cfg

video_shader_enable = true
video_smooth = false
video_scale_integer = true
video_shader_dir = /recalbox/share_init/shaders/
video_shader = /recalbox/share_init/shaders/scanline.glslp

Enfin, la configuration par défaut du codre FBA sous Retroarch n'utilisait pas la profondeur de couleurs à 32 bits par défaut.

J'ai réalisé une configuration équivalente sous Recalbox 6.1 :

• J'ai configuré le menu "OPTION DES JEUX" pour mettre comme shader global "RETRO"
• Puis j'ai réalisé la surcharge pour fba_libretro et neogeo en changeant la méthode car celle utilisée en 6.0 ne fonctionne plus. Pour cela j'ai configuré dans \RECALBOX\share\system\recalbox.conf les options fba_libretro.shaders et neogeo.shaders suivantes :

## Shader set 
## Automatically select shaders for all systems
## (none, retro, scanlines)
global.shaderset=retro

#  13/10/2019 : Je force des shaders plus adaptés pour FBNeo (FBA Libretro et Neo Geo)
fba_libretro.shaders= /recalbox/share_init/shaders/scanline.glslp
neogeo.shaders= /recalbox/share_init/shaders/scanline.glslp

• Enfin, j'ai désactivé la profondeur de couleur 32 bits maintenant activée par défaut pour le core FBNeo. Pour cela j'ai modifié l'option dans le menu retroarch ce que je peux aussi observer dans \RECALBOX\share\system\configs\retroarch\cores\retroarch-core-options.cfg

fbneo-allow-depth-32 = "disabled"

Comme indiqué ci-avant, avec toutes ces modifications, j'ai retrouvé un framerate soutenu de 60fps et une bonne jouabilité sur tous mes tests Neo Geo et FBNeo, parfois peujt-être un microglitch qui n'existait pas sous recalbox 6.0 (le FPS affiché décent vers les 59.5) mais c'est maintenant tout à fait supportable et cela permet de bénéficier des avantages de la 6.1 comme les vidéo dans Emulationstation

Cédric

[barbudreadmon]

@dric said in FBNeo lagge sur Odroid XU4Q:

j'ai désactivé la profondeur de couleur 32 bits maintenant activée par défaut pour le core FBNeo

Attention quand même, je sais que certains jeux (je n'ai malheureusement pas la liste) auront des glitches graphiques sans ce réglage, raison pour laquelle je l'ai passé en réglage par défaut. Je suis également assez surpris que çà ait un réel impact sur les perfs sur un xu4 car çà n'en a aucun sur mon pi3.

Juste pour confirmer, vu que tu n'as pas répondu à la question, tu es bien à 100% pour le "CPU clock" ? J'ai corrigé le fonctionnement de celui-ci qui par le passé n'appliquait pas du tout les bons coefficients par rapport aux valeurs choisies (par exemple une valeur de 190% applique désormais vraiment un OC de 190%, par le passé on était plus proche des 160% avec le même réglage). J'ai également ajouté la possibilité d'utiliser des valeurs inférieures à 100%, ce qui permet, si le jeu utilise ce réglage, de baisser la charge cpu et d'avoir un meilleur framerate, sans que le jeu en souffre forcément (beaucoup de bornes d'arcade n'utilisaient pas 100% de la puissance de leur cpu, donc baisser la fréquence de celui-ci n'a pas d'impact).

[Dric]

@barbudreadmon Effectivement je n'avais pas répondu. Oui, je suis bien à CPU clock 100%

Concernant la profondeur de couleur, ça contribue un peu à l'amélioration comme tous les autres paramètres... Et sans les avoir tous changé j'ai des lags un peu désagréables niveau son....

[Dric]

@barbudreadmon Suite à ton dernier retour j'ai refait des tests et :

• Tu as raison, l'impact de la profondeur de couleur est minime voire insensible..
• Grace a ton explication sur le rôle de "CPU Clock", j'ai pu rendre RtypeLeo totalement fluide, comme auparvant, en baissant uniquement pour lui CPU Clock à 50% via un fichier d'option propre à ce jeu.

Au final, j'ai donc rétablir la profondeur de couleurs à 32 bits et je pourrais utiliser CPU Clock pour chercher un meilleur framerate si d'autres roms me posent souci. Merci

[barbudreadmon]

@dric said in FBNeo lagge sur Odroid XU4Q:

en baissant uniquement pour lui CPU Clock à 50%

Le jeu est fluide sur mon rpi3b+ à 70%, vraiment bizarre que tu aies besoin d'un réglage aussi bas sur ton odroid. Je vais sortir mon xu4 du placard pour voir si j'ai ce genre de soucis avec une RB 6.1

[barbudreadmon]

@dric après test, je confirme avoir rencontré le même problème (çà tournait moins bien que sur mon pi3b+), la bonne nouvelle c'est que j'ai trouvé le soucis : il faut désactiver le threading video dans la configuration de retroarch (ne me demande pas pourquoi, j'ai juste essayé de désactiver l'option vu que çà me semblait bizarre qu'elle soit activée par défaut) et çà va BEAUCOUP mieux.

[Dric]

@barbudreadmon said in FBNeo lagge sur Odroid XU4Q:

Le jeu est fluide sur mon rpi3b+ à 70%, vraiment bizarre que tu aies besoin d'un réglage aussi bas sur ton odroid. Je vais sortir mon xu4 du placard pour voir si j'ai ce genre de soucis avec une RB 6.1

En fait je n'avais pas pas cherché à mettre le meilleur réglage. J'avais mis 50% et j'ai vérifié en testant que le jeu allait bien alors je m'étais arrêté là.

J'ai refait des tests et j'ai un jeu presque tout le temps fluide à 85%, juste des petites pertes de frame à 2 joueurs à la fin du 1er niveau lorsque les météores explosent de partout. Pour rester systématiquement à 60 fps dans tout le niveau en étant 2 joueurs tirant de manière effrénée je dois descendre à 70%.

[barbudreadmon]

@dric comme dit au dessus, tu n'as même pas besoin de downclock le cpu, désactive le threading video et le soucis sera réglé, visiblement il y a un gros soucis de perf avec cette option sur xu4, et je doute que fbneo soit le seul core impacté.

[Dric]

@barbudreadmon Merci !!!! Après modification de l'option je retrouve les performances de la 6.0 (au moins !) et toutes mes optimisations précédentes ne sont donc plus nécessaires.

Du coup, la seule question qui restait était "comment rendre cette désactivation permanente ?".

Pour cela j'ai utilisé la surcharge de configuration (décrite ici) en créant un fichier .retroarch.cfg directement dans le partage share (/recalbox/share sous linux en ssh) contenant juste :

video_threaded = false

Les performances sont de retour. Merci pour ton aide

[vva]

Salut!
Je n'avais pas de lags ou autres sur mon XU4Q, mais j'ai quand même rajouté ce .retroarch.cfg au cas où...
J'ai juste eu le temps de jouer 10 minutes à Street of rage 1 et 2 sur megadrive, ils étaient juste injouables, tout était au ralenti..!!!
Je l'ai donc viré, et tout est revenu à la normale...?!?
Je n'ai pas eu le temps de tester sous FBNeo....

[barbudreadmon]

@vva said in FBNeo lagge sur Odroid XU4Q:

J'ai juste eu le temps de jouer 10 minutes à Street of rage 1 et 2 sur megadrive, ils étaient juste injouables, tout était au ralenti..!!!
Je l'ai donc viré, et tout est revenu à la normale...?!?

Étrange, je ne rencontre pas ce soucis, les 2 jeux fonctionnent parfaitement avec ou sans cette option, que ce soit avec picodrive ou genplusgx. Il doit y avoir un second paramètre qui rentre en compte dans ces baisses de perfs liées au threading video.

D'ailleurs je remarque que l'émulateur mégadrive par défaut pour RB XU4 est picodrive, alors que genplusgx est recommandé quand on a une machine suffisamment puissante (un rpi2 est déjà suffisamment puissant), des glitches sont d'ailleurs visibles sur street of rage 1 avec picodrive (sur les écritures en haut de l'écran).

[vva]

@barbudreadmon Problème résolu...! Je n'ai pas d'explication rationnelle, mais en créant un nouveau fichier directement dans Cyberduck (application qui me sert à me connecter en local sur Mac) ça a fonctionné.
La première fois, j'avais créé le fichier avec TextEdit, l'avais enregistré en .rtf auquel j'avais changé l'extension par .cfg....
La ligne à l'intérieure était la même, à ceci près que comme j'avais fait un copier/coller de la ligne "video_threaded = false" ci-dessus, la couleur de typo et le fond de texte avaient été copiés aussi, du coup je les avais passé en typo blanche sur fond incolore...
Est-ce possible que le problème soit venu de là? Aucune idée....

[Dric]

@vva Hello, j'ai fait moi aussi des tests ce matin, je tiens parfaitement le 60fps sur les Street of Rage

Effectivement le format .rtf embarque beaucoup d'informations, pour le format, qui n'existent pas dans un simple fichier texte. Sous Mac il faut bien penser à sauvegarder en "plain text"

[barbudreadmon]

@vva said in FBNeo lagge sur Odroid XU4Q:

Est-ce possible que le problème soit venu de là? Aucune idée....

Le format rtf est un format texte avec mise en page, les fichiers de config ne doivent jamais contenir de mise en page (leur vocation première est d'être lu par un programme et non par un humain, avoir une mise en page n'a donc aucun sens), il est probable que ton fichier contenait des données de mise en page additionnelles qui faisaient apparaître ton fichier comme étant corrompu du point de vue de l'émulateur, et il est possible que charger ce fichier de configuration corrompu ait mis un peu de chaos dans la configuration de RA.

[Dric]

@vva Et d'autres tests, sur Super Nintendo (ex: Donkey Kong Country) ou Playstation (ex : Crash Bandicoot), passent nickel aussi avec le fichier .recalbox.cfg évoqué ci-avant + shaders "Retro" + lissage des jeux + pixel perfect. Et pour ma part rembobinage toujours désactivé, on n'est pas là pour tricher

[vva]

Ok, merci pour toutes ces infos, je vais essayer de me trouver un éditeur de texte plus approprié !

[Bkg2k]

Ne vous cassez pas trop la tête avec le threaded_video, elle sera désactivée par défaut dans la 6.1.1.
En attendant, vous obtiendrez le même résultat avec une surcharge globale dans votre repertoire /recalbox/share/roms.