Solved FBNeo lagge sur Odroid XU4Q

[Dric]

Bonjour,

Merci pour tout le travail réalisé sur Recalbox 6.1 ainsi que sur les versions précédentes qui me permettent de partager avec bonheur le plaisir du retrogaming sur notre bartop familial

Sur recalbox sur Odroid XU4Q, que ce soit en montée de version depuis la 6.0, ou sur une nouvelle installation from scratch, j'observe que FB Neo a de multiples soucis de performance :

• le rafraîchissement de l'écran est lent/saccadé/flou
• des lags font saccader le son ou ralentir les jeux.
• tout cela rend l'émulation FBA assez inutilisable

J'observe ces soucis :

• sur des jeux "FBA Libertro" : lags très visible sur R-Type Leo, affichage de mauvaise qualité sur Rolling Thunder
• aussi sur des jeux Neo Geo : affichage aussi de mauvaise qualité sur Metal Slug
• aussi bien en shader "retro" que sans shader
• même en ayant désactivé les options "couteuses" en performances comme le rembobinage
• tout cela sur ma configuration avec écran en DVI 1280x1024

Sur la version 6.0 sous FBA, tous ces jeux tournaient de manière totalement fluide.

Je vais essayer de m'installer une autre sd avec une version standalone de retroarch pour comparer... Dans l'intervalle j'ai réinstallé mon backup en 6.0 sur le bartop.

[barbudreadmon]

@dric said in FBNeo lagge sur Odroid XU4Q:

j'observe que FB Neo a de multiples soucis de performance

FBNeo n'a aucune régression de performance sur les jeux cités par rapport à FBAlpha, je pencherai plutôt pour un problème de setup, peut-être un réglage dans les core options ? J'ai fait pas mal de changements là dedans.

@dric said in FBNeo lagge sur Odroid XU4Q:

affichage de mauvaise qualité

çà veut tout et rien dire.

[Dric]

Bonjour,

Merci @barbudreadmon pour ces retours.

Tout d'abord sur ce point :

@dric said in FBNeo lagge sur Odroid XU4Q:

affichage de mauvaise qualité

çà veut tout et rien dire.

J'avais précisé plus haut dans le message les problèmes d'affichage : rafraichissement lent/saccadé, des flous.... Et un impact vraisemblablement lié sur le son qui hache parfois lorsqu'il y a beaucoup de sprites à l'écran dans RType Neo.

Pour voir s'il y avait un problème de setup, j'ai comparé les config retroarch sous 6.0 et 6.1 et j'ai repéré les changements suivants dans les configs par défaut :

• Affichage par défaut en 16 bits sur la 6, 32 bits sur la 6.1 via la valeur de fba-allow-depth-32 lorsque le fichier /recalbox/share/system/configs/retroarch/cores/retroarch-core-options.cfg est généré
• utilisant l'option "shader=retro" dans le menu "format des jeux", je remarque que les shaders utilisés ne sont pas les mêmes :
  • en 6.0, le shader appliqué n'a qu'une passe scanline.glsp provenant de la config suivante :
    • video_shader = /recalbox/share_init/shaders/crt-caligari_gamma_125.glslp dans /recalbox/share/system/configs/retroarch/retroarchcustom.cfg
    • video_shader = /recalbox/share_init/shaders/scanline.glslp dans /recalbox/share/system/configs/retroarch/fba_libertro.cfg et dans /recalbox/share/system/configs/retroarch/neogeo.cfg
  • en 6.1, le shader appliqué a 2 passes avec bsnes_gamma_ramp_115.glsl puis crt-caligari.glsl provenant de la config suivante :
    • video_shader = /recalbox/share_init/shaders/crt-caligari_gamma_115.glslp
      dans /recalbox/share/system/configs/retroarch/retroarchcustom.cfg

Ces différences de configuration par défaut ont déjà un impact important sur le rendu graphique. Cependant elles ne suffisent pas à tout expliquer, en effet :

