COM - FFB 360Hz avec IRacing

Un peu après la guerre, mais ça se passe par là sur le forum officiel :

More detailed FFB (360Hz) from 24S2? — iRacing Forums

Les achanges entre David Tucker (iracing) et Mika Takala (simucube) sont interessants pour comprendre l'implémentation.

Je vais mettre un resumé des messages des deux ce soir

Mika Takala

19 février 10 :16

iRacing calcule toujours le FFB et fait d’autres choses à 60 Hz. À ce rythme, il communique la dernière valeur FFB via DirectInput, mais il calcule également des échantillons de 360 Hz de manière rétrospective et les rend disponibles dans la carte de mémoire de télémétrie.

C’est aux développeurs de matériel comme nous de proposer une API qui permet d’envoyer un lot d’échantillons dans l’appel 60 Hz qui serait autrement un appel standard à DirectInput. Cela est maintenant implémenté dans l’empattement du Simucube 2 et il semble prometteur que nous puissions l’inclure dans la mise à jour 24S2.

Par rapport au mode 360 Hz d’iRFFB, nous sommes vraiment à 16,67 ms de retard. IRFFB lit les données à partir de la carte mémoire où les données sont disponibles plus tard que via un appel FFB direct d’iRacing, et iRFFB a également besoin de faire tourner ses propres threads pour communiquer des échantillons individuels à une fréquence de 360 Hz. Il en résulte un retard total d’environ 29 ms dans l’iRFFB.

Je vais faire quelques tests de stabilité FFB, mais en ce qui concerne cela, le mode 360 Hz n’est pas une solution miracle. Il y a quelques détails supplémentaires sur FFB.

David Tucker

20 février 21h50

Cela nous permet donc d’envoyer plusieurs échantillons à la roue en un seul appel, pour une lecture à une fréquence plus élevée. Cela supprime la contrainte temporelle qui nous oblige à essayer de faire passer les échantillons très rapidement sans ajouter de gigue. Il devrait vraiment s’agir d’un appel intégré dans DirectInput. L’avantage ici est que nous pouvons laisser passer des signaux de fréquence beaucoup plus élevés à travers la roue. Avec les appels DirectInput direct, nous étions limités à environ 20-30 Hz max, et avec cet appel, nous pouvons générer des fréquences allant jusqu’à environ 120-180 Hz. La grande majorité des signaux sont inférieurs à 20 Hz, mais cela aide toujours dans des situations dynamiques, comme lorsque vous heurtez un trottoir.

Cela n’améliore pas la stabilité, cela ne peut se produire qu’avec une réécriture de notre moteur physique, et ce n’est pas quelque chose que nous pouvons faire en une saison. Il fait essentiellement ce que fait irFFB, mais à côté du firmware des roues, donc avec un timing beaucoup plus précis. En théorie, cela signifie que la roue peut également faire un meilleur filtrage, car le signal entrant a plus de données à haute fréquence avec lesquelles travailler.

À l’heure actuelle, il n’est disponible que sur la molette Logitech PRO, et Simucube est maintenant presque terminé. Cela fonctionne très bien sur une version de développement, mais il y a un peu de polissage qui doit être fait avant qu’il puisse être distribué aux membres. Je ne sais pas si nous le sortirons la saison prochaine, ou dans un patch/saison ultérieur, mais nous en sommes très proches. Je dois dire que Simucube a fait un excellent travail sur ce point, le signal passe très proprement, sans transitoires ni bruit. Cela fonctionne très bien.

Mika Takala

20 février 23 :39

Je suis d’accord. Nous sommes très proches de la mise en œuvre et de l’intégration, mais les prochains jours nous diront s’il est prêt pour un public plus large lorsque nous aurons d’autres testeurs pour le tester.

D’après ce que j’ai ressenti lors des tests, nous devons régler le filtre de reconstruction pour en tirer le meilleur parti possible, ce que nous faisons également, mais ce sera dans une version ultérieure du firmware.

David Tucker

26 février 18 :46

Dustin a raison, nous ne pouvons pas utiliser DirectInput à partir de deux threads. Nous devrions déplacer toute la logique de gestion du joystick dans le nouveau thread qui fonctionne à 360 Hz, puis retarder le signal de 1 image afin que nous puissions vous le lire. C’est possible de le faire, mais les inconvénients sont aussi importants que les avantages.

