SL 1.14 et FirstLook

Quand je ne suis pas dans SL, ou en train de dormir, j'aide Linden Lab a améliorer Second Life. Moi, ainsi que tout un tas de développeur, avons nos pattes dans le client de Second Life qui, je vous le rappelle, est opensource depuis le mois de janvier.

Je m'occupe principalement de chasser des bugs et trouver des optimisations de performances via des outils de profiling (merci Apple). Le travail fait par la communauté opensource de SL a été principalement testée sur le client "First Look".
La mise a jour d'hier (1.14) est tout simplement la migration du client "officiel" vers le client "first look" testé depuis déjà plusieurs mois.

Nous n'avons pas vu beaucoup de "features" ces temps-ci. Linden Lab se concentre sur la stabilité et la "scalabilité" du client et du serveur, et la communauté opensource sur les performances du client. Qu'avons nous de neuf, et qu'est ce qui est prévu dans le futur ?



Quoi de neuf :
- Le client est multi-thread : Avoir un processeur multi-core prend maintenant tout son sens dans second life et voit de grosse amelioration de performance sur le décodage des textures JPEG2000. Beaucoup d'autres choses sont aussi multi-treadée, mais cela utilise tellement peu de ressource cpu que le gain est vraiment minime. Cela dit c'est toujours bon a prendre pour le futur.
- Le client utilise le VBO : Cela permet d'accelerer le traitement de la scène par la carte graphique, gain de FPS. Le gain n'est pas énorme, car il y a toujours une grande partie du traitement faite sur le CPU, et sur le thread principal qui est deja surchargé.
- Amélioration du système de cache : Le cache local a été amélioré, mais il y a encore beaucoup a faire et c'est un sujet chaud en ce moment. Une des prochaines grosse amélioration dans les futures versions sera dans la rerefonte du système de cache.
- Utilisation des services http : de plus en plus de requêtes client->serveur sont maintenant faite via le protocol http, plutôt que via le systeme de message propriétaire de Linden Lab (qui pose problème, et qui implique entre autre de redemarer toute la grille a chaque mise a jour du protocol). A terme, on vera de moins en moins de "downtime" le mercredi...(ou du moins de downtime pour cause de changement de protocole).
- Des bugfixes en pagaille et des optimisations par ci par là.

Le futur :
- Rerefonte du système de cache local : ne plus utiliser de VFS, mais directement le FS de l'OS. Utilisation de plusieurs niveau de caches (mémoire, textures pre-décompressée sur disque, texture décompressée sur disque, réseau). Un des gros soucis de performance est le décodage des textures compressées. Le 2ème soucis vient directement de Windows et sa particularitée d'utiliser un système de fichier qui nécessite d'être defragmenté manuellement (saviez vous que la plupart des autres OS utilisent un système des systèmes de fichiers qui ne nécessite pas de defragmentation ?). Microsoft a encore le palmarès de la grosse merde avec son NTFS et nous cause pas mal de maux de tetes pour avoir un système de cache local performant (S'il n'y avait pas ce problème de fragmentation spécifique a microsoft, cela serait beaucoup plus simple).
- Plus de multithread : Il y a encore beaucoup trop de choses qui sont faites dans le thread principal, ce qui surcharge un core alors que l'autre glandouille (sur les système multi-core bien sur). L'idéal serait d'arriver a séparer le traitement graphique (en particulier les octree) sur un cpu a part, mais avoir un rendu multi-thread est de loin le truc le plus galère a faire. (C'est aussi pour cette raison que beaucoup de jeux ne profitent pas des systèmes multi-cores). Il y a aussi beaucoup de choses qui sont faites dans le boucle idle(), ce qui n'est pas pratique ni performant.
- Réduction du packet-loss : Le système de message va utiliser un peu moins d'UDP et un peu plus de TCP. Il y a aussi une fourberie dans le design du client qui fait que plus on a du packet-loss plus cela genere de packet-loss... ce qui genere encore plus de packet-loss qui genere plus de packet loss... etc ... Du fait aussi qu'une partie du traitement réseau se trouve dans la boucle idle(), plus le CPU est surchargé plus il y a de packet loss et plus cela surcharge le CPU, ce qui rajoute bien sur encore plus de packet-loss qui genere du packet-loss sur surcharge le CPU qui ... hein... bref, z'avez compris (ou pas). Et non seulement cela surcharge le CPU du client, mais cela surcharge aussi le CPU du serveur... ce qui, vous l'avez compris (ou pas?)... genere plus de packet-loss qui ... *baille*

Le futur lointain :
- Linden Lab travaille a implémenter Havok 4... un jour ;)
- Le backend (serveur) sera aussi opensource
- Le systeme permettra d'avoir directement ses propres serveurs, voir même sa propre grille. Mais c'est pas pour demain, cela pose encore d'énorme problème de sécurité et de fiabilité.


PS : s'il vous prend l'idée de vous inspirer de ce post pour écrire un article similaire, vous pouvez, mais je vous prie de citer auteur (kerunix Flan) et site (http://kerunix.blogsplot.com/). Je travaille dur pour rester informé sur le futur de secondlife, et je suis prêt a partager mes précieuses informations (comme beaucoup d'autres le font). En échange je demande un "minimum" de reconnaissance et de remerciement pour vous avoir maché le travail.

Du coup j'en profite pour remercier 3pointD, RCE, et toute la bande qui traine sur les differents canaux IRC dediés a secondlife ;)