• [^] # Re: Pourquoi PA sux

    Posté par . En réponse à la dépêche Sortie de PulseAudio 2.0. Évalué à 8.

    Le commentaire que tu met en lien n'est pas si clair que ça je trouve :

    Maintenant plus pour le cote recherche, un certain nombre d'algorithm de rendu son limite par la bande passante memoire. On est donc entrain d'experimente la compression des ressources graphiques du theme et des fonts avec un rendu direct. Cela pourrait augmenter la charge CPU, en diminuant la bande passante memoire consome, donc prendre moins de temps au final. La plus grosse question sera de voir si cela a un impact sur la consommation de batterie. On travaille aussi sur un moteur de rendu hybride GPU/CPU, car OpenGL n'est pas adapte a toutes les situations et il vaudrait mieux pour certain morceaux de l'image finale, passe par le CPU. Enfin pour ameliorer les performances, on espere pouvoir experimente avec un rendu par tile plus adapte a une meilleure utilisation du cache L1.

    Il parle d'un axe de recherche et pas de faits et surtout il parle d'utiliser conjointement CPU et GPU pour diminuer les latences du au bus entre les deux et pour utiliser au mieux le CPU (mais sans abandonner le GPU).

    Je pensais que tu allais parler de ça : https://linuxfr.org/users/steckdenis/journaux/en-finir-avec-la-lourdeur-de-kde mais il y a une phrase importante dedans :

    Cela [utiliser le rendu uniquement fait par le CPU] peut sembler sous-optimisé, mais c'est en fait le meilleur des backends. En effet, il n'y a aucune phase de préparation, et ce backend est optimisé pour tirer parti des instructions multimédia disponibles sur les derniers processeurs.

    Et ça c'est bien sur les CPUs Intel et AMD (peut être aussi sur le Cell), mais sur les ARM ce n'est pas le cas. Au grand désarrois d'Intel android est surtout utilisé sur ARM plutôt que sur x86.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)