En poussant les données tout de suite en une seule fois vers la roue, ils peuvent utiliser leur boucle interne beaucoup plus précise pour lire le signal, et ils peuvent également faire une meilleure interpolation et un meilleur filtrage.

Idéalement, nous serions plus rapides, mais c’est un énorme projet qui implique de découper toute la simulation en morceaux et de la réorganiser. Et le potentiel d’aggraver les choses plutôt que de les améliorer est énorme. Pourtant, c’est quelque chose que nous examinons. Mais même dans ce cas, c’est toujours une bonne idée que la roue elle-même puisse prélever plusieurs échantillons à la fois. Il était pratiquement garanti que la physique serait toujours plus rapide que notre boucle externe, quelle que soit la vitesse à laquelle nous construisons la boucle externe. Et la précision de synchronisation est beaucoup plus facile à maintenir, lorsque la roue fait le travail dans sa boucle interne (généralement bien au-dessus de 1 kHz).

Mika Takala

27 février 14h13

Notre plate-forme de firmware actuelle est différente d’environ 80% de ce qu’elle était pour Simucube 1. Il s’agit donc d’un travail de « recommencement » et pas seulement de copier-coller pour un produit en fin de vie pour lequel nous ne recevons aucun revenu.

Mika Takala

11 mars 01 :58

Simucube a le filtre de reconstruction depuis 2017 qui fait la mise à l’échelle, et nous pensons que cela vaut la peine à 100% de faire le truc 360Hz. Mais je suppose que tout le monde ne l’aimera pas.

Mika Takala

12 mars 13 :23

L’implémentation est terminée (en attente de tests). Cela a pris environ une demi-heure. La grande question est qu’il y a eu des mises à jour de la couche d’abstraction matérielle de bas niveau qui sont dans Simucube 2 mais pas 1. Ceux-ci affectent la minuterie qui est utilisée pour sélectionner l’échantillon à donner au servomoteur.

La prochaine étape pour moi est de trouver un bouton d’arrêt d’urgence pour mon ancien Simucube 1 unité... Je n’ai pas l’impression d’en avoir un de plus à la maison...

Mika Takala

mars 14 11 :43PM

Le filtre de reconnaissance n’ajoute pas de décalage tel quel. Je ne pense pas qu’il y ait d’autre logiciel d’empattement que les MMOS obsolètes de nos jours qui ont des filtres basés sur la moyenne si simples qui ajouteraient un décalage à l’ensemble du signal. Un réglage élevé du filtre de reconnaissance a plus de « gain de puissance » sur l’interpolation du signal et peut dépasser si la direction du signal change rapidement, de sorte que certains pics peuvent avoir un léger retard.

David Tucker

15 mars 18 :11

Vous êtes le plus susceptible de le remarquer sur les trottoirs (en particulier les bordures 3D), c’est-à-dire là où le signal aura le plus de données à haute fréquence. Et en général, cela devrait adoucir les bordures, car nous remplissons les points. Ainsi, au lieu de 3 points pour une onde de bordure, qui ressemble plus à un triangle ou à une onde carrée, vous obtenez 18 points, qui ressemblent plus à une onde sinusoïdale, de sorte que l’effet global est un signal plus lisse.

Je peux pirater la simulation pour qu’elle fonctionne à 360 Hz (en enlevant presque tout sauf votre propre voiture) et cela rend les pneus « caoutchouteux » sur les bordures, comme s’ils en avaient un peu de souplesse. C’est agréable, mais c’est plus doux, c’est sûr.

Mika Takala

18 mars 21 :33

Les commentaires sont notés.

iRFFB dispose également des paramètres de télémétrie basés sur FFB - amélioration du sous-virage et du survirage - qui sont certainement quelque chose que certaines personnes aiment.

Malheureusement, ces implémentations d’effets dans la base de code IRFFB sont sous licence GNU General Public License (GPL). Cela signifie qu’il serait dangereux pour nous d’aller jeter un coup d’œil au code et de le copier, car nous aurions alors besoin de publier le code source complet de notre firmware ainsi que la licence GPL est assez toxique de cette façon.

