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 octobre 2012 à 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 octobre 2012 à 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 octobre 2012 à 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.

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

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

      OK, j'ai lu l'annonce et je comprends maintenant:

      "is perfectly decodable by any S3TC decoder"

      OK donc si je comprends bien, S2TC serait un sous-ensemble de S3TC qui évite les parties brevetées.

      Plus bas on lit:

      • when a precompressed texture is uploaded, nothing changes - it is uploaded as "full" S3TC
      • when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder

      OK donc soyons clairs, dans le monde réel, les jeux vidéo fournissent leur propres textures compressées, ils ne se reposent pas sur le GL pour compresser leurs textures pour eux (en tout cas ils n'ont pas à le faire).

      La spec OpenGL (et ES) va plus loin en proposant de compresser à la volée des textures non compressées. C'est cette partie qui est sujette à brevets logiciels du point de vue de Mesa (car cette partie doit être implémentée par Mesa) et c'est ça qui rend impossible pour Mesa d'exposer l'extension S3TC. Mais du point de vue d'un développeur de jeux vidéo, ça n'est pas utile.

      Ce que j'aimerais, c'est une variante de l'extension S3TC moins le support de la compression à la volée. Comme ça, Mesa pourrait l'exposer sans problème sur les pilotes de matériel gérant ce format en dur (Mesa ne pourrait pas l'exposer sur les autres pilotes et en particulier pas sur LLVMpipe et autres pilotes logiciels), et ça suffirait pour les jeux vidéo.

      Note que c'est ce que l'extension de WebGL expose. Pas de support pour la compression à la volée, du coup, pas de problèmes de brevets tant que le matériel prend nativement le format en charge.

      • [^] # Re: 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 octobre 2012 à 03:24.

        Les brevets portent sur la décompression, d'où ce sparadrap :

        Can S2TC's libtxc_dxtn decompress S3TC?
        No, it can not decompress S3TC, as the S3TC decompression algorithm is not implemented. When a "reserved" bit combination (i.e. one not defined in S2TC) is encountered, the decompressor instead selects - at equal probabilities - one of the two possible color (or alpha) values. This yields reduced visual quality, but accessibility/readability is not impaired. See the libtxc_dxtn page for a screenshot.

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

          Posté par  (site web personnel) . Évalué à 3.

          Apparemment ils doivent aussi porter un peu sur la compression, puisque le message sur la liste de diffusion dit:

          • when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually "good enough" (see screenshots on my wiki)

          En gros ce que je dis c'est que la compression par le GL n'est déjà pas une fonctionnalité très utile en soi pour les jeux vidéo (et pour la plupart des applications), et donc l'idée de faire un compresseur castré qui évite les brevets au prix d'une qualité inférieure ne va sembler intéressante qu'à un marché limité, en tout cas probablement pas aux éditeurs de jeux vidéo (la dernière phrase de ta dépêche suggère que Valve est intéressé par S2TC, peux-tu donner une source?)

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

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 octobre 2012 à 11:10.

            La gestion du S3TC est nécessaire pour les jeux Valve, quelque soit le moyen (S3TC ou S2TC).

            Source Ubuntu :

            We’ve brought in a patent-free S3 texture compression library for mesa required by Valve and the Humble Indy Bundle, to be installed on user systems by default starting with quantal (and precise via PPAs). And we’re working on getting mesa 8.0.4 SRU’d into precise (not required by Valve, but brings numerous fixes other games and 3D apps need).

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

      Posté par  (site web personnel) . Évalué à 1.

      Au fait, note aussi que pour activer le support de S3TC par Mesa, il suffit de définir une variable d'environnement… ce que Firefox fait depuis la version 16 fraîchement débarquée.

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

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 octobre 2012 à 03:20.

      Les appareils mobiles implémentent ETC2 pour la plupart (OpenGL ES).
      Pour les appareils desktop, c'est un problème : ainsi Intel vise la certification OpenGL ES 3 (après la 2 qu'il a obtenue récemment) pour Sandy/Ivy Bridge (Gen 6 et 7) et il doit trouver un moyen de décompresser les textures au format ETC2 matériellement.

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

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 octobre 2012 à 03:30.

        Matériellement ou pas, si l'on en croit un des dévs Intel :

        None of our currently shipping hardware has native support for ETC2, which means we have to implement it in software. That means that textures are uploaded and stored to the GPU in an uncompressed format, which isn't terribly efficient, but there's not much else we can do. That will at least make applications using ETC2 compressed textures work.

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

        Posté par  (site web personnel) . Évalué à 3.

        Peux-tu me citer un seul appareil mobile disponible sur le marché qui offre effectivement le support de ETC2 dans les bibliothèques OpenGL ES 2 livrées dessus?

        Parce que j'avais regardé il y a quelques mois et j'en avais trouvé zéro. Si le support de ETC2 était largement répandu, on n'aurait pas choisi PVRTC et ATC comme formats mobiles à exposer par WebGL en plus de S3TC pour bien couvrir le marché.

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

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 octobre 2012 à 11:34.

          Arf j'ai peut-être extrapolé.

          J'avais déduit de cette phrase que les puces autres que PowerVR géraient ETC mais ce n'est pas ce qui est écrit en fait :

          At the same time it will be interesting to see how developers adopt ETC. Just because it’s a standard doesn’t mean it has to be used, and while we can’t imagine Android developers not using it once OpenGL ES 3.0 is the baseline for applications, Apple bears keeping an eye on. As a PowerVR-only shop they have used PVRTC since day one, and so long as they don’t change to another brand of GPUs they wouldn’t need to actually back ETC.

          Apparemment Mali-400 gère ETC 1 ou 2 ?

          Pire, au niveau logiciel, Wikipédia EN ne parle que de ETC1

          Android version 2.2 (Froyo) includes support for ETC1

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

        Posté par  (site web personnel) . Évalué à 3.

        ETC2 Texture Compression For Intel Is Happening

        Before getting too excited, however, this ETC2 support isn't a full implementation for texture compression on the hardware but rather is just immediately decoding the ETC2 data into RGBX data.

        Even if these patches aren't the best, at least in time for Mesa 9.1/10.0 in early 2013 we should have proper ETC2 support for at least the open-source Intel driver. They really want OpenGL ES 3.0 in Mesa by time of the next release and with GLES 3.0 comes the hard requirement on ETC2 support.

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

        Posté par  (site web personnel) . Évalué à 1.

        Intel Continues Work On ETC2 Texture Compression

        Anuj Phogat of Intel has published his second round of twenty-two patches for implementing ETC2 texture compression support within the Intel Mesa driver.
        With the second revision to these support patches, Anuj plans to push the texture compression code to Mesa's "GLES3" branch soon. The patches are currently on the mesa-dev list. "It enables ETC2 texture formats for all Intel hardware. ETC2 texture data is decoded into a suitable uncompressed mesa format at the time of glCompressedTexImage2D. These patches can be tested using piglit test case i have posted for etc2 textures. Patches for the test are under review on piglit mailing list."

  • # Les brevets sur S3TC seraient invalides

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 octobre 2012 à 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.