• en reconfigurant retroarch pour appliquer une configuration absolument identique à FBNeo en 6.1 qu'à FBA en 6.0 (affichage 16 bits et shader 1 passe scanlines), j'ai toujours des lags et du hachage de son lorsqu'il y a beaucoup de sprites
• en supprimant tout shader et avec l'affichage en 16 bits de même, il y a moins de lags et de hachages mais encore un peu
  (ces tests comme tous ceux qui suivent réalisés avec la rom R-Type Leo qui tourne nickel en 6.0 et a des lags et des hachages de son lorsqu'il y a beaucoup de sprites en 6.1)

Du coup, j'ai entrepris une recherche de rootcause à plein de niveaux :

• noyau qui serait moins performant d'une version sur l'autre => possible car ce n'est pas le même noyaux cependant l'émulation Super-Nintendo avec les 2 mêmes passes de shader fonctionnent bien. Idem pour l'émulation PS1 qui est pourtant plus exigeante => On doit pouvoir penser que le noyau est hors cause
• version de retroarch moins performante, soit en raison d'une montée de version soit en raison d'options de compilation différentes => Idem, les tests croisés PS1 et Super Nintendo n''accréditent pas cette thèse
• version des roms utilisées pour les tests => J'ai vérifié, elles sont bien issues du romset 0.2.97.44 et elles fonctionnent parfaitement bien sous Retroarch en core FBNeo sur Android sur une GPD-XD plus => Les roms ne sont pas en cause
• le core FBNeo moins performant que le core FBA, ou compilé avec des options différentes limitant sa performance => Pour tester ce point j'ai voulu testé une version de retroarch indépendante de Recalbox. Je me suis installé une petite SDCard avec la dernière version de Lakka et je l'ai testée sur le même oDroid XU4Q et les mêmes rom. Et bien ça lagge bien plus sous Lakka avec une configuration retroarch identique et même sans shader ! Visiblement l'optimisation sous Recalbox est bien meilleure (merci @barbudreadmon) .
• Les shaders embarqués par Recalbox qui auraient des soucis de compatbilité avec le core FBNeo => J'ai monté une SD avec une version recalbox 6.1 toute vierge, j'y ai remonté / en rw puis j'ai lancé un update des shaders dans retroarch avant de tester à nouveau une config identique à celle que j'utilise en 6.0 => le résultat reste le même avec parfois des lags et du son haché lorsqu'il y a beaucoup de sprites

Après tous ces tests, je ne sais plus quoi faire et j'ai l'impression qu'en l'état des versions de retroarch et du core fbneo je ne parviendrai pas à rétablir une configuration aussi performante qu'en 6.0. Je suis cependant ouvert à suggestions pour d'autres tests si cela peut aider à comprendre et à corriger. Recalbox est un superbe moteur pour mon bartop et je serai heureux de pouvoir aider

Cédric

[barbudreadmon]

@dric said in FBNeo lagge sur Odroid XU4Q:

ces tests comme tous ceux qui suivent réalisés avec la rom R-Type Leo

C'est surtout ton retour d'expérience sur les jeux neogeo qui me fait douter que ce soit un soucis de régression du core en terme de performances, étant donné que ces jeux passent sans soucis sur des SBCs moins puissantes comme le rpi3, même en activant le read ahead.
Quand aux jeux irem M92 comme rtypeleo, ils ont toujours été gourmands, notamment ils ne passaient pas sur pi3b+. Néanmoins il semble qu'il y ait eu du progrès dans le bon sens depuis mes derniers tests sur pi3b+ (l'an dernier) avec ceux-ci :

• sans toucher aux réglages, j'ai gagné environ 2 fps (de mémoire j'étais à 55-57fps et là je suis plutôt à 57-59fps)
• en utilisant les possibilités de downclock ou de frameskip dans les core options, il semble en fait que ces jeux passent désormais très bien sur pi3b+

Bref, si pas de régression (au contraire) sur pi3b+, c'est que ce n'est pas le core qui est en cause, et si tu dis que ce n'est pas un soucis de setup, je n'ai hélas pas beaucoup d'autres pistes :

• soucis hardware
• soucis software autre que le core

PS : t'es sûr de pas avoir une valeur à la con dans la core option "CPU clock" ?

[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é !