Et de toute façon, notre logiciel d’empattement n’est pas capable de lire le flux de télémétrie du jeu pour le moment. Nous verrons comment implémenter des effets similaires lorsque nous aurons un lecteur de télémétrie implémenté dans le logiciel de pilotage de l’empattement. Mais nous devons faire attention à ne pas aller voir comment IRFFB fait les effets de l’addon.

Mika Takala

21 mars 11 :29

Merci pour les graphiques ! Il semblerait donc que le « bruit » soit là indépendamment du fait que le FFB soit en mode 360 Hz ou en mode DirectInput 60 Hz ? Nous soupçonnions David que cela était dû au retard supplémentaire, mais ce n’est peut-être pas le cas après tout. J’ai découvert que d’autres paramètres de notre profil FFB ont également un effet sur cette vibration, il s’agit donc probablement d’un type de résonance entre la fréquence de vibration du signal d’entrée, les filtres de traitement FFB et le délai supplémentaire en mode 360 Hz.

L’ajout d’un filtre passe-bas de 150 permettra bien sûr de lisser cela, mais tous les détails nets du FFB sont également filtrés.

Si vous courez beaucoup avec la voiture IR-18 - nous nous excusons, mais efforçons-nous d’améliorer la situation également pour l’utilisateur général afin qu’il n’y ait pas de telles surprises intéressantes.

David Tucker

21 mars 22 :13

C’est ainsi que la plupart des voitures devraient ressembler. Il ne se passe généralement pas grand-chose au-dessus de 20 Hz dans la FFB. Dans certains cas, les signaux s’élèvent au-dessus de 20 Hz, notamment sur les bandes de vibration et lors de l’impact sur un trottoir à grande vitesse. Mais dans 90% des cas, les signaux seront plus ou moins synchronisés.

En ce qui concerne l’IR-18, Eric est en train de l’examiner en ce moment, j’espère que nous pourrons faire le ménage.

David Tucker

21 mars 22 :16

Je soupçonne que c’est ce qui se passe. Le signal de 360 Hz est plus fluide, ce qui le rend plus léger. Je parie que si vous superposiez les signaux ensemble, vous remarqueriez à peine une différence. Mais il serait intéressant de regarder un exemple.

David Tucker

22 mars 12 :33

Auto regarde toujours le signal 360 Hz, peu importe le mode dans lequel vous avez le jeu de roues. Et il utilise un histogramme pour pouvoir jeter les pointes, afin qu’elles n’aient pas trop d’influence sur le signal.

David Tucker

22 mars 18 :56

Si la molette utilise un filtre de reconstruction, réglé sur 60 Hz, ces deux pistes auront le même aspect sur la sortie. C’est-à-dire que le filtre de reconstruction interpolera les échantillons pour remplir les choses afin qu’elles ressemblent plus ou moins au tracé de 360 Hz. Ce n’est que dans le cas où les deux signaux n’ont que des données bien inférieures à 60 Hz. Toutes les roues n’ont pas de filtre de reconstruction, mais la plupart des roues DD en ont.

C’est l’une des lacunes de l’entrée directe, que nous ne pouvons pas leur dire quel est le taux de mise à jour cible, de sorte que les fabricants de roues doivent deviner et espérer juste.

David Tucker

22 mars 19 :05

Pour être très clair, nous abusons de DirectInput pour nous permettre d’envoyer un signal haute fréquence à la roue. Il n’a jamais été conçu pour cela. Ils s’attendaient à ce que vous utilisiez des effets prédéfinis la plupart du temps, et que vous n’envoyiez des forces directes que dans les cas où les effets prédéfinis ne pouvaient pas être mis à jour assez rapidement. L’ensemble de la conception a été réalisé à l’époque où les ordinateurs étaient monothread et où la physique était principalement constituée de tables de correspondance.

Nous avons vraiment besoin d’une nouvelle norme qui permette aux développeurs d’envoyer des signaux dont l’amplitude et la fréquence sont connues, et idéalement regroupés, avec plusieurs échantillons à la fois. Ces appels à 360 Hz qui se développaient avec les fabricants de roues sont un pas dans cette direction. Ils nous permettent d’envoyer une amplitude de force connue et de dire à la roue quelle est la fréquence cible, afin qu’ils puissent développer correctement des filtres pour le signal. Et comme les échantillons sont regroupés, le timing peut être contrôlé pour une lecture parfaitement fluide (avec une touche de latence). Vous pouvez bien sûr également mettre en mémoire tampon des échantillons réguliers pour contrôler la gigue, si vous êtes d’accord avec une touche de latence.

Tout ce qui manque, c’est une norme unifiée (moyen) de communiquer ces nouvelles idées à la roue, afin que tous les fabricants de roues puissent la mettre en œuvre sans trop de difficultés. Il s’agit en fait d’un gros projet, il s’agit probablement d’une nouvelle norme USB HID (idéalement plus rapide que 1000 Hz). Et sans Microsoft, il serait très difficile d’obtenir un large soutien pour cela. J’espère qu’ils se tourneront bientôt vers les jeux sur PC.

David Tucker

mars 22 7 :21PM

La norme USB HID ne peut pas envoyer une mise à jour plus rapide que 1 KHz, c’est une limite technique de la norme. S’ils sont réellement en train d’interroger à 8 KHz, alors ils doivent utiliser une autre api. Ou ils pourraient être en train de faire des sondages internes à 8 KHz et de vous envoyer simplement le signal lissé à 1 KHz (ou moins). Plus important encore, Windows utilise une file d’attente d’événements pour gérer les mises à jour de la souris et les jeux ne lisent cette mise à jour que si souvent. Nous exécutons cette mise à jour à 60 Hz, donc une souris de 8 KHz ne fait pas grand-chose pour vous (c’est un peu mieux, mais difficilement mesurable). Je doute que même les jeux de tir fonctionnent à plus de 200 Hz.

De plus, la norme USB HID est limitée à quelque chose comme 64 octets, ce qui est un gros problème pour les fabricants de roues qui souhaitent avoir plusieurs commutateurs de position rotatifs. Ils ne peuvent contenir qu’un nombre limité de boutons et d’axes dans un seul message HID, et il est difficile de tout équilibrer (surtout avec 3 pédales, un frein à main, un volant et des palettes analogiques). Augmenter le taux de mise à jour et la taille des paquets serait d’une grande aide. Quelque chose comme 512 octets et 10 KHz serait parfait.

Même dans ce cas, les appels en plusieurs étapes ajouteraient des avantages. Mais oui, l’idéal serait de courir plus vite.

Je suis loin d’être un expert en usb, mais je ne pense pas que l’on puisse utiliser les microframes en mode HID. Je suis sûr que vous pouvez écrire vos propres pilotes pour que cela fonctionne, mais il n’apparaîtra pas comme une souris générique sans pilotes. Mais pour être honnête, je n’ai passé aucun temps à m’intéresser aux souris à grande vitesse. Ce n’est pas quelque chose dont nous pouvons profiter, et je soupçonne un peu que tout cela ne soit que de la poudre aux yeux. Je suis sûr qu’une souris qui fonctionne à 500 Hz est une bonne idée, mais il est peu probable qu’aller encore plus vite aide.

Nous pourrions utiliser l’api telle qu’elle est écrite maintenant pour le faire.

Cela fonctionne très bien lorsque vous dormez pendant une longue période, mais pas si bien lorsque vous ne dormez que pendant une ms ou deux.

Oui, mais vous utilisez essentiellement un cœur à 100% tout le temps. Si Windows avait un support de veille fractionnaire de millisecondes (allez Microsoft, c’est 2024 !), nous pourrions simplement l’utiliser, mais comme Linux l’a depuis 20+ ans et que Microsoft n’a pas encore compris, il est peu probable que cela se produise de sitôt. En fait, Microsoft va dans l’autre sens et ralentit son horloge maîtresse afin que les threads dorment encore plus longtemps que demandé, afin d’aider sur le front de l’économie d’énergie.

Utiliser un cœur à 100% n’est pas terrible mais pas génial. Sur un ordinateur portable, cela ajoute beaucoup de chaleur inutile dans le processeur et entraînera un étranglement du processeur, dans certains cas. Et sur un ordinateur de bureau qui rend plus difficile pour l’ordonnanceur de faire son travail, et utilise plus d’énergie (pas que nous nous en souciions autant lorsque nous pilotions une carte 4090 à plein régime). Vous pouvez céder pour essayer de réduire cet effet (sleep(0) par exemple) mais cela apporte ses propres problèmes. Céder peut ne pas vous remettre en marche en une seconde, ce qui peut ajouter de la gigue ou simplement faire exploser tout le timing. Et en théorie, cela ne réduit pas du tout la consommation d’énergie (mais cela pourrait être le cas dans certains cas).

Le point principal est que vous devez courir à une vitesse où votre gigue est inférieure à environ 1/4 de l’intervalle, ou il n’y a vraiment aucun intérêt à courir à cette vitesse. Si nous pouvions fonctionner à 1000 Hz avec 1 à 2 ms de gigue, ce n’est vraiment pas mieux que de fonctionner à 300 Hz. C’est-à-dire que tout signal au-delà de 150 Hz serait détruit par la gigue, alors quel est l’intérêt d’aller plus vite. Il y a une réduction de la latence (mais même cela est détruit par la gigue), mais la latence est l’une de ces choses qui est soit un gros problème, soit pas un gros problème. Nous avons juste besoin de réduire la latence à un point où les roues peuvent fonctionner de manière stable, et pour l’instant, c’est autour de 200 Hz (mais plus c’est rapide, mieux c’est).

Elle fait l’objet d’une réflexion active. J’espère que nous pourrons y travailler, mais c’est un gros projet qui est en grande partie au-delà de ma capacité à le mettre en œuvre.

—

Il existe probablement des moyens d’implémenter des attentes occupées qui permettent de gagner du temps, mais je ne suis pas sûr qu’ils fonctionneront sur différentes versions de Windows. Par exemple, il y a des instructions de montage qui sont essentiellement sans opérations. Il est possible que ceux-ci puissent être utilisés pour ne pas faire de travail. Nous pourrions faire des appels bloquants dans un registre matériel qui prend un certain temps connu pour répondre. Cela met effectivement le fil en pause, sans céder de temps (en théorie). Et le moteur DSP utilisé par XAudio a un moyen de faire des micro-sommeils. Il est possible que nous puissions déterminer les cris qu’ils font et les utiliser dans notre physique. Mais ce n’est pas documenté (à part une seule présentation d’il y a 8 ans qui le mentionnait), et il est peu probable qu’il soit stable d’une version à l’autre de Windows. Et Microsoft a apporté de grands changements dans le fonctionnement de l’horloge globale de Windows, dans chaque version de Windows depuis Windows 95. Donc, encore une fois, il y a de fortes chances que quoi que nous fassions, nous nous brisons encore et encore.

Tout cela est très bien, si vous faites un utilitaire expérimental. Mais c’est une mauvaise façon d’essayer de développer une application commerciale complexe que vous voulez continuer à faire fonctionner pendant 20 ans. Vous vous doutez bien que réorganiser notre architecture sur la base d’une astuce qui nous permet de tourner à 2 000 Hz, par exemple, mais qui risque de se casser dans 2 ans, n’est pas une décision très sage. Quoi que nous fassions, il doit avoir une solution de repli qui fonctionne dans n’importe quelle version de Windows, y compris les versions futures, sans avoir d’impact négatif sérieux sur le fonctionnement de la simulation. Nous ne pouvons pas passer 9 mois à restructurer la simulation, pour que tout s’effondre.

Nous devons communiquer avec TrueDrive pour mettre le volant en mode 360 Hz, et cela dépend de la disponibilité de TrueDrive et de la communication avec le volant lorsque iRacing démarre.

y'a beaucoup de propos sans contexte qui seront difficiles à comprendre, mais cela donnera quand meme beaucoup d'infos

Iracing a une limitation historique de son moteur FFB. Ils tentent de contourner le problème avec cette pirouette mais je pense que cela reste moins satisfaisant que d’autres FFB synchronisées sur les moteurs physiques d’autres simu.

C'est vrai que quand on lit cette histoire de rematricage, cela semble une solution peu élégante et pas très engageant.

Mais de l'avis de plusieurs personnes ayant fait le comparatif, cela semble porter tout de même un gain. Maintenant si on fait un blind test, je ne suis pas sur que les gens sachent différencier. Comme avec les différentes base du marché en fait. Et comme avec la hi res en audio.