Journal X.org Vacation of Code

Posté par  .
Étiquettes : aucune
0
20
avr.
2007
Bonjour,

Comme vous le savez, les dépôts de candidature pour le Google Summer of Code [1] ont pris fin récemment; la fondation X.org n'a reçu que trois places, qui vont donner lieu, on l'espère, à trois améliorations majeures pour X.org [2].

Du coup, les dirigeants de X.org ont décidés d'employer eux-même trois étudiants supplémentaires pour trois projets de plus [3].

On y trouve donc:

- Un support Xv pour le driver libre pour cartes NVidia, Nouveau [4].
- XCBScope/Dissector-Library (ne me demandez pas ce que cela veut dire).
- Mon propre projet, une implémentation libre de la compression S3TC pour Mesa.

Actuellement, la compression S3TC, utilisée intensivement dans les jeux vidéos, est soumis à un brevet logiciel qui empêche de distribuer des implémentations Mesa contenant un support de la compression de textures à la volée.

Mon objectif est d'utiliser des algorithmes différents pour générer le même format (qui lui est bien-sûr ouvert), ce qui ouvrira la voie de la compression à la volée à tous les drivers libres.

J'en profite pour remercier encore une fois Bart Massey pour m'avoir sélectionné, et Brian Paul pour avoir accepté d'être mon mentor.

Je vous ferai part de mon avancement dès le début du travail, fin Mai.

