S2TC fait la pige à S3 pour la gestion libre des textures !

Posté par  (site Web personnel) . Édité par Davy Defaud, baud123 et Nÿco. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes : aucune
42
13
oct.
2012
Serveurs d’affichage

Les jeux en 3D texturée OpenGL, OpenGL ES et maintenant WebGL utilisent la compression de textures pour permettre des performances décentes.

Malheureusement, le format qui s’est imposé de fait sur le desktop (il est inclus dans Direct3D pour Windows) est soumis à redevance dans les pays qui, malheureusement, reconnaissent les brevets logiciels. Il s’agit du format S3TC de la société S3 Graphics.

Le point avait été abordé dans cette dépêche du mois d’août, qui portait d’ailleurs de très bonnes nouvelles : le lancement de nouveaux formats de compression de textures libres de redevance, équivalents (ETC) ou supérieurs (ASTC) au S3TC. Ça, c’est pour l’avenir. Mais, pour le présent ?

Pour le présent, Rudolf Polzer et Maik Merten ont développé il y a plus d’un an S2TC, un format de compression de textures qui est compatible avec le S3TC, sans recourir aux techniques brevetées pour celui‐ci.

La solution serait un peu moins qualitative, sans que la différence ne soit très visible à l’œil nu (voir la comparaison). Elle serait en revanche plus performante, car plus simple à mettre en œuvre.

Actuellement, vous avez le choix pour votre distribution : installer vous‐même la bibliothèque qui implémente S3TC (libtxc-dxtn) ou celle qui implémente S2TC (libtxc-dxtn-s2tc). Aucune n’est installée par défaut, et si vous faites tourner un jeu nécessitant le format de compression S3TC, celui‐ci tournera sans les textures.

Pour éviter cet écueil, les distributions réfléchissent à intégrer la prise en charge du S2TC par défaut.

Ubuntu vient de franchir le pas, aiguillonné par Valve, et d’autres pourraient suivre (voir debbugs #668645, par exemple).

Aller plus loin

  • # Plus performant ?

    Posté par  . Évalué à 7. Dernière modification le 13/10/12 à 20:50.

    Plus simple à mettre en œuvre n'implique pas que ce soit plus performant.

    L'annonce indique que c'est plus performant car l'algorithme est plus simple. Par contre l'algorithme de compression étant plus simple, il a pu être mieux optimisé, ce qui peut parfois donner une meilleur qualité.

    J'ai regardé les comparaisons. Je pense effectivement que bien que S3TC soit meilleur, le joueur ne se rendra pas compte de la différence. Et l'on voit effectivement une très légère meilleur qualité dans certaines images ne comportant pas de dégradés.

    • [^] # Re: Plus performant ?

      Posté par  (site Web personnel) . Évalué à 5.

      Je n'ai pas développé ce point, désolé.

      Il faut retenir que, d'après les devs, le compresseur S2TC est plus rapide lors de la compression dynamique, au chargement du jeu :

      S2TC is fast
      S2TC is especially well suited for runtime (on-load) compression of textures, as it is - in low quality settings - way faster than any other texture compressors out there.

      Et qu'à la décompression, ça ne change rien puisque c'est accéléré par la puce graphique comme S3TC dont c'est un sous-ensemble :

      Which graphics cards can decompress S2TC?
      All current graphics cards can decompress S2TC, as S2TC is a special case of the well-known S3TC texture compression format.

  • # Pas forcement concluant

    Posté par  . Évalué à 7.

    Je viens d'uploader des versions ArchLinux sur AUR (https://aur.archlinux.org/packages.php?O=0&K=libtxc_dxtn_s2tc)

    • Aucuns problèmes dans Torchlight (x86_64)
    • Segfaults avec Ennemy Territory QuakeWars et Quake 4 (32-bit sur x86_64)

    Voilà pour un premier test.

  • # FXT1

    Posté par  . Évalué à 1.

    Il aurait été intéressant d'intégré le format libre FXT1 de feu 3Dfx dans les tests ou alors tenter d'améliorer FXT1.

    Un comparatif assez intéressant FXT1 vs S3TC montre qu'il n'était pas totalement à la ramasse, certes moins bon mais avec le temps on aurait pu atteindre l'équivalent voir mieux, suffit de voir ce qui se fait dans la compression video libre.

    • [^] # Re: FXT1

      Posté par  (site Web personnel) . Évalué à 6. Dernière modification le 14/10/12 à 03:25.

      Ce n'est pas la communauté qui dicte les formats de l'industrie sur ce coup là. Il faut donc faire en fonction.

  • # Il existe déjà des formats libres; le problème c'est le support matériel.

    Posté par  (site Web personnel) . Évalué à 5. Dernière modification le 14/10/12 à 01:08.

    Je ne comprends pas: le problème n'est pas qu'il n'existe pas de format de textures compressées libre—il existe ETC2 pour les textures RGBA et ETC1 pour les textures RGB—le problème est que ces formats libres ne sont pas implémentés dans le matériel. ETC1 commence certes à être implémenté dans pas mal de GPUs, mais le manque de support pour les textures RGBA le rend peu utile (90% des textures utilisées dans les jeux ont un canal alpha qui peut être utilisé pour divers effets), donc c'est plutôt ETC2 qu'on veut, mais je ne connais aucun matériel en circulation qui l'implémente.

    On peut certes implémenter un format de textures compressées dans le peintre de fragments (ma traduction de fragment shader) mais ça ne sera probablement pas aussi performant qu'un support direct par le matériel, enfin je serais ravi d'être démenti.

  • # Les brevets sur S3TC seraient invalides

    Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 14/10/12 à 18:12.

    Une remarque complémentaire sur les brevets de S3TC que j'oublie de mettre depuis le début de cette dépêche : S3TC serait dans le giron de HTC si j'ai bien suivi, et Intel a émis publiquement de sérieux doute quant à la validité du brevet. Mais tant que le brevet n'est pas invalidé…

  • # Trop bas niveau?

    Posté par  (site Web personnel) . Évalué à 5.

    Est-ce qu'opengl n'est pas trop bas niveau sur ce coup là?

    En tant que développeur de jeux multiplate-formes, plutôt que de jouer au mega puzzle "quelle est la combo de 500 paramètres pour gérer mes textures avec le hardware sur lequel je tourne", j'aimerais bien pouvoir faire quelque-chose comme:

    glPrepareLoadPleinDeTexturesDansTaTronche();
glTexture(GL_TEXTURE_QUE_JE_VAIS_CHANGER_SOUVENT, "pouet.png");
glTexture(GL_TEXTURE_QUI_NE_BOUGERA_PAS, "toto.jpg");
...
glCompresseOuDecompresseMaisDemerdeToiPourQueToutRentreDansTaMemoire();

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.