Cher journal,
Je prend la plume ce soir pour te raconter un peu ma vie parce je m'ennuie et que mademoiselle elle est au travail et que je reste réveiller pour aller la chercher. Peut être que je n'arriverai pas au bout de ma prose parce qu'il sera trop tard mais qu'importe.
Tu t'es peut être rendu compte que je suis assidument l'actualité de la pile graphique de mon OS préféré, celui depuis lequel je t'écris actuellement. En particulier, je suis inscrit à la liste de diffusion mesa/dev. Cela me fait beacoup de chose à lire et je n'en comprend pas le quart. Les "loop unfolding" et autre optimisations du compilateur en "mesa intermediate representation" c'est un peu technique pour moi.
Je suis triste parce que je n'arrive pas à trouver un morceau de code dans lequel me plonger pour comprendre les choses. Je n'ai pas de vu d'ensemble et c'est quand un peu du trop haut niveau pour moi. Alors je vais essayer de les aider en m'y prenant autrement.
Ce soir, il y a 5 minutes en fait, nous avons reçut de la part de Luca Barbieri, un developpeur a poster un message sur la liste de diffusion annonçant la disponibilité immédiate de la branche d3d1x qui contient un state-tracker pour gallium qui implémente les API D3D10 et D3D11 (glossaire à la fin du journal).
[Je vais chercher mademoiselle, je reviens, de toute façon personne s'intéresse à ces trucs là ici on va pas me piquer mon sujet et j'ai envi de finir quand même.]
...
[30 minutes plus tard]
Luca, donc, a implémenté une partie de l'api D3D version 11 au dessus de Gallium. Seule la partie que peut supporter gallium est actuellement en place et à priori seul swrast (le software rasterizer) est capable d'exécuter les démos qui vont bien.
C'est une étape assez importante et intéressante, en tout cas je le pense. Pas de vérités générales ici c'est mon journal et j'ai tord souvent, déduisez-en ce que vous voulez mais faites attention aux imprécisions qui le jalonneront sans aucun doute.
Tout d'abord les raisons qu'il donne dans le commit qui inaugure la branche : c'est une sorte de démonstration, une preuve que gallium est quand même suffisamment bien foutu pour supporter de multiple API, même celles qui n'ont vraiment pas été prévu pour lui. De plus on pourrais envisager, en écrivant un driver ad-hoc, de faire exécuter les commandes mesa par flgrx et le pilote Nvidia , et donc de profiter de leur niveau de maturité (en tout cas pour OpenGL). Enfin il explique en gros que l'API D3D10/11 est de bien meilleur niveau que celle d'OpenGL.
La dernière raison de cette implémentation va sans doute en faire bondir plus d'un. En ce qui me concerne, je suis assez d'accord. Lors de mes errances pour trouver un truc à contribuer (ce que je n'ai pas encore fait) j'ai fini, assez fatalement, par essayer de lire un petit bout de spécification d'OpenGL( 3 quelque chose). En un mot comme en 100 j'ai cru devenir malade. Par curiosité à l'époque, j'ai parcourt la doc D3D (10.1 à ce moment là). C'était propre et clair, j'ai eu un peu l'impression que j'ai eu quand j'ai découvert Python (les pythoniens me comprendront).
C'est assez triste de devoir l'admettre mais D3D est dans ses versions les plus récentes vraiment mieux et plus facile à utiliser qu'OpenGL. Il y a bien eu une tentative il y a quelques années pour faire la même chose à OpenGL que ce que Microsoft a fait à D3D, tout réécrire depuis 0 et casser la compatibilité ascendante, mais le Khronos groupe a abandonné ça.
Mais je m'égare.
La bonne nouvelle, c'est que cette chose utilisée conjointement avec un Wine un peu adapté devrait permettre de faire tourner les applications exploitant cette API avec Wine, sans avoir à utiliser de couche de compatibilité qui fait appel à mesa, mais plutôt en permettant à l'application winifiée de parler directement au state tracker. Si la partie driver de Gallium suit les performances devraient être pour ainsi dire égales à celle atteignables sur Windows (oui, les jeux).
Alors certes, on peut argumenter que cela reviendrait à encourager l'utilisation de ce machin sur mon OS favoris même pour des application natice. Mais le travail des gens qui bossent sur Mesa3D, Gallium3D et tous ces trucs là c'est pour faire un truc qui marche et qui soit utile à des vrais gens. Et les vrais gens de chez Wine, et ben on dirai que ça va leur rendre service (Wine n'a pas de couche de compatibilité avec D3D11 et celle pour D3D10 est embryonnaire parait-il). Et moi qui ait à cœur l'interopérabilité et l'utilisabilité, je trouve que c'est une bonne chose.
On parle d'utiliser une API dont le modèle de développement est parmi les plus fermés qui soient, et actuellement l'utiliser à son vrai potentiel implique de recourir à des driver propriétaire. Mais compte tenu de la progression, fulgurante ces derniers temps, des pilotes libres, je ne suis pas loin de parier sur une implémentation presque libre (module l'API D3D1x donc) au moins dans un proche avenir pour les carte Intel et Radeon (< r300). Les autres arrivent bien que je ne sache pas trop trop où ils en sont chez nouveau. J'en reparlerai peut être au moment de la sorti de mesa 7.9 d'ici quelques jours si je trouve le temps.
tl,dr : merde à vous ;)
Voilà, j'ai fini. Je vais pouvoir retourner chercher un truc à gratter sur Gallium et surtout trouver du temps pour tester tout ça. Ce coup de projecteur miniature est ma modeste contribution à l'univers graphique autour de Linux et la signification de la reconnaissance pour le travail des développeurs (en plus lire leurs messages sur la liste de diffusion m'occupe dans le bus et le métro, je vais pas me plaindre).
(C'est vraiment long et indigeste, mes excuses !)
Glossaire :
- Mesa3D : implémentation libre d'OpenGL initié il y a déjà un bye.
- Gallium3D : dépoussiérage et remise au goût du jour avec une architecture moderne de la pile 3D.
- State tracker : morceau de Gallium3D qui implémente une API spécifique et permet de générer des commandes en un langage intermédiaire indépendant du matériel sous-jacent, ex: OpenGL, OpenGL ES, OpenVG, ...
- Driver (au sens de Gallium3D) : code qui transforme les appels des state trackers en commandes exécutable par le hardware, ex: r300g, softpipe...
- software rasterizer (swrast) : code qui permet d'exécuter logiciellement les commandes provenant des appels aux state trackers, quand le matériel ne les supportes pas ou ne les implémentes pas.
- fglrx : driver propriétaire ATI.
- D3D10/11 : direct 3D, API dédié à la 3D issue de DirectX. La version 10 est fondamentalement différente de la 9 et casse la compatibilité ascendante avec cette dernière car elle est le fruit d'une réécriture complète. La version 11 est juste une évolution.
- Wine : couche de compatibilité qui vise à permettre l'exécution de binaire Windows sous Linux (entre autre) en transformant les appels aux API spécifiques en leurs équivalents locaux.
Journal Mesa, Gallium et D3D10/11 sont dans un bateau
21
sept.
2010
# On a compris hein…
Posté par Sufflope (site web personnel) . Évalué à 10.
[Je vais chercher mademoiselle, je reviens, de toute façon personne s'intéresse à ces trucs là ici on va pas me piquer mon sujet et j'ai envi de finir quand même.]
...
[30 minutes plus tard]
Oui, parce que J'AI UNE COPINE[0]…
[0] http://xkcd.com/684/
[^] # Re: On a compris hein…
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
# D3D
Posté par Guillaume Knispel . Évalué à 10.
(MS est en situation de leader sur cette API notamment pour les jeux vidéos, ils n'accepteront jamais le risque d'une implémentation alternative performante, on est donc condamné à ce que ça demeure une implé de seconde zone ou à son étouffement par MS si jamais ça commencerait à être trop dangereux pour eux.)
[^] # Re: D3D
Posté par Olorim . Évalué à 3.
En tout cas, tcourbon, la prochaine fois que tu t'ennuie, n'hésite pas à nous repondre un journal comme celui-ci : très intéressant, très clair, même pour quelqu'un qui n'y connais rien comme moi. Super travail.
[^] # Re: D3D
Posté par zebra3 . Évalué à 4.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: D3D
Posté par Olorim . Évalué à 2.
Enfin, je peu me tromper ou j'ai pas compris. Tu peu en dire plus?
[^] # Re: D3D
Posté par monde_de_merde . Évalué à 3.
Alors que Java (et Mono) utilisent potentiellement des techniques mises en place dans les implémentations officielles qui elles sont couvertes par des brevet.
Bref, en gros je pense que si l'implémentation de Luca n'enfreint aucun brevet il n'y a rien à craindre, si ce n'est le risque de devoir louvoyer entre les solutions technique et donc de souffrir de performances affaiblies par les workaround.
[^] # Re: D3D
Posté par Olorim . Évalué à 2.
bien entendu, mon commentaire est à pondéré par ma connaissance limité du sujet...
[^] # Re: D3D
Posté par monde_de_merde . Évalué à 2.
[^] # Re: D3D
Posté par Guillaume Knispel . Évalué à 3.
La moindre structure de donnée à la con réservée par on ne sait quel miracle par MS t'expose à des dommages. En fait si, on sait par quel miracle, il suffit pour le déposant de la fondre dans un algorithme à la con complètement trivial que tu vas forcement utiliser, mais le brevet ne sera pas forcement invalide à cause des bureaux et autres nuisibles d'avocats des brevets qui vont arguer comme des gros bâtards qu'ils sont que la façon d'appliquer cet algorithme sur cette structure de donnée particulière est nouvelle, et blablabla et hop t'es niqué par les mots magiques ! -- à savoir aussi que la notion de trivialité dans un brevet n'a quasiment aucune existence pratique, il faut atteindre le niveau de 1+1=2 pour qu'il soit refusé à cause de son évidence, et encore même dans ce cas il est facile de noyer le poisson en décrivant des systèmes qui n'ont rien à voir avec la choucroute sur des pages et des pages...
(De mémoire j'ai déjà vu un brevet décrivant une instruction comptant des bits dans le registre d'un processeur, sans évidemment donner d'implé en transistors ni même en portes logiques sinon ça serait pas drôle, c'est le concept général de comptage de bit dans un certain contexte qui était réservé, bref pour faire passer la pilule le brevet s'étendait sur 30 pages décrivant en long en large et en travers l'architecture d'un ordinateur y compris avec un imprimante branchée dessus et autres variations crétines. Les claims reprenaient évidemment les 30000 variations avec des revendications du style "un ordinateur implémentant une instruction qui compte les bits, lorsqu'une imprimante est connecté à cet ordinateur" (et je simplifie à peine). Voilà pour ce qui est de la qualité de certains brevets touchant au domaine des ordinateurs. Ce genre de brevet n'est pas forcement valide -- et encore j'en suis pas totalement sûr...-- , mais il est en général attribué et va te faire dépenser un pognon fou si on t'attaque avec une telle merde.)
Et plus tu chercheras à te protéger préemptivement moins tu seras productif pour faire une implé correcte et plus tu courras le risque d'introduire des incompatibilités qui diminueront la valeur de ton implé.
[^] # Re: D3D
Posté par zebra3 . Évalué à 3.
Que MS n'a attaqué personne pour une implémentation de .Net (comme Mono), alors qu'Oracle l'a fait pour une implémentation de Java.
C'est purement factuel.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: D3D
Posté par Guillaume Knispel . Évalué à 2.
Et on peut trouver des contres exemples de situation inversée entre le comportement des deux boites dans d'autres domaines.
# L'évolution d'OpenGL est toujours d'actualité.
Posté par drakmaniso . Évalué à 10.
C'est faux. Ce que Khronos a abandonné, c'est de tout remettre à plat en une seule fois. Au lieu de cela, ils ont choisi une évolution en plusieurs étapes, plus lente. Cela à causé beaucoup de déceptions lors de la sortie d'OpenGL 3, mais au final les changements les plus importants ont eu lieu, et les autres sont dans le pipeline.
L'état actuel de l'API est loin d'être aussi catastrophique que ce que tu décris, par contre, il ne faut absolument se fier à la documentation officielle pour la juger. Il faut utiliser des tutos spécifiquement destinés à OpenGL 3 ou 4, et se servir de la doc comme référence uniquement.
Quand à l'émergence de D3D comme API valable pour Linux, je n'y crois pas une seule seconde. C'est une chose de proposer une ébauche, et une autre complètement différente de proposer un support complet et suffisamment optimisé.
Il y a beaucoup de problèmes avec la pile graphique, mais ce n'est pas en changeant d'API qu'on les résoudra.
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par Albert_ . Évalué à -1.
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par monde_de_merde . Évalué à 1.
Ce que je sais c'est que pour y arriver, il faudrait que cette évolution brise la compatibilité avec ses ancêtres ce que le Khronos se refuse à faire.
Ce que j'en pense et que j'écris là, avis absolument pas objectif, c'est que quitte à casser des trucs, autant tout casser pour mettre en application les 2 ou 3 bricoles qu'on a apprises ces dernières années en terme de conception d'API et surtout qu'on en fasse une adapté aux problématiques actuelles.
J'irai même jusqu'à rêver qu'on arrête le design par un comité comme c'est le cas actuellement. Mais je rêve...
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par drakmaniso . Évalué à 4.
Encore une fois, c'est faux. Depuis OpenGL 3, de nombreuses parties de l'ancienne API ont été marquées obsolètes. Il suffit d'utiliser le profil forward compatible context pour avoir une API propre, qui casse la compatibilité avec tout ce qui a été écrit pour OpenGL 2. Et jusqu'à présent, chaque nouvelle version a continué d'avancer dans la bonne direction, en phase avec la réalité du matériel moderne.
La seule différence avec un changement brutal (qui était prévu et connu sous le nom de code Long Peaks), c'est que l'on est pas obligé d'utiliser ce profil; en fait le programmeur peut choisir à quel niveau de compatibilité il se place. C'est une contrainte pour les développeurs de drivers, mais absolument pas pour ceux qui utilisent l'API.
Par contre cela laisse la tentation d'utiliser quand même les fonctions obsolètes, là où un changement brutal aurait poussé plus rapidement les développeurs à améliorer leur code.
Quand au problème du design by committee, les coups de gueule poussés à la sortie d'OpenGL 3 ont largement assainit la situation (il suffit de voir le rythme et la qualité des sorties de nouvelles versions depuis).
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par monde_de_merde . Évalué à 2.
En gros, je résume.
Quand tu dis que c'est faux que Khronos refuse de cassé la compatibilité et qu'OpenGL a marqué des morceaux de l'API obsolète tout ça, j'ai envie de dire que le Khronos group a surtout fait preuve d'énormément d'hypocrisie. Ils ont ajouté des trucs, mais ont laisser les anciens et n'ont pas introduit les changements attendus (en particulier pour le modèle objets).
Comment on peut espérer faire évoluer un écosystème à l'inertie énorme si on ne pousse pas un petit peu ?
Peut être que je me trompe, comme souvent, mais je ne crois pas qu'il y ait des logiciels annoncés ou publiés (jeux ou autres) qui exploitent OpenGL 3.3 (voir 4.0), qui sont intéressantes.
En ce qui me concerne, j'estime que Long peaks a été abandonné et avec lui la volonté de refondre pour de vrai OpenGL, et qu'on s'est contenté du minimum syndical.
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par drakmaniso . Évalué à 3.
Il n'en reste pas moins que la voie choisie par le Khronos Group est saine; et contrairement à ce que tu dis, ils ont introduit la plupart des changements attendus.
En fait il faut distinguer deux types de changements.
D'une part, ceux concernant les fonctionnalités fournies par l'API; OpenGL 2 était rempli d’archaïsmes, de mécanismes bridant toute possibilité d'optimisation dans les drivers. De plus, s'il était possible de coder en suivant une architecture à peu près moderne, il fallait le faire par le biais de multiples extensions disparates. Tout cela a été remis à plat, et le coeur d'OpenGL est maintenant cohérent et en adéquation avec le matériel.
D'autre part, tout le monde attendait un changement profond dans le mode d'accès à ces fonctionnalités (la forme), et, effectivement, il y a eu peu de modifications de ce point de vue. Mais les appels OpenGL sont la plupart du temps encapsulés, donc au final ces changements là n'ont que peu d'impact (sauf peut-être pour ceux qui apprennent l'API).
Quand au manque de succès d'OpenGL 3 et 4, les causes sont nombreuses. Entre les drivers calamiteux d'Intel (toutes plateformes confondues), l'énorme retard des drivers libres, et la solide assise qu'a pris Microsoft lorsqu'il a su renouveler son API, l'étonnant aurait plutôt été qu'ils arrivent à percer.
# Juste parce que ça pique les yeux...
Posté par Ellendhel (site web personnel) . Évalué à 8.
Bail.
Cela dit merci d'avoir posté tout cela, la 3D, OpenGL et les batailles autour des implémentations libres me sont assez étrangères, mais j'ai cru comprendre qu'il y a des choses qui pourraient mieux fonctionner, c'est toujours une bonne chose.
[^] # Re: Juste parce que ça pique les yeux...
Posté par monde_de_merde . Évalué à 5.
Mais il y en a bien d'autres des qui piquent les yeux.
# OpenGL le faisait il y a 20 ans
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Pourquoi vouloir abandonner une bonne API faite par un consortium ouvert pour quelques malheureuses fioritures d'une autre API faite par LA boite fermée.
Si vous voulez faire du Direct3D en C#, vous n'êtes pas sur le bon site!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: OpenGL le faisait il y a 20 ans
Posté par monde_de_merde . Évalué à 2.
Il suffit de regarder les tarifs annuels pour une adhésion "utile" : 25 000 $/an pour avoir le droit de participer à l'établissement des spécifications.
Je ne sais même pas si en faisant de gros sacrifices la Linux Fundation pourrait se le permettre (et encore moins la Xorg Fundation).
Je m'en tient à "OpenGL est "open" car "royalties free" (mais pas forcement libre de brevets ce qui pose problème pour l'implémentation dans mesa/gallium).
Je ne connais pas assez la situation de D3D pour m'avancer sur le terrain de la comparaison.
# Plus de branche d3d1x ?
Posté par inico (site web personnel) . Évalué à 1.
L'annonce est maintenant à cette url => http://cgit.freedesktop.org/mesa/mesa/commit/?id=92617aeac10(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.