[1] http://code.google.com/soc/
[2] http://code.google.com/soc/xorg/about.html
[3] http://summer.cs.pdx.edu/node/58
[4] http://nouveau.freedesktop.org/wiki/Accueil-fr

  • # Bon courage

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

    Bon courage à toi et à ton projet...

    <mode un peu naif>
    En espérant que cela permettra quelques éditeurs de jeux d'utiliser un format ouvert et voir plus de jeux sur notre plateforme...
    </mode un peu naif>

  • # Bon, bah puisque c'est pas moi...

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

    ... qui fais un journal dessus, je poste un commentaire :)

    Je suis la personne qui s'occupera du support Xv pour Nouveau. En réalité il y a déjà un support Xv mais il est lent et ne tourne pas très bien (je cite ce qui m'a été dit, je n'ai pas encore commencé à travailler dessus), mon boulot consistera à nettoyer le code, utiliser DMA, et supporter de nouveaux formats.

  • # Définition de "S3TC"

    Posté par  . Évalué à 6.

    S3 Texture Compression (S3TC) (sometimes also called DXTn or DXTC) is a group of related image compression algorithms originally developed by Iourcha et al of S3 Graphics, Ltd. (US Patent #5,956,431) for use in their Savage 3D computer graphics accelerator.

    Wikipedia: http://en.wikipedia.org/wiki/Texture_compression
    Informations supplémentaires : http://www.digit-life.com/articles/reviews3tcfxt1/

    voila :-)

    ps: bonne chance pour ton projet

    • [^] # Re: Définition de "S3TC"

      Posté par  . Évalué à 3.

      Pour les décideurs pressés, selon Wikipédia :

      Unlike some image compression algorithms (e.g. JPEG), S3TC's fixed-rate data compression coupled with the single memory access (cf. some VQ-based schemes) made it ideally suited for use in compressing textures in hardware accelerated 3D computer graphics.

      Donc si j'ai bien compris, l'avantage sur du JPEG ou autre c'est que le ratio de compression est toujours identique donc on peut savoir d'avance la taille de la texture compressée. J'ai bon ?

      • [^] # Re: Définition de "S3TC"

        Posté par  . Évalué à 4.

        L'énorme avantage sur le jpg est surtout que c'est bien plus simple à cabler dans les cg (faut bien décompresser).

        Le jpg, c'est de la compression par ondelettes, c'est très efficace, mais aux prix d'artefacts disgracieux, et surtout de calculs complexes nécessitant plusieurs accès mémoire à différents endroits de l'image.

        Avec le S3TC, tu prend ton bloc de pixels, et tu as tout ce qu'il te faut pour décompresser.

  • # Piiiiiiiirate !

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

    Il ne faut pas payer des royalties pour implémenter l'algo S3 ?

    • [^] # Re: Piiiiiiiirate !

      Posté par  . Évalué à 7.


      Mon objectif est d'utiliser des algorithmes différents pour générer le même format (qui lui est bien-sûr ouvert)

  • # Et pour ati?

    Posté par  . Évalué à 2.

    Et rien pour les driver ati?
    Y'a encore des gens qui bossent dessus?
    Parce que ça fait un bon moment qu'on attend le support des Radeon X1K et la stabilisation du driver pour les r300/r400, j'ai beau chercher mais je ne trouve pas d'info à jour là dessus, Quelqu'un connait l'adresse du blog d'un des développeurs?

    • [^] # Re: Et pour ati?

      Posté par  . Évalué à 2.

      Le problème c'est que visiblement peut de personnes semblent attiré pour bosser sur les drivers radeon (le driver r300 étant de plus probablement un mauvais exemple de driver tant il reste plein de hack pas beaux tout partout) et comme les développeurs existant on peut de temps tout avance lentement aux grées de leur temps libre.

      Enfin pour les radeons X1K je crois pouvoir dire que d'ici peu un driver libre fera son apparition, attention probablement aucune acceleration simplement la gestion des changements de modes, pour l'acceleration il faudra attendre que les différences avec les r300 & r400 soit isoler afin de pouvoir se servir du moteur 3d.

      Je crois pas que tu trouvera des informations sur des sites ou des blogs, les dev restent en général discret car ils savent jamais quand il vont trouver une heure pour finir le point de détail qui manque avant de publier le boussin. Mais en restant sur irc tu peux récupérer des brides conversations sur le sujet :)

    • [^] # Re: Et pour ati?

      Posté par  . Évalué à 1.

      Sur la page http://dri.freedesktop.org/wiki/R300 tu peux trouver les liens vers les TiRDC (The irregular Radeon-Development companion) sur le modèle de ceux faits pour Nouveau.

      • [^] # Re: Et pour ati?

        Posté par  . Évalué à 1.

        Merci ;)
        Je check de temps en temps le wiki mais j'avais pas encore vu ça, très bonne initiative!

  • # ...

    Posté par  . Évalué à 7.

    @ahuillet: eh beh, deux froggies, et tous les deux sur LinuxFR, c'est marrant ça :) (le troisième est allemand, à vue de nez).

    En général, merci pour les encouragements, vais essayer de faire un truc potable (et d'y ajouter deux trois tools genre un format de fichier compressé style DDS avec plugin gimp permettant de gérer le processus de quantization).

    Pour le copyright, comme je l'ai dit, l'algo d'origine de S3 est sous brevet, pas le format. Donc je prend un autre algo (de tte manière on a pas l'algo d'origine :)), et j'encode dans le même format, et c'est réglé. Au pire, je suis en France, je ne risque rien (pour l'instant, du moins...).

    Pour le driverATI, je ne participe pas au projet, mais le support est loin d'être complet. Pour ma Radeon 9800pro, 2d ok, aucune accélération 3d... Quant aux Radeon X1K, le problème majeur est que ça reste pour l'instant coûteux, donc peu de gens en ont, donc dur de développer dessus (les devs doivent en acheter, mais qui fera les remontées de bugs ?).

    Du coup, je reste sous NVidia, et driver proprio pour mon laptop.

    • [^] # Re: ...

      Posté par  . Évalué à 1.

      Le driver r300 supporte ta radeon9800 pro, tu as probablement un distribution un peu vieillotte ou alors tu as un problème de dépendance.

      • [^] # Re: ...

        Posté par  . Évalué à 1.

        Mon dernier test date d'il y a quelques mois, avec une Gentoo ~x86, ça s'est peut-être amélioré récemment :)

        Dans tous les cas, pour que je reprenne de l'ATI, il me faudrait un driver qui:

        - Supporterait la totalité des fonctionnalités hardware (OpenGL 2.0 complet, pour la compression de textures on-the-fly, je vais attendre 4 mois :p).
        - Supporterait sans problème la vidéo, y compris avec la sortie.
        - Plus délicat, supporterait parfaitement le dual screen, type NView sous NVidia (bureau étendu).
        - Le tout avec des performances décentes (au moins 80% du driver proprio).

        C'est ce qui fait que j'ai du driver proprio partout :(
        Menfin je compte sur les devs pour que ça soit un jour utilisable !

        • [^] # Re: ...

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

          Supporterait la totalité des fonctionnalités hardware (OpenGL 2.0 complet ...)

          Erreur, les fonctions hardware de ces cartes ne sont pas à la norme OpenGL (ni 1 ni 2), ni DirectX (quoique la par contre c'est pas sûr sûr, elles doivent être très orienté DX).
          C'est le boulot du driver (enfin plus souvent de la libgl fournie avec) de transformer les appels OpenGL en fonctions comprehensibles par la carte.

  • # La grande question que tout le monde se pose

    Posté par  . Évalué à 3.

    non, la réponse n'est pas 42.

    Voilà en fait la question, le projet sûr lequel tu travail, il permettra de faire tourner des cubes sur son bureau en VESA ?

    • [^] # Re: La grande question que tout le monde se pose

      Posté par  . Évalué à 3.

      Non, compresser puis décompresser le framebuffer ou des fenêtres en software ne ferait que rajouter des calculs aux processeurs et donc ralentir l'ensemble. Si aujourd'hui tu ne peux avoir d'effet comme ceux de beryl ou compiz avec vesa, il y a peut de change que tu puisse en avoir demain. La seul solution est d'écrire des routines de rasterisation optimise pour ton processeurs et encore je pense que tu ne pourrais pas dépasser le 1024x768 sans voir les performances s'écrouler. Enfin je ne pense pas que mesa s'intéresse énormément a écrire les routines de rasterisation les plus optimisée possible, il s'intéresse surtout a la qualité du rendu pour ce qui concerne le rendu en software.

      D'autre projet comme enlightenment pourrait éventuellement apporter ce genre d'effet en software, ils semblent s'intéresser bcp plus au rendu software qu'a tirer partit de l'accélération matériel.

  • # FXT1

    Posté par  . Évalué à -4.

    Pourquoi s'attarder avec des trucs proprios alors que on a à dispo (libre) une excellente techno de feu 3DFX?

    • [^] # Re: FXT1

      Posté par  . Évalué à 2.

      Parce que la techno 3dfx, on s'en tamponne, vu que celle qui est cablée dans les cartes graphiques, c'est le S3TC ?

  • # Déçu ;)

    Posté par  . Évalué à 4.

    J'aurai vraiment aimer que ça soit l'idée d'intégrer le protocole NX en natif dans Xorg qui me plaisait le plus. :)

Suivre le flux des commentaires

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