Le présent article a pour but de faire le point sur l'avancement de Nouveau et de son pilote, ainsi que sur les évolutions attendues. C'est une traduction de celui de Linux Weekly News qui sera publié jeudi. Le site LWN.net nous a gracieusement autorisé à le traduire et publier la version française avant eux. L'article original a été collégialement écrit par les membres du projet.
Si vous souhaitez nous rencontrer, vous êtes les bienvenus au FOSDEM 2008 où une partie de l'équipe du projet Nouveau se rendra les 23 et 24 février. Stéphane Marchesin y présentera les étapes pour arriver à un pilote libre (Samedi 23, 16h30 -17H30 Xorg Devroom).
Cet article fait le point sur l'avancement du projet Nouveau et l'évolution de la pile graphique sous Linux.
== Introduction ==
Nouveau est un projet visant à écrire un pilote X.org libre et complet pour les cartes graphiques Nvidia. L'objectif est de supporter l'accélération 2D et 3D pour toutes les cartes NVidia depuis les NV04 (TNT) aux dernières G80 (Geforce 8), et de supporter les architectures x86-64, PPC et x86.
== Historique ==
Le projet a démarré quand Stéphane Marchesin a voulu désobscurcir une partie du pilote nv, maintenu par NVidia. Malheureusement, un certain nombre de règles étaient en place chez NVidia concernant ce pilote, et ils n'avaient à l'époque aucune intention de les changer. Ils refusèrent les patches de Stéphane.
Il ne restait donc à notre intrépide hacker que le grand choix du libre : forker ! En février 2006, au FOSDEM, Stéphane a dévoilé ses plans pour un pilote libre pour le matériel NVidia appelé Nouveau. Le nom a été suggéré par la fonction de remplacement automatique de son client IRC qui lui proposait le mot « nouveau » lorsqu'il tapait « nv ». Les gens ont aimé et le nom est resté. La présentation au FOSDEM a amené assez de publicité au projet pour attiser la curiosité d'autres développeurs.
Ben Skeggs fut l'un des premiers à s'impliquer. Il avait auparavant travaillé à l'ingénierie inverse des shaders des r300 (un circuit graphique d'ATI) et avait écrit des parties du pilote ; il avait donc une grande expérience avec les pilotes graphiques. Au départ, il s'intéressait uniquement aux shaders des NV40 mais il a par la suite été pris dans le mouvement et a à ce jour travaillé sur à peu près toutes les parties du pilote pour les NV40 et supérieures.
Le projet a attiré d'autres développeurs avec des intérêts à plus ou moins long terme. Un utilisateur indépendant a mis en place une promesse de dons, dont le montant final s'est élevé à 10 000$ US, mais pour des raisons indépendantes de notre volonté nous n'avons pas pu recevoir ces dons.
Le projet étant principalement développé sur IRC, il était assez difficile pour les nouveaux arrivants de se rendre compte des développements antérieurs, lire des logs IRC n'étant pas très pratique. KoalaBR a donc décidé de résumer le développement dans une série d'articles connus sous le nom de TiNDC (The irregular Nouveau Development Companion). Ceux-ci se sont révélés être très utiles pour attirer des nouveaux développeurs et testeurs autour du projet. Le TiNDC est publié toutes les deux à quatre semaines.
Le LCA 2007 a vu la première démonstration réelle de Nouveau. Dave Airlie avait accepté de donner une conférence sur le sujet et a réussi à persuader Ben Skeggs que montrer un glxgears fonctionnel ferait un magnifique final. Ben a travaillé sans répit avec les autres développeurs afin d'avoir une initialisation correcte de la carte de son portable et la présentation fut un véritable succès.
Après avoir manqué de place au Google Summer of Code, X.org a fourni à Nouveau une alternative par l'intermédiaire du Vacation of Code. Celui-ci a vu Arthur Huillet rejoindre l'équipe et travailler sur un support performant de Xv dans Nouveau. Arthur a eu une révélation et il a continué à s'impliquer dans Nouveau après la fin du VoC.
À l'automne 2007, Stuart Bennett et Maarten Maathuis se sont promis d'améliorer le support de Nouveau pour RandR1.2. Depuis, un flot continuel de patches a permis une nette amélioration du code.
Le projet a actuellement 8 contributeurs réguliers (Stéphane Marchesin, Ben Skeggs, Patrice Mandin, Arthur Huillet, Pekka Paalanen, Maarten Maathuis, Peter Winters, Jeremy Kolb, Stuart Bennett) et bien plus de contributeurs occasionnels, testeurs, écrivains et traducteurs.
== Les familles de cartes NVidia ==
Cet article utilisera les noms techniques des GPU (Graphics Processing Unit) NVidia et non les noms commerciaux :
- NV04/05 Riva TNT, TNT2
- NV1x GeForce 256, GeForce 2, GeForce 4 MX
- NV2x GeForce 3, GeForce 4 Ti
- NV3x GeForce 5
- NV4x(G7x) GeForce 6, GeForce 7
- NV5x(G8x) GeForce 8
Pour les noms avec « N » ou « G », nous utilisons de préférence la variante « N » (NV4x et NV5x).
http://nouveau.freedesktop.org/wiki/CodeNames pour plus d'informations
== Généralités sur le système graphique ==
Avant de nous intéresser au pilote Nouveau, nous allons voir dans cette section un bref aperçu de la complexité du système graphique sous GNU/Linux.
Celui-ci a un long historique remontant aux serveurs X Unix et au projet XFree86. Ceci a conduit a une situation très différente de celle des autres pilotes sous Linux. Les pilotes graphiques étaient fournis par le projet XFree86, s'exécutaient principalement en espace utilisateur, et ne requéraient que peu voire pas d'interaction avec le noyau. La partie en espace utilisateur, connue sous le nom de DDX (Device-Dependant X), était responsable de l'initialisation de la carte, de la gestion des modes (NDT : fréquence et résolution) et elle fournissait l'accélération des opérations 2D.
Le noyau fournissait également des pilotes framebuffer pour certains systèmes afin d'avoir une console utilisable avant le démarrage de X. Malheureusement, les interactions entre ces pilotes et ceux de X étaient plus ou moins aléatoires et de nombreux problèmes pouvaient survenir, notamment en cas de conflit sur qui doit diriger le matériel.
Le projet DRI a démarré afin d'ajouter le support pour le rendu direct dans les applications 3D sous GNU/Linux. Rendu direct signifie qu'une application peut parler directement à la partie 3D du matériel, sans passer par le serveur X. OpenGL est l'API 3D standard mais elle est trop complexe et trop grande pour être implémentée dans le noyau, sans compter les différents GPU qui fournissent des interfaces bas-niveaux très différentes. Ainsi, à cause de la complexité de l'interface haut-niveau et de l'absence de standardisation des API matérielles, un composant noyau (DRM, Direct Rendering Manager) et un pilote en espace utilisateur (DRI, Direct Rendering Infrastructure) furent nécessaires pour exposer sans risque les interfaces matérielles et fournir l'API OpenGL.
Les limitations de cette architecture sont apparues au cours des dernières années et le consensus actuel est que l'initialisation du GPU, la gestion de la mémoire et celle des modes doivent migrer dans le noyau. Cela permettra une meilleure cohabitation entre les pilotes X et le framebuffer, un meilleur support de la mise en veille/réveil, une plus grande facilité à rapporter les erreurs noyau (le noyau sera capable d'afficher un message d'erreur à l'écran même si X est lancé), et plus de souplesse pour gérer les futures technologies des cartes graphiques.
Le gestionnaire de mémoire des GPU, implémenté par Tungsten Graphics, est connu sous le nom de TTM ( http://lwn.net/Articles/256772/ ). Bien qu'initialement destiné au matériel Intel, il est conçu comme un gestionnaire de mémoire vidéo généraliste.
Au dessus du gestionnaire de mémoire, un architecture de gestion des modes dans le noyau a été implémentée. Elle est basée sur le travail réalisé avec RandR1.2 dans le serveur X.org.
== Architecture du GPU ==
Les cartes graphiques peuvent être programmées de multiples façons mais la plus grande partie de l'initialisation et de la gestion des modes est faite via MMIO (entrées/sorties projetées en mémoire, Memory Mapped I/O), qui correspond à un ensemble de registres accessibles par le CPU dans son espace d'adressage mémoire standard. Ceux-ci sont ensuite divisés en groupes gérant diverses fonctions telles que gestion des modes, contrôle des sorties vidéos ou encore configuration des fréquences.
Une explication plus complète peut être trouvée à l'adresse suivante : http://en.wikipedia.org/wiki/Memory-mapped_IO
Les GPU les plus récents fournissent également des possibilités de traitement de commandes grâce auxquelles il est possible de décharger le CPU de différentes tâches qui seront alors exécutées sur le GPU, réduisant les ressources CPU nécessaires pour les opérations graphiques.
Ces interfaces sont généralement des FIFO (First In, First Out) implémentées comme des tampons circulaires dans lesquels les commandes sont placées par le CPU et exécutées par le GPU. Elles sont situées dans une zone de mémoire partagée (mémoire AGP, PCIGART ou RAM vidéo). Le GPU possède également un ensemble d'informations d'état, généralement appelées contextes, qui sont utilisées pour traiter les commandes.
La plupart des GPU modernes contiennent une seule machine à états pour traiter les commandes. Le matériel NVidia, quant à lui, a toujours possédé plusieurs « canaux » indépendants qui consistent en une FIFO privée (push buffer), un contexte graphique et un ensemble d'objets de contexte. Le « push buffer » contient les commandes à exécuter par la carte, le contexte graphique stocke les données spécifiques à l'application telles que des matrices, des configuration d'unités de textures, des paramètres de blending, des informations sur les shaders, etc. Chaque canal contient 8 sous-canaux auxquels sont liés les objets graphiques avant leur traitement par la commande dans la FIFO.
Chaque carte NVidia dispose, suivant le modèle, de 16 à 128 canaux assignés à différentes tâches de rendu. Chaque client 3D possède un canal associé, quelques canaux sont réservés pour le noyau et pour le serveur X. Les canaux sont intervertis (« changement de contexte ») par voie logicielle à la suite d'une interruption sur les vieilles cartes, et automatiquement par la carte elle-même pour celles postérieures aux NV30.
Et maintenant, que placer dans la FIFO ?
Chaque carte NVidia dispose d'un ensemble d'objets, chacun d'entre eux fournissant différentes méthodes liées à une tâche donnée, par exemple, transfert mémoire DMA ou rendu.
Ces méthodes sont celles utilisées par le pilote (ou, à un niveau plus élevé, par l'application). Quand un client se connecte, il utilise un ioctl() pour créer un canal. Par la suite, le client crée les objets dont il a besoin à l'aide d'un autre ioctl().
Actuellement, nous avons deux types de client possibles :
X (via le pilote DDX) et OpenGL via DRI/MESA. Un pilote framebuffer accéléré utilisant la nouvelle architecture de gestion de mode (nouveaufb) sera également un client dans le futur, permettant d'éviter les conflits rencontrés avec nvidiafb.
Détaillons quelques uns de ces objets :
nom de l'objet:
NV_IMAGE_BLIT
Description courte:
Moteur 2D, combine plusieurs images en une autre.
Disponible sur:
NV03,NV04,NV10,NV20
nom de l'objet:
NV12_IMAGE_BLIT
Description courte:
Version améliorée du précédent.
Disponible sur:
NV11,NV20,NV20,NV30,NV40
nom de l'objet:
NV_MEMORY_TO_MEMORY_FORMAT
Description courte:
Transfert mémoire DMA.
Disponible sur:
V04,NV10,NV20,NV30,NV40,NV50
Dans cette liste, vous pouvez remarquer que certains objets sont disponibles sur toutes les cartes (NV_MEMORY_TO_MEMORY_FORMAT) tandis que d'autres ne le sont que sur certaines. Par exemple, chaque famille de carte a son propre objet moteur 3D : NV10TCL sur NV1x, NV20TCL sur NV2x, etc.
Chaque objet est identifié par un nombre unique : sa « classe ». Cet ID est 0x5f pour NV_IMAGE_BLIT, 0x9f pour NV12_IMAGE_BLIT et 0x39 pour NV_MEMORY_TO_MEMORY_FORMAT.
Si vous voulez utiliser les fonctionnalités d'un objet donné, vous devez tout d'abord le lier à un sous-canal. La carte fournit un certain nombre de sous-canaux, qui correspondent à un certain nombre d'objet actifs (ou liés).
Chaque méthode fournie par un objet possède un offset qui doit être précisé dans la commande.
Une commande dans la FIFO est composée d'un en-tête suivi par un ou plusieurs paramètres. L'en-tête contient généralement le numéro du sous-canal, l'offset de la méthode à appeler et le nombre de paramètres (une entête peut également définir un saut dans le FIFO mais cela sort du cadre de cette explication).
De façon à limiter la quantité d'entêtes à écrire et donc améliorer les performances, les cartes NVidia peuvent appeler plusieurs méthodes consécutives en une fois si on a correctement fourni plusieurs paramètres.
Comment se réfère-t-on à un objet ?
Les données écrites dans la FIFO ne contiennent aucune information à ce sujet...
Lier un objet au sous-canal 1 est réalisé par l'écriture de son ID comme argument de la méthode 0. Par exemple : 00044000 5c00000c lie l'objet dont l'ID est 5c00000c au sous-canal 2. Cet ID est alors utilisé comme clé dans une table de hachage conservée dans la mémoire de la carte et qui est remplie lors de la création des objets. C'est comme ça que l'objet est identifié.
La création d'un objet a besoin de zones mémoire spéciales :
RAMIN
RAMIN signifie « mémoire d'instance », c'est une zone de mémoire à travers laquelle le moteur graphique est configuré. Une zone RAMIN est présente sur toutes les puces NVidia d'une façon ou d'une autre mais elle a évolué au fur et à mesure de la sortie des nouvelles puces.
En bref, RAMIN est ce qui contient les objets. Ces derniers ne sont généralement pas très gros (128 octets en général, jusqu'à quelques kilooctets dans le cas des objets DMA qui contiennent une liste de pages physiques).
- Pre-NV40 : Zone de mémoire interne dédiée, accessible par les registres MMIO de la carte.
- NV4x : Une ressource PCI de 16Mo est utilisée pour accéder à RAMIN. Cette ressource est représentée sur les 16 derniers mégaoctets de la VRAM. Le premier mégaoctet de RAMIN est également accessible au travers de l'ouverture MMIO (héritée du passé).
- NV5x : La ressource PCI est de 32Mo mais n'est pas utilisable directement au démarrage de la carte. Elle peut être configurée de multiples façons via la mémoire virtuelle des NV5x. L'ouverture MMIO peut être projetée sur n'importe quel segment de 1Mo de VRAM.
RAMIN contient également quelques zones spécifiques à mentionner :
RAMFC - Table des contextes FIFO
- Table globale qui stocke les états/configurations du moteur de FIFO pour chaque canal
- N'existe pas sous cette forme sur les NV5x. Plutôt qu'une table globale unique, les FIFO ont des registres qui contiennent des pointeurs vers les états de chaque canal de FIFO.
RAMHT - FIFO hash table
- Table globale, utilisée par le PFIFO pour trouver les objets de contexte
- sauf sur les NV5x où chaque canal a sa propre hashtable.
Des information supplémentaires sont disponibles sur ces liens :
http://nouveau.freedesktop.org/wiki/NvObjectTypes
http://nouveau.freedesktop.org/wiki/HonzaHavlicek
== Sources d'informations et outils d'ingénierie inverse ==
Étant donné que très peu d'informations sont disponibles sur la conception et l'implémentation du matériel NVidia, le projet Nouveau a développé un certain nombre d'outils afin de mieux comprendre l'architecture des cartes et comment les programmer. Ce sont ces outils, accompagnés d'informations préexistantes, qui sont utilisés pour écrire le pilote.
Haiku/BeOS dispose d'un pilote issu du SDK NVidia disponible pour les cartes NV03/04 et des informations fournies par le pilote nv non obscurci qui a fait un bref passage dans XFree86. Ce pilote possède un code de gestion des modes amélioré par rapport à nv et un pilote 3D basique utilisant des objets fixes et un contexte unique.
D'autres informations sont disponibles dans l'utilitaire nvclock qui permet l'overclocking sous GNU/Linux des GPU NVidia. Son principal auteur, Roderick Colenbrander (Thunderbird) a aidé Nouveau pour la gestion des fréquences, de l'i2c, et de la sortie TV (dont le support n'est pas encore implémenté dans Nouveau).
=== REnouveau ===
Le premier utilitaire qui a été développé est REnouveau. Il permet l'ingénierie inverse du pilote binaire nvidia par la méthode de la boîte noire : envoyer des commandes au pilote d'un côté et étudier ce que le pilote commande à la carte de l'autre. Il utilise pour cela un grand nombre de tests OpenGL couvrant la majeure partie des capacités du GPU et génère un ensemble de fichiers résultats à envoyer aux développeurs de Nouveau.
Il fonctionne en présentant les registres et les FIFO assignés à l'application courante.
Il enregistre ensuite l'état des FIFO et des registres, exécute un programme OpenGL simple et compare l'état final avec l'état initial. Enfin, il écrit l'information dans un format pouvant être lu par un humain en utilisant une base de donnée XML des registres/commandes. (Certains développeurs objecteront que l'hexadécimal est tout à fait lisible pour eux).
Cet outil a comme avantage d'être simple pour l'utilisateur qui peut le lancer sur de nombreuses configurations, sans avoir besoin d'être root. Il ne perturbe pas le pilote binaire et ne nécessite pas de connaissances techniques approfondies.
=== MMioTrace ===
MMioTrace est un outil utilisé pour tracer les accès MMIO dans le noyau. Le pilote NVidia contient en effet un module noyau qui est responsable de presque toute l'initialisation de la carte, la gestion des modes, et qui ne peut pas être observé simplement depuis un outil en espace utilisateur comme REnouveau.
MMioTrace utilise relayFS et debugFS pour remonter les données d'observation vers l'espace utilisateur.
MMioTrace agit en remplaçant, dans le pilote à observer, les appels vers les fonctions noyau ioremap, ioremap_nocache et iounmap par des appels à des fonctions de MMioTrace. Lorsque le pilote modifié appelle ioremap() pour accéder aux registres MMIO, les pages à accéder sont alors présentées comme absentes dans l'espace d'adresse du noyau. MMioTrace peut être paramétré pour ne tracer que les adresses qui pourront être touchées par le pilote, réduisant ainsi le volume du fichier final.
Lorsque le module du pilote essaye d'accéder à l'espace des registres, une erreur de page va se produire. Le gestionnaire d'erreur de page va alors détecter l'adresse et enregistrer l'action tentée. La page est ensuite marquée comme présente, et l'instruction bloquée va être exécutée. La page est ensuite de nouveau marquée comme absente et le cycle peut recommencer au prochain accès.
L'une des restrictions de MMioTrace est qu'il ne peut pas tracer les adresses historiques ISA, marquer celles-ci comme absentes faisant crasher le noyau. Une solution est peut être en vue mais elle nécessiterait de patcher le noyau.
MMioTrace n'est pas seulement utilisable pour les pilotes graphiques mais également pour tous les types de pilotes s'exécutant dans le noyau.
Jusqu'à la version 2.6.23 du noyau Linux, MMioTrace était fourni sous la forme d'un module externe. La version 2.6.24 a vu le retrait des fonctions nécessaires à MMioTrace, ce qui signifie qu'il devra être inclus dans le 2.6.25 ou suivant pour continuer à fonctionner.
Si vous êtes intéressé par plus d'informations, MMioTrace possède une page web dédiée :
http://nouveau.freedesktop.org/wiki/MMioTrace
=== Valgrind-mmt ===
Valgrind-mmt est un greffon pour la suite de débogage Valgrind. Il trace les accès MMIO depuis un processus en espace utilisateur, comme par exemple le serveur X.org où le pilote NVidia DDX est chargé. Cet outil a été développé à l'origine par Dave Airlie pour observer le matériel ATI et ensuite étendu par nombre de développeurs. Il est utilisé dans le cadre de Nouveau, d'une façon plus ou moins similaire à REnouveau, pour extraire le contenu des FIFO.
Valgrind-mmt permet d'observer de façon fiable la FIFO de X.org, ce que REnouveau n'arrive pas très bien à faire. Observer celle-ci est parfois nécessaire pour voir comment certaines fonctions 2D sont implémentées.
== Utiliser MMioTrace pour rajouter une fonctionnalité ==
Les commandes sont en général envoyées à la carte en écrivant dans la FIFO, pas en écrivant les registres MMIO directement, mais certaines tâches telles que l'initialisation de la carte (sélection d'un mode d'écran) nécessitent d'intervenir sur les registres MMIO.
L'exemple ci-dessous montre comment MMioTrace a été utilisé pour effectuer l'ingénierie inverse de l'overlay vidéo YV12, qui existe sur certaines cartes NVidia.
Les vidéos ne sont en général pas stockées en RGB. La plupart des codecs vidéo fonctionnent dans l'espace de couleur YUV, où Y correspond à la luminance (image monochrome), et U et V sont les informations de chrominance (la couleur). La perception de l'oeil humain est plus fine pour la luminance que pour la chrominance, donc la plupart des codecs suppriment une fraction des informations U et V pour gagner un peu d'espace. Quand X-Video demande à la carte d'afficher une image de vidéo, il lui passe un tampon contenant des données YUV, en général en format YV12 ou YUY2.
Bien qu'assez mal fait, le site http://www.fourcc.org/ contient des informations détaillées à propos de ces deux formats. Dans le cadre de cet article, tout ce qui nous intéresse est que YUY2 conserve un échantillon de chrominance (U ou V alternativement) par échantillon de luminance, ce qui signifie que la carte reçoit "YUYVYUYV" (16 bpp). YV12 quant à lui conserve deux échantillons de chrominance (un U, un V) par bloc de luminance de taille 2x2, ce qui donne 12 bits par pixel de video. YV12 est donc 25% plus petit que YUY2, et c'est de très loin le format le plus utilisé par les codecs vidéo. À vrai dire nous n'avons pour l'instant pas trouvé de codec qui sorte autre chose que de l'YV12 (ou du I420, qui est conceptuellement identique - les positions de U et V sont inversées dans le tampon).
Au début de l'été 2007, le support Xv de Nouveau était hérité de nv. En plus d'être extrêmement lent, nv ne supportait que le format YUY2, et convertissait les données YV12 en YUY2 logiciellement, avant de les envoyer à la carte. En travaillant sur l'amélioration des performances, nous nous sommes rapidement demandés si les cartes NVidia supportaient YV12 matériellement. En effet, cela aurait permis de réduire le volume des transferts sur le bus de 25%, ceux-ci jouant un rôle très important dans le débit de Xv, surtout sur les cartes PCI.
Nous avons vérifié cela en mesurant la performance du pilote propriétaire lors de la lecture de vidéos YV12 et YUY2 (en utilisant mplayer -yuy2). Les résultats ont été très clairs :
nvidia propriétaire overlay YUY2 (16 bpp):
real 0m20.591s
nvidia propriétaire overlay YV12 (12 bpp):
real 0m15.409s
Pas besoin de sortir votre calculatrice, il y a une différence de 25%, ce qui correspond à la différence de taille de données. L'explication la plus simple est que ce qui transite sur le bus est en format YV12 : la carte supporte YV12 matériellement.
La situation était donc que nous avions un pilote Xv qui supportait uniquement la vidéo YUY2, et nous savions (du moins pensions, avec un certain niveau de certitude - et d'espérance) que le matériel supportait YV12 nativement. Malheureusement aucun pilote existant, tel que rivatv, n'avait de code pour l'overlay YV12 : il y avait de l'ingénierie inverse à faire.
MMioTrace ne rentre pas en jeu tout de suite : comme indiqué précédemment, la plupart des commandes sont envoyées en écrivant dans la FIFO, pas en touchant aux registres. La première chose à faire était donc d'utiliser valgrind-mmt, pour regarder si la FIFO X contenait certaines commandes relatives à la vidéo.
C'était le cas, mais ces commandes étaient des méthodes logicielles, c'est-à-dire de fausses méthodes pour lesquelles la carte génère une interruption qui demande au noyau de les exécuter. C'est assez similaire à un appel ioctl() vers le module noyau du pilote, sauf que c'est synchronisé avec la FIFO (c'est-à-dire avec le GPU) plutôt qu'avec le CPU. Première conclusion : la sortie vidéo est faite via le module noyau.
Nous avons alors MMioTracé le pilote propriétaire lors de la lecture de vidéos YUY2 et YV12 (de même taille, même position de fenêtre, ... (la seule différence étant le format), et comparé les sorties.
Au milieu des 150Ko de données (la plupart des traces MMIO sont beaucoup plus grandes), nous avons trouvé :
YUY2
NV_PVIDEO.[0].FORMAT
YV12
NV_PVIDEO.[0].FORMAT
NV_PVIDEO+0x800
NV_PVIDEO+0x808
NV_PVIDEO+0x820
Nous avions donc une valeur différente écrite dans FORMAT, et trois registres inconnus. En cherchant dans la documentation et le code existants, il est apparu que le bit 0 du registre FORMAT nous était inconnu.
Nous avons donc essayé de faire marcher l'overlay YV12 dans Nouveau, tout d'abord en mettant simplement à 1 le bit 0 de FORMAT, et sans toucher aux trois registres inconnus. Résultat : pas de vidéo. Il y avait donc un effet, mais nous n'étions pas sûr que le bit 0 de FORMAT correspondait bien au bit "YV12".
Une lecture plus approfondie des MMioTraces nous a montré que ce qui était écrit dans les trois registres était en fait assez similaire à ce qui était écrit dans les registres qui servaient à configurer le tampon de données (indiquer son adresse et sa taille notamment). Nous avons pu deviner ce qui devait être écrit à cet endroit (il s'agissait en fait de la configuration du tampon de couleur, sachant que le tampon principal était utilisé pour les informations de luminance).
Finalement, nous avons fait marcher YV12 dans Nouveau, sans conversion en YUY2, ce qui représente une amélioration de performance des 25% attendus. MMioTrace nous a permis de découvrir comment la carte devait être programmée pour afficher des données YV12, ce qui n'était semble-t-il connu de personne en dehors de NVidia auparavant.
Cela a fini dans nv10_video_overlay.c, dans NV10PutOverlayImage:
/* Those are important only for planar formats (NV12) */
if ( uvoffset )
{
nvWriteVIDEO(pNv, NV_PVIDEO_UVPLANE_BASE(buffer), 0);
nvWriteVIDEO(pNv, NV_PVIDEO_UVPLANE_OFFSET_BUFF(buffer), uvoffset);
}
Il est intéressant de préciser que MMioTrace se contente d'enregistrer les opérations de lecture/écriture réalisées par le noyau - vous pouvez voir presque tout ce que le module noyau fait à la carte. Le désavantage évident étant que « presque tout » représente rapidement une grosse quantité de données :
plusieurs méga-octets, voire plusieurs dizaines, après quelques minutes de MMioTrace. Parcourir ces centaines de milliers de lignes pour trouver celles qui sont intéressantes peut être difficile et nécessite un peu d'expérience.
Nous avons utilisé MMioTrace pour comprendre le fonctionnement de l'overlay YV12, mais aussi pour une majeure partie du code d'initialisation de la carte et de configuration des modes - et il nous servira encore pour beaucoup de choses.
MMioTrace n'est pas limité à Nouveau, il peut tracer les opérations MMIO de n'importe lequel de vos modules noyau (binaires), ce qui permet d'effectuer de l'ingénierie inverse pour n'importe quel matériel.
== Développements actuels dans le domaine graphique sur Unix et leur influence sur Nouveau ==
Nous allons maintenant jeter un oeil sur le futur de l'accélération 3D sous GNU/linux. L'année 2007 a vu un grand nombre de changements majeurs apparaître dans la façon dont Linux et X11 gèrent la partie graphique.
Un grand nombre d'améliorations vont commencer à être utilisées : EXA pour l'accélération 2D, TTM pour la gestion de la mémoire, Gallium3D pour la 3D, la nouvelle interface DRI2... Tous ces changements nécessitent une adaptation des pilotes qui peut prendre du temps.
Avec l'arrivée des cartes graphiques programmables, le design actuel des pilotes graphiques Mesa commence à devenir inadapté. Celui-ci avait en effet été conçu pour des cartes basées sur des fonctions OpenGL fixes, c'est à dire possédant des circuits spécifiques à chaque partie du pipeline GL.
Le design pour ce type de cartes requiert un appel dans le pilote pour chaque nouvelle fonction fixe, ce qui devient vite complexe et oblige à une duplication de code importante entre les pilotes.
Un nouveau design de pilote, Gallium3D, tente de remédier à cela en simplifiant l'interface du pilote tout en maximisant le code partagé. Il est conçu pour fournir tout ce qui est nécessaire à OpenGL 3.0, mais également aux API DirectX ou OpenGL actuelles. Il doit également permettre une portabilité des pilotes sur les OS et plateformes majeurs. Il requiert des circuits graphiques programmables possédant au moins des « fragment shaders ».
Maintenant que nous savons pourquoi le design a changé, voyons l'architecture de Gallium3D. Celui-ci sépare le pilote DRI en 3 composantes : un traqueur d'états commun, une couche « winsys » dépendante de l'OS et un pilote spécifique à la 3D du matériel.
Le winsys est en charge de la partie 2D, de la plupart des tâches de gestion et des parties spécifiques à un OS, tandis que le pilote "matériel" gère la 3D. Chaque pilote doit implémenter la partie gestion matériel et le winsys. Lorsqu'un pilote est porté vers un autre OS, seule la partie winsys doit être réécrite.
La référence complète implémentée de façon logicielle est appelée softpipe. C'est un moteur de rendu logiciel qui permet de présenter les concepts derrière Gallium3D, comment les implémenter et qui agit comme un recours logiciel pour les fonctions que le matériel ne gère pas.
Un dernier composant du nouveau système graphique est le gestionnaire de mémoire TTM qui gère dans le noyau et de façon unifiée toute la mémoire accessible au GPU.
Auparavant, la gestion de la mémoire était séparée entre les pilotes X et utilisait surtout des allocations statiques. TTM a été conçu et implémenté au départ pour les circuits Intel et a dû être adapté pour le matériel NVidia et le design logiciel de Nouveau. La principale fonction, nécessaire pour la gestion des contextes matériels multiples des circuits NVidia, qui a été ajoutée est appelée fence classing.
== Statut actuel ==
Lorsque, l'année dernière, nous sommes passé de l'ingénierie inverse à l'écriture du pilote, on nous a demandé quand celui-ci serait prêt. Nos prédictions tablaient sur l'automne 2007 mais finalement, seule une partie du travail était finie.
À l'exception des NV5x, nous avons un pilote 2D relativement bon. Durant un temps, nous avons même envisagé l'idée de la sortie d'une version uniquement 2D du pilote, idée que nous avons finalement repoussée, l'interface noyau n'étant pas assez stable pour un support à long terme. En effet, lorsqu'un module (comme notre module DRM) est intégré dans le noyau Linux, ses interfaces doivent être par la suite conservées indéfiniment. Ce qui ne serait pas très approprié actuellement pour Nouveau, étant donné que les interfaces vont être amenées à évoluer avec l'arrivée du TTM et de la gestion des modes dans le noyau. Conserver les anciennes interfaces rendrait très complexe l'utilisation et le support des nouvelles.
Aujourd'hui, Nouveau est capable des fonctions suivantes :
- Rendu 2D basique sur toutes les cartes via EXA.
- EXA Composite (implémentant l'extension XRENDER) utilise le moteur 3D sur toutes les cartes à l'exception des NV5x et NV04. Dans ce dernier cas, des limitations matérielles rendent l'implémentation difficile si ce n'est impossible. L'implémentation sur NV1x est un récent exploit étant donné que ces cartes ne possèdent pas de shaders mais seulement deux combineurs de registres de fonctions fixes.
- Xv est disponible des NV04 aux NV4x grâce au travail d'Arthur Huillet, au travers de l'overlay (NV04 ->NV3x), du blitter (toutes les cartes) ou de textures vidéos (NV4x). L'adaptateur de vidéo texturée a été écrit par Stéphane Marchesin qui a travaillé sur un filtrage bicubique pour une meilleure qualité. Les performances de Xv sont équivalentes à celles du pilote binaire nvidia sur de nombreuses cartes.
- Support de l'architecture PowerPC (PPC) Quelques systèmes PPC fonctionnent avec Nouveau. La majorité des problèmes d'ordre des bits a été réglée grâce à l'aide du projet PS3 RSX et de Benjamin Herrenschdmidt. Il reste néanmoins des configurations où surviennent des blocages DMA lorsqu'on essaye d'envoyer des données à la carte. Le code est actuellement audité et la majorité des bogues corrigés.
- Le travail sur RandR 1.2 est en cours, la gestion basique des modes fonctionne à peu près sur NV3x, NV4x et NV5x. Les fonctions plus complexes comme le bi-écran sont en développement constant et progressent très vite.
- Le code du module DRM de Nouveau possède un support préliminaire pour TTM. Par exemple, une FIFO est allouée exclusivement au DRM. Il reste toutefois beaucoup de travail avant d'avoir quelque chose de réellement utile.
- Ben Skeggs travaille sur un pilote Gallium3D pour les NV4x et NV5x. Il fonctionne sur les NV4x mais n'est aucun cas ni complet, ni dépourvu de bogues. De leur côté les NV5x ne fonctionnent pas du tout.
- Stéphane travaille quant à lui à supporter les cartes dépourvues de shaders avec Gallium3D. Il cherche à créer une structure générique à toutes les cartes (NVidia, ATI, Intel, etc) permettant de gérer les instructions shaders sur des cartes anciennes comme celles antérieures aux NV30 (>= NV04) chez NVidia, qui ne disposent pas de shaders.
Actuellement, Les NV5x sont le point faible de notre pilote : elles fonctionnent en 2D de la même façon qu'avec le pilote nv, mais la sauvegarde/restauration de l'état des terminaux virtuels (non-X) ne fonctionne pas.
Tout cela est bien beau mais je vous entends demander : « Et la 3D alors ? »
La réponse courte est simple : nous n'avons pas de 3D fonctionnelle.
La réponse longue est un peu plus nuancée :
Rien ne fonctionne sur NV5x et comme beaucoup de choses ont changé par rapport aux NV4x, pas mal d'ingénierie inverse va être nécessaire. Pour les autres cartes, nous avons les informations mais il y a encore beaucoup à comprendre et à réaliser avant d'avoir un pilote final.
Glxgears fonctionne sur NV1x, NV3x et NV4x mais c'est un prototype et il subsiste différents problèmes. Il faut noter que le travail sur le pilote DRI a cessé au profit de Gallium3D.
Un pilote Gallium3D plus ou moins fonctionnel existe mais avec encore de nombreux bogues et erreurs. Même si ça s'améliore quotidiennement pour les NV4x, on est encore loin de pouvoir jouer avec. Cela dit, Gallium3D lui même est toujours en cours de développement, il ne parait donc pas étonnant qu'il en soit de même pour notre pilote.
La gestion des modes fait actuellement l'objet d'un travail important d'amélioration par Maarten Maathuis et Stuart Bennett, ce qui à terme devrait amener une gestion de RandR1.2 (bi écran et autres) avec Nouveau.
Une fois terminé, tout comme d'autres pilotes, nous prévoyons de migrer la gestion des modes dans le noyau. Une API noyau a été définie dans ce but ( http://lkml.org/lkml/2007/5/17/342, http://lwn.net/Articles/218380/ et http://gitweb.freedesktop.org/?p=MESA/drm.git;a=shortlog;h=m(...) ). Elle ressemble à une version simplifiée de l'API Randr1.2, ce qui devrait rendre la migration assez simple.
Bon, et à quoi devons nous nous attendre ensuite ?
Ceci est seulement une approximation des objectifs à moyen terme :
- Terminer le travail sur la 2D, gestion des modes et RandR1.2 inclus.
- Ingénierie inverse pour les NV5x.
- Implémenter TTM.
- Implémenter un pilote Gallium3D. Évident pour les cartes avec des shaders. Pour les plus anciennes, il faudra attendre que la structure générique de Stéphane fonctionne. Dans le cas où elle se révèlerait irréalisable, un pilote DRI pourrait bien être la seule option pour ces anciennes cartes.
Évidemment, si vous voulez plus de détails, parcourez notre Wiki, lisez les TiNDC ou rejoignez nous sur le canal IRC #nouveau sur freenode (archives disponibles ).
Pour ne pas déroger à la tradition, voici quelques captures d'écran, et commençons par le jeu des 7 différences.
Voici une capture du blob et de Nouveau qui représente le début du premier niveau de NeverBall :
Capture de Nouveau
Capture de NVidia (pilote binaire)
Ben Skeggs semble avoir noté quelques petites différences aussi, et après quelques semaines, a corrigé les rendus incorrects.
Et voilà ce à quoi ressemble OpenArena avec le pilote Nouveau Gallium3D de janvier 2008 :
Capture d'OpenArena
Il semble que les armes sont un peu trop sombres, mais à part ça, il n'y a pas de différences flagrantes.
Plus d'informations sur Gallium3D sur le site de Tungsten Graphics :
http://www.tungstengraphics.com/wiki/index.php/Gallium3D
http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007(...)
Bref, voilà où nous en somme aujourd'hui. Notre feuille de route montre que la prochaine étape importante sera Quake. Elle n'est pas trop loin pour les NV4x, un peu plus pour les autres cartes, d'autres problèmes étant sur le chemin.
Notre première estimation d'automne/hiver 2007 pour une première version n'était finalement pas si mauvaise si on ne regarde que la partie 2D ; même si nous avons du la repousser à cause de certaines décisions architecturales dont nous ne maîtrisons pas forcément tous les délais (TTM et Gallium notamment).
Nous pensons tout de même que ces décisions étaient bonnes et Nouveau sera l'un des pilotes les plus pérennes et les plus avancés technologiquement.
Pour terminer, je (KoalaBr) voudrais remercier Arthur Huillet, Ben Skeggs, David Airlie et Stephane Marchesin pour leur aide dans la rédaction de cet article. Ce fut réellement un vrai travail d'équipe !
Traduction réalisée par Mjules, avec l'aide de Stéphane Marchesin et Arthur Huillet.
Aller plus loin
- Le projet Nouveau (19 clics)
- Les logs IRC et les TiNDC (7 clics)
- Le projet DRI (5 clics)
- X.org (3 clics)
- Tungsten Graphics (4 clics)
- Un résumé du fonctionnement de X11 (5 clics)
# Neverball
Posté par Narishma Jahar . Évalué à 6.
# Arg
Posté par Axel . Évalué à 6.
# Polémique
Posté par patrick_g (site web personnel) . Évalué à 10.
A noter que la parution de cet article dans le LWN de jeudi va être accompagnée d'un long commentaire de Jon Corbet sur l'utilité du projet Nouveau. Le titre est "Reverse engineering: more than NVIDIA deserves?" ce qu'on pourrait traduire par "L'ingéniérie inverse: Plus que ce que mérite NVidia ?".
Selon Jon il y a essentiellement trois acteurs sur le marché des cartes graphiques : Intel, AMD et NVidia.
Intel propose depuis toujours des pilotes libres et a commencé récemment à fournir aussi de la documentation sur ses cartes. Comme une équipe dédié existe chez Intel, l'aide de la communauté des développeurs du libre est réduite.
AMD a aussi choisi de basculer vers le libre et a fourni de la documentation sur ses cartes.
NVidia au contraire ne propose aucun code libre et aucune documentation. La seule chose qui est fournie est un gros blob binaire.
Le problème du projet Nouveau est que cela constitue une "aide" gratuite à la seule firme qui conserve sa mentalité ultra-propriétaire. Pourquoi aider ainsi notre ennemi alors que les deux autres firmes n'ont que peu d'aide de la communauté ?
Jon écrit : "NVIDIA, instead, is giving us nothing - and, in return, we are giving it an eight-person development team dedicated to the production of free drivers for its hardware (..) NVIDIA does not deserve a gift of this magnitude from the community".
Quand il n'y avait aucune autre solutions cela pouvait apparaitre acceptable de se lancer dans l'ingéniérie inverse du hardware fermé de NVidia. Maintenant que les concurrents de NVidia sont tournés vers le libre, que les gammes qu'ils couvrent sont complètes (entrée de gamme pour Intel et haut de gamme pour AMD) pourquoi aider ainsi NVidia ?
Il faut au contraire "punir" NVidia de sa non coopération : "So there will be no need to buy hardware from this particular vendor, and, since the alternatives will be well supported, every reason to buy from somebody else".
Bien entendu Jon admet que Nouveau est intéressant pour les possesseurs actuels de cartes NVidia. Il admet également que certaines personnes s'amusent à savoir comment marchent les cartes graphiques et à écrire des pilotes. Il n'y a pas de mal a être curieux et à écrire du code libre. Mais il faut réfléchir aux conséquences à long terme : "So, as a community, we cannot make a collective decision to stop this kind of development. But, as individual developers, we may occasionally want to give a moment's thought to the question of whether our activities are truly beneficial in the long run.".
A noter qu'il y a eu beaucoup de réactions à cet article de Jon Corbet et que beaucoup de gens sont en désaccord avec lui. Parmi eux il y a, hélas, ceux qui disent que NVidia écrit les meilleurs pilotes pour Linux : "instead of complaining about NVIDIA, we should be thanking them for releasing an excellent (yet unfortunately closed-source) driver".
Mais il y a aussi des arguments plus solides et de nombreuses personnes soutiennent que NVidia ouvrira a un moment ou à un autre ses pilotes. Quand les alternatives libres seront compétitives en terme de performances il n'y aura plus d'avantage comparatif à avoir un pilote fermé et la rationalité prévaudra chez les dirigeants d'NVidia. Dans l'intervalle Nouveau servirait à aider les infortunés libristes ayant acheté des cartes graphiques NVidia et le projet serait donc bénéfique.
Dans tous les cas l'article de Jon Corbet (et ses commentaires) est une lecture très intéressante et je vous le recommande (il ne sera accessible que jeudi prochain pour les non abonnés).
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 6.
Je te propose donc la lecture du lien suivant, qui propose un éclairage tout à fait différent :
http://liquidat.wordpress.com/2007/03/04/the-forcedeth-story(...)
[^] # Re: Polémique
Posté par patrick_g (site web personnel) . Évalué à 9.
Néanmoins, à la lecture de ton lien, je pense qu'on ne peux pas comparer un pilote de chipset et celui d'une carte graphique haut de gamme.
Le premier est "relativement" simple et la concurrence sur ce marché est pléthorique.
Le second est monstrueusement complexe et nvidia est en situation de quasi-monopole sur la 3D haut de gamme pour Linux.
Donc les situations ne sont pas comparables.
Quand au fait que l'article de Jon est partial, je le reconnais tout à fait. Il est partial envers le libre. Il se fiche de la bonne qualité du blob proprio de nvidia et il ne se préoccupe que de l'intérêt à long terme de la communauté du logiciel libre.
Le projet Nouveau est-il intéressant à long terme pour cette communauté du libre ? Je n'en sais fichtrement rien mais la question mérite d'être posée.
[^] # Re: Polémique
Posté par Clément David (site web personnel) . Évalué à 10.
Si cela plaît de se défoncer à faire un pilote libre pour Nvidia, le long terme n'est pas pris en compte dans la motivation. La motivation c'est l'apprentissage du fonctionnement de toutes cartes Nvidia.
Sur le long terme si le driver de Nvidia devient Open source alors tant mieux mais les développeurs veulent s'amuser avec leurs cartes graphiques ne les 'cassont' pas à dire que ce qu'ils font ne sert à rien et est mauvais pour le Logiciel Libre.
Le long terme pour le libre c'est la passion et les projets, de quelques natures que ce soient.
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 10.
Il y a deux solutions. La première est de demander gentiment aux constructeurs de donner les specs, l'autre est de les trouver soi-même sans rien demander.
La première solution (celle que tu proposes) consiste, de manière très schématique, à attendre que AMD distribue effectivement des documentations. Maintenant si je prends un point de vue pragmatique, quel est l'effet immédiat ?
Eh bien aujourd'hui, les drivers R100/R200/R300 ne bougent pas d'un poil, la majeure partie des développeurs attend "parce que au cas où AMD donne les docs sur la partie que j'ai faite, ça serait une perte de temps". En fait les développeurs dépendent alors plus ou moins du bon vouloir du constructeur en matière de documentation.
Et quel sera l'effet sur le long terme ? Personne ne le sait, les documentations, ce n'est jamais quelque chose de gagné, ça peut disparaître du jour au lendemain. Deux générations de cartes n'ayant souvent pas grand chose en commun, il suffit d'une année pour balayer l'existant. Bref en matière de documentation, rien n'est jamais acquis définitivement, par exemple ATI a par le passé donné puis repris les docs à maintes reprises (bien heureux le développeur qui a fait des sauvegardes).
La solution que je propose est d'écrire un driver libre qui se retrouvera dans les distributions dans quelques mois. Quel sera alors l'effet ?
Eh bien sur le court terme, les gens pourront remplacer le driver binaire. Si des gens utilisent le driver libre, ils feront remonter les rapports de bugs et les demandes de nouvelles fonctionnalités vers les constructeurs (DELL, HP et co.).
Et c'est là que se trouve le levier qui permet d'obtenir les fameuses documentations : ce sont en effet les constructeurs qui influencent directement les fabricants de cartes graphiques, puisque ce sont eux qui font du volume. Si le constructeur voit que sous linux, tout le monde utilise le driver binaire nvidia, il n'y a pas de levier. Par contre, si le constructeur voit que beaucoup de gens utilisent un driver libre, il va demander à nvidia de réparer les bugs, voire de participer au développement (sous forme de code ou bien de documentation).
[^] # Re: Polémique
Posté par patrick_g (site web personnel) . Évalué à 10.
Heu...non moi je me contente d'informer les lecteurs de linuxfr de l'existence de l'article polémique de Corbet sur LWN et de faire un résumé des arguments.
J'ai écrit explicitement que je ne savais fichtrement pas quoi penser.
En tout cas ce que je sais c'est que les gens sont libres et travaillent sur ce qui leur chante et que c'est très bien comme ça.
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 6.
AMD fournit de la doc à un rythme élevé. Les meilleurs ingénieurs ne peuvent rivaliser en faisant de ingénierie à rebour. Sur moins de 6 mois, AMD a donné plus de 1000 pages de doc je crois.
Donc il est peut-être pertinant d'attendre (ou d'implémenter ce qui est dans les spècs) que de faire de ingénierie à rebour.
ATI semble vraiment sincère dans sa démarche et on en a les preuves.
L'année 2007 ATI :
http://www.phoronix.com/vr.php?view=11616
L'année 2007 NVidia :
http://www.phoronix.com/vr.php?view=11615
Ce qui peut poser interrogation, c'est la gestion du projet. Pas vraiment de site web, le développement confier à une distribution au-lieu d'être "neutre", etc.
> Eh bien aujourd'hui, les drivers R100/R200/R300 ne bougent pas d'un poil
Et ?
À qui la faute ?
À AMD car AMD donne de la doc. La relation que tu mets ici est "bizarre" (surtout si c'est une comparaison avec NVidia).
Tu crois qu'il faut demander à Intel de ne plus fournir les spècs pour améliorer les drivers Intel ?
Franchement, je ne te comprend pas.
J'ai l'impression que tu fais un "coup bas" contre ATI. Certes ATI n'a pas été exemplaire ses dernières années et le ressentiment qu'on peut avoir est justifié. Mais depuis quelques mois l'implication d'ATI dans Linux est indiscutable.
Nouveau semble avoir une excellente équipe (je n'ai pas les compétences pour juger). Mais si Intel, AMD, etc ne fournissent pas de doc, es-ce que le libre sera en mesure de former une équipe pour les puces Intel, une autre pour AMD, etc ?
J'en doute sérieusement.
Et pour quelle efficacité ?
Le driver radeonhd est en écriture depuis quelques moins. Il y a un support 2D correcte (pour X.org 1.4). D'ici la fin de l'années il y aura probablement un support pour la 3D et fin 2009 il sera plus que correct. En gros ça sera 2 ans d'effort pour un driver de bonne qualité et écrit depuis 0. M'enfin, c'est ce que me dit ma boule de cristal. Combien de temps pour Nouveau ?
De plus, ATI ne va pas dupliquer les efforts, à moyen terme il n'y aura que le driver libre (les autres étant en mode maintenance).
Je suis d'accord avec Jon Corbet, NVidia ne mérite pas le cadeau Nouveau.
M'enfin, ainsi est le libre, libre à qui veut de bosser sur Nouveau.
> les documentations, ce n'est jamais quelque chose de gagné, ça peut disparaître du jour au lendemain
Comme le projet Nouveau...
La doc est là, elle est sous NDA. Les drivers en cours d'écriture est sous licence open source (type BSD je crois, je n'ai pas regardé).
> Deux générations de cartes n'ayant souvent pas grand chose en commun, il suffit d'une année pour balayer l'existant.
Pareil pour NVidia ou autre.
> par exemple ATI a par le passé donné puis repris les docs à maintes reprises (bien heureux le développeur qui a fait des sauvegardes).
Sauf qu'aujourd'hui elles sont sous NDA. Donc tout le monde peut les garder/diffuser. Ça ne va pas disparaitre du jour au lendemain.
> Et c'est là que se trouve le levier qui permet d'obtenir les fameuses documentations
Ben d'autres fournissent déjà la doc. On ne va pas s'en plaindre.
> Si le constructeur voit que sous linux, tout le monde utilise le driver binaire nvidia, il n'y a pas de levier. Par contre, si le constructeur voit que beaucoup de gens utilisent un driver libre, il va demander à nvidia de réparer les bugs, voire de participer au développement (sous forme de code ou bien de documentation).
Je n'en suis pas convaincu...
Ça fait depuis des années que Red Hat ne fournit pas le driver proprio et dit que sa distribution RHEL n'est pas supporté avec le driver proprio. Es-ce que ça a influencé NVidia ? 0, nada.
Je crois que la meilleur façon d'influence NVidia, est de ne pas utiliser NVidia. Il faut privilégier Intel ou ATI. Si l'absence de driver libre impacte le chiffre d'affaire de NVidia, il est quasi sûr que NVidia va se bouger le cul. Peut-être en participant à Nouveau :-)
NB : j'ai rien contre Nouveau ! C'est NVidia qui m'énerve. J'ai actuellement une carte NVidia car elle était avec le PC qu'on m'a donné. J'ai installé Nouveau :-) Ça marche nickel (et mieux que le driver nv) pour mes besoins (pas de 3D). Chapeau bas pour ce travail. Vous avez toute mon admiration. Indiscutablement vous méritez l'aide des utilisateurs NVidia.
Il n'empêche que je ne suis pas content d'avoir une carte graphique qu'un constructeur qui n'aime pas le libre. Bref, je vais m'acheter une carte ATI (OK, je l'ai déjà dit et toujours pas fait :-)).
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 1.
s/NDA/sans NDA/g
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 4.
> les documentations, ce n'est jamais quelque chose de gagné, ça peut disparaître du jour au lendemain
Comme le projet Nouveau...
Ah ? Tu sembles mieux connaître mon projet que moi :)
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 3.
Ce n'est évidement pas ce que je souhaite à Nouveau.
[^] # Re: Polémique
Posté par Mat (site web personnel) . Évalué à 3.
on ne meurt qu'une seule fois !
sauf les phenix éventuellement.
Et je ne souhaite bien entendu pas non plus que cela arrive à Nouveau
[^] # Re: Polémique
Posté par Putifuto . Évalué à 5.
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 6.
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 5.
Si tu ne sais pas programmer, il existe le concept de "bounty" qui est une incitation financière pour les programmeurs.
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 6.
J'ai deja mon quota de participation assez plein et de financement aussi.
J'ai le droit d'avoir une appreciation en accord avec les commentaires/articles du dessus non? Et je trouve que nouveau a beaucoup plus de publicite que les projets pour les drivers ati et intel en effet.
Je trouve tres bien que voir admirable de se lancer dans ce genre de projet mais je trouve un peu dommage que les autres projets aient enormement moins de publicite en comparaison.
[^] # Re: Polémique
Posté par herodiade . Évalué à 6.
Je me demande si ta remarque est un reproche voilé contre cette dépêche (assimilée à de la « publicité » pour le projet Nouveau) ?
Sinon, même remarque que ci-dessous : si tu estime qu'Intel ne reçoit pas assez de pub, tu peu toujours rédiger une dépêche sur les drivers Intel. Il y a plein de choses à dire, par exemple qu'en ce moment même, la version 2.2.1 de leur pilote est en pre-release (v. 2.2.0.90, déjà très stable, mais à tester d'urgence quand même), qu'il y a du boulot en cours pour améliorer les performances d'EXA sur les i965, que le drm Intel est bien avancé (maintenant, le suspend/resume fonctionne totalement sans recourir à des hacks comme vbetool), ou pour parler de la nouvelle branche pour le refactoring du support XvMC d'Intel (avec en perspective, à la clef, l'accélération de la décompression vidéo), ou pour rendre compte des perspectives des premières expérimentations avec Gallium3d + LLVM ou TTM (expérimentations qui sont d'abord faites, comme le dit cette dépêche, avec un pilote Intel)... Il y a de la matière. Bref, pas assez de pub ? then just do it !
J'en profite au passage pour remercier les rédacteurs de cette dépêche, exceptionnellement claire, solide, passionnante, bien écrite, qui permet de se faire une idée très claire de l'état du pilote, des difficultés rencontrés, des perspectives, et au-delà, de présenter d'excitants outils et méthodes de reverse-engeneering.
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 4.
Je peux vous grantir que mon prochain achat d'ordinateur sera uniquement a base de carte graphique ayant un vrai driver opensource au moment de l'achat pas un truc qui un jour sera complet. En gros, ce sera probablement a base d'intel!
[^] # Re: Polémique
Posté par herodiade . Évalué à 8.
Seulement c'est le temps libre des développeurs bénévoles, pas le mien. S'il n'y a pas assez de monde pour encourager les initiatives d'Intel en développant (ou pas assez de monde pour obtenir une proportion de contributeurs externes quantitativement plus importante pour Intel que pour nvidia), hé bien, ma fois, c'est ainsi, et je vois difficilement comment on pourrait reprocher à d'autres développeurs de participer à d'autres projets.
Si vous voulez qu'il y ai deux fois plus de développeurs externes sur le driver Intel que sur le driver nvidia, vous pouvez vous-même participer, ou embaucher une équipe. Mais reprocher aux bénévoles de ne pas donner de leur temps... (ou, déclinaison du même reproche, reprocher à certains d'être trop nombreux à donner du temps à un autre projet ....), c'est une goujaterie.
En résumé : il ne faut pas dire qu'il y a trop de développeurs Nouveau, mais qu'il n'y a pas assez de développeurs bénévoles Intel ; et on n'est pas moralement en droit d'en faire reproche à qui que ce soit d'autre que soi-même.
Incidemment : vous pouvez aider Intel, même si vous n'êtes pas développeur, en participant à leur programme de test (ils ont lancé un appel à l'aide à ce sujet). Voir la section "Getting Involved" sur :
http://www.intellinuxgraphics.org/testing.html
[^] # Re: Polémique
Posté par Zenitram (site web personnel) . Évalué à 8.
AMD a aussi choisi de basculer vers le libre et a fourni de la documentation sur ses cartes.
Euh... Non. AMD a filé un bout de gras à la communauté, et la communauté a dit "génial". Mais c'est... rien.
Donc pour le moment, coté libre, on a le choix entre un driver libre Intel (bas de gamme) et... Rien. Pas de haut de gamme.
Donc Nouveau est la pour compenser.
Mais pourquoi diable dès que le seigneur AMD lache 1 sou à la population, la population l'acclame?
J'attend bien plus de sa part, comme libérer le code qu'il a déja, ou fournir l'ensemble des spécifications, pas 0.00001%.
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 2.
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 6.
http://www.x.org/docs/AMD/
Plus de 1700 pages de doc. C'est un "bout de gras" pour toi ?
En moins de 6 mois !
Presque 300 pages / mois !
La spèc pour la partie 3D est pour mars/avril.
A terme il n'y aura pas deux drivers (un proprio développé par ATI et un libre). Mais qu'un driver libre.
Quand Intel avait annoncé faire du libre, il y a eu des "moqueries" comme tu le fais. Aujourd'hui on sais ce qu'on peut en penser.
> J'attend bien plus de sa part, comme libérer le code qu'il a déja,
Peut-être qu'ATI ne peut pas ?
ATI réécrit quasi complètement les drivers. Ça fait du boulot.
> ou fournir l'ensemble des spécifications, pas 0.00001%.
1700 pages font 0.00001%. Donc la doc complète fait ... 17 milliard de pages...
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 9.
Plus de 1700 pages de doc. C'est un "bout de gras" pour toi ?
En moins de 6 mois !
Presque 300 pages / mois !
La spèc pour la partie 3D est pour mars/avril.
Les docs concernent uniquement le modesetting (c'est-à-dire comment initialiser le GPU et programmer un mode video donné). Si tu regardes bien, il n'y a même pas de quoi faire l'accélération 2D. Le nombre important de pages s'explique par le fait qu'il y a de la réplication d'information entre ces 4 documents. Ces documents ne décrivent ni l'accélération 2D, ni l'accélération vidéo, ni la 3D.
A terme il n'y aura pas deux drivers (un proprio développé par ATI et un libre). Mais qu'un driver libre.
Non, AMD a été clair là dessus, il vont continuer le driver proprio (fglrx) parce qu'ils ont des obligations vis-à-vis de certains clients et partenaires, et qu'avoir le contrôle sur le driver fglrx est leur seul moyen de faire des certifications.
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 0.
Pas que ça. Un exemple :
2.7 Display Controller Registers
2.7.1 Primary Display Graphics Controller Registers
2.7.2 Primary Display Video Overlay Control Registers
2.7.3 Primary Display Video Overlay Transform Registers
2.7.4 Primary Display Video Overlay Gamma Correction Registers
2.7.5 Primary Display Graphics and Overlay Blending Registers
2.7.6 Primary Display Color Matrix Transform Registers
2.7.7 Primary Display Subsampling Registers
2.7.8 Primary Display Hardware Cursor Registers
2.7.9 Primary Display Hardware Icon Registers
Radeonhd supporte XRand 1.2.
> Ces documents ne décrivent ni l'accélération 2D, ni l'accélération vidéo, ni la 3D.
Je ne suis pas un spécialiste, mais il semble bien qu'il y a l'accélération vidéo. Et c'est codé (c'est un début) :
http://lists.opensuse.org/radeonhd/2008-01/msg00233.html
ATI (ou AMD) veut mettre toute la doc à disposition. Il n'y a un "hic", c'est le décodage (h264 ou VC) vidéo. Certains chipsets font du DRM (Digital Rights Management) et ATI ne peut pas fournir la doc pour des raisons légales. ATI a dit réfléchir (NB: il n'y a pas de décision pour l'instant) pour que les prochains chipsets séparent décodage et DRM.
> Non, AMD a été clair là dessus, il vont continuer le driver proprio (fglrx) parce qu'ils ont des obligations vis-à-vis de certains clients et partenaires
Pour les "vieux" chipsets, c'est ce que j'ai compris. Pour les futurs, je n'ai pas compris ça.
M'enfin ce n'est pas clair. Initialement AMD a dit qu'il garderait fglrx en proprio et "point barre". Puis il a été dit que flgrx serait, partiellement, en libre (sauf ce qui pose problème avec les partenaires d'AMD). Par contre ça ne concernerait pas les générations actuelles des cartes ATI, mais les R9 (?) et supérieurs. Avant ça, il y aura utilisation de Mesa (Gallium3D a été envisagé mais semble écarté).
M'enfin, ATI a promis de fournir les spècs 3D (au moins ce qui ne pose pas problème avec les partenaires). Ce qui fait qu'il n'est plus sur ma liste noire :-)
Je dois te donner raison, car ce n'est pas clair.
> et qu'avoir le contrôle sur le driver fglrx est leur seul moyen de faire des certifications.
?!?!
Red Hat certifie ses distributions RHEL, c'est pourtant du libre.
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 6.
Pas que ça. Un exemple :
2.7 Display Controller Registers
2.7.1 Primary Display Graphics Controller Registers
2.7.2 Primary Display Video Overlay Control Registers
2.7.3 Primary Display Video Overlay Transform Registers
2.7.4 Primary Display Video Overlay Gamma Correction Registers
2.7.5 Primary Display Graphics and Overlay Blending Registers
2.7.6 Primary Display Color Matrix Transform Registers
2.7.7 Primary Display Subsampling Registers
2.7.8 Primary Display Hardware Cursor Registers
2.7.9 Primary Display Hardware Icon Registers
L'overlay en question n'est pas utilisable pour la video (Xv) mais est prévu pour les applications OpenGL (genre maya et compagnie). Les registres décrits ne sont pas suffisants pour faire l'accélération 2D.
Radeonhd supporte XRand 1.2.
Oui, il s'agit de faire du modesetting précisément.
Je ne suis pas un spécialiste, mais il semble bien qu'il y a l'accélération vidéo. Et c'est codé (c'est un début) :
http://lists.opensuse.org/radeonhd/2008-01/msg00233.html
L'accélération 2D sur R500 est codée, mais n'est pas décrite dans les documents. En fait elle est codée parce qu'elle est la même que sur R300. Par contre rien sur la 2D pour R600 qui nécessiterait des docs.
Pour les "vieux" chipsets, c'est ce que j'ai compris. Pour les futurs, je n'ai pas compris ça.
M'enfin ce n'est pas clair. Initialement AMD a dit qu'il garderait fglrx en proprio et "point barre". Puis il a été dit que flgrx serait, partiellement, en libre (sauf ce qui pose problème avec les partenaires d'AMD). Par contre ça ne concernerait pas les générations actuelles des cartes ATI, mais les R9 (?) et supérieurs. Avant ça, il y aura utilisation de Mesa (Gallium3D a été envisagé mais semble écarté).
M'enfin, ATI a promis de fournir les spècs 3D (au moins ce qui ne pose pas problème avec les partenaires). Ce qui fait qu'il n'est plus sur ma liste noire :-)
Je dois te donner raison, car ce n'est pas clair.
Effectivement AMD va sûrement bientôt filer des specs 3D. Pour l'architecture utilisée pour la 3D, je ne vois pas comment toi ou moi pourrions savoir, puisque aujourd'hui AMD n'a pas commencé ni fait commencer le travail sur un pilote 3D libre.
> et qu'avoir le contrôle sur le driver fglrx est leur seul moyen de faire des certifications.
?!?!
Red Hat certifie ses distributions RHEL, c'est pourtant du libre.
Sur ce point je ne fais que répéter ce que dit AMD. Je pense qu'ils ont une obligation contractuelle avec certains partenaires qui est incompatible avec l'utilisation d'un driver libre (parce qu'ils utilisent une feature qu'ils ne veulent pas documenter, parce qu'ils veulent mettre du DRM, parce qu'ils ne peuvent/veulent pas entrer en conflit sur une base de code sur laquelle ils n'ont pas la main). Si tu lis ce que dit John Bridgman (qui est celui à AMD qui s'occupe de ça), leurs plans sont très clairs et très cohérents.
[^] # Re: Polémique
Posté par Thomas Douillard . Évalué à 3.
Question d'un benet dans le domaine : qui peut le plus peut le moins non ?
Il me semble avoir lu par ici des commentaires qui disaient qu'ATI voulait carrément décabler la partie 2D des cartes pour utiliser les drivers pour faire gérer la 2D par les circuits 3D ... pas possible de faire pareil ici ?
[^] # Re: Polémique
Posté par Stephane Marchesin (site web personnel) . Évalué à 4.
Exact. En fait sur R600 il n'y a plus de matériel qui gère la 2D. Enfin, pas exactement.
Il existe un firmware pour les R600 qui permet d'émuler la 2D des R500 en utilisant les unités de 3D de la R600. AMD devrait distribuer ce firmware bientôt, il sera alors (en théorie) possible d'utiliser le même code 2D que pour les R500.
Pour la video sur R600, je crois que ça ne fait pas partie des possibilités de ce firmware, et qu'il faudra utiliser la 3D.
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 1.
Certes. Mais il y a une annonce. Pas une annonce où il est dit "on y réfléchit", mais une annonce où il est dit "on va le faire". Ce type d'annonce n'est généralement pas des propos en l'air. M'enfin, je comprend l'attitude "wait and see" tant qu'il n'y a pas la doc.
Merci pour les précisions. Même si je suis d'accord avec Jon Corbet, je te souhaite, et au projet Nouveau, le meilleur.
[^] # Re: Polémique
Posté par Zenitram (site web personnel) . Évalué à 5.
oui.
AMD a pour le moment, de ce que j'ai compris, filé des "annexes" avec des registres.
Super, mais ca ne permet pas grand chose.
Et c'est de la 2D. Super, mais pour le moment on n'a besoin de la 3D.
Bref, j'insiste : ils ont filé un bout de gras. Le nombre de pages ne fait pas tout, si je te files 1 000 000 de pages vides, vas-tu dires 'super, tu m'as filé 1 000 000 de pages, ce n'est pas rien, c'est génial" --> A part détruire la forêt, tu n'as rien à faire de ces pages.
Presque 300 pages / mois !
Et?
Des pages de registres, c'est pas trop dur, et en plus ils ne créent pas, ils lachent juste de la doc.
La spèc pour la partie 3D est pour mars/avril.
Tu serais du style a vendre la peau de l'ours avant de l'avoir tué? Tu crois aussi Miscrosoft quand il dit qu'il veut s'ouvrir? bravo...
J4attend de voir cette partie 3D. Si c'est fournir encore des registres, c'est un bon début, mais c'est seulement en débit. Les registres, c'est sympa, mais ça ne fait pas un GPU...
Ce que j'attends d'un vendeur de carte graphique (ou de matériel en général), c'est qu'il fournisse le matériel, et le driver libre. Ce sont quand même eux les plus à même de connaitre leur matériel!
Filer les specs à la communauté, c'est une chose, c'est "gentil", mais ça ne fait de cette entreprise une entreprise volontariste sur le libre. juste une entreprise pas contre le libre.
C'est juste de la bouffe en pature pour la communauté, pour dire de, rien de plus.
Mais bon, je vois que cette bouffe fait plaisir, alors bon... AMD n'a pas besoin de faire plus. Intel, lui, paye des développeurs...
[^] # Re: Polémique
Posté par Putifuto . Évalué à 9.
Marrant, mais j'ai lu énormément de fois que le principal est d'avoir :
- une doc, qu'un driver libre n'était pas utile parce que la communauté du libre était capable de coder un driver performant à partir de la doc car ça permettrait de supporter plus d'architecture et d'OS.
Aujourd'hui, on demande un driver libre.
On s'aperçoit que :
1) Que les évangélistes du libre n'ont pas le courage/capacité/envie de développer un driver libre.
2) Que l'investissement demandé aux constructeurs est énorme pour 1% du marché.
3) Que fournir un driver binaire a démobilisé la communauté. (Si rien ne marchait, il y aurait plus de volontaire)
4) J'aimerais bien avoir le temps et surtout les compétences pour coder ces drivers :-(
5) Sans des drivers vidéo performants (2D et 3D) Linux ne sera jamais prêt pour le neuneu desktop. Mais je ne pense pas qu'il y a encore beaucoup de gens ici qui ont encore ce genre d'illusion.
[^] # Re: Polémique
Posté par Zenitram (site web personnel) . Évalué à 0.
- une doc, qu'un driver libre n'était pas utile parce que la communauté du libre était capable de coder un driver performant à partir de la doc car ça permettrait de supporter plus d'architecture et d'OS.
Pour un lecteur MP3, une carte d'acquisition video, etc... Pas de soucis.
Le problème d'une carte vidéo est que beaucoup de choses sont fait en logiciel, les vendeurs de carte video "trichent" en implémentant en soft ce qui devrait être fait en hard. Par exemple, si la norme OpenGL etait cablée en brut dans la carte, ça serait facile, hop API... Mais non, le wrapper OpenGL --> carte est énorme, et seul le constructeur peut le faire. Seul hic : ca tourne sur le CPU de la machine, donc il faut que ce soit open-source.
Et surtout... Si ils fournissaient leur vraie doc, une API, et pas une liste de registre brut de forme, ca serait utilisable.
2) Que l'investissement demandé aux constructeurs est énorme pour 1% du marché.
On ne leur demande pas plus que de diffuser le code source ,qu'ils ont déjà en interne...
Et... Le 1% commence à monter (Eee...), les gens commence à voir que le prix du matos descend et que le prix de Windows commence à prendre une sacrée place dans le budget, donc le premier constructeur à fournir un driver libre aura une longueur d'avance... Si il y en a qui part, et c'est la le soucis (Intel ne vend pas en retail, ni ne fait de haut de gamme, et c'est dommage... J'aurai acheté Intel sinon).
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -4.
Le constructeur est un surhomme. Les dvp du libre des sous merde.
Sympa ta vision.
Si ils fournissaient leur vraie doc, une API, et pas une liste de registre brut de forme, ca serait utilisable.
A parce qu'il y a une "api" sur une puce matérielle ?
Sort un peu de ton monde, et va me prendre un datasheet d'une puce matérielle (pas un truc avec un processeur a l'intérieur, et que tu push un code dedans, une VRAI puce matérielle).
Regarde si ils fournissent une "API" et pas une liste des registres.
Tu risque d'avoir quelques désillusions.
[^] # Re: Polémique
Posté par ahuillet (site web personnel) . Évalué à 6.
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -2.
Et désolé, je persiste et je signe, pour des vrais "puces matérielles", ce sont avec des registres que tu joue.
Ensuite que sur les cg , qui sont des systèmes complet, et pas une simple puce, il est possible que la doc soit des commandes proches d'une api, ce que je n'ai jamais refusé.
Donc, par pitié, pour reprendre ton expression, lis au moins les commentaires correctement (ie le commentaire auxquel je répond, pour avoir le contexte).
Allez,comme tu vas pas me croire :
http://focus.ti.com/lit/ds/symlink/tvp5160.pdf
TVP5160
NTSC/PAL/SECAM/Component
2x10-Bit Digital Video Decoder
Data Manual
Regarde le chapitre 4.
Tout plein d'api et de commande qu'on push dis moi...
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -2.
Vous pouvez donc me dire sans problème en quoi la datasheet officiel de ti n'est pas une vraie doc ?
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -8.
donc les moinsseurs fou n'ont même pas le courage d'expliciter leur geste.
Mais quel courage mes petits.
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -7.
Pouvez mieux faire.
Voui, au cas ou vous auriez pas compris, je me fous de la gueule des moinsseurs qui n'ont pas le courage de leur opinion.
[^] # Re: Polémique
Posté par Nicolas Schoonbroodt . Évalué à 6.
[^] # Re: Polémique
Posté par wismerhill . Évalué à 5.
Tout simplement que la datasheet de ti n'a rien à voir avec le sujet puisque le post (de zenitram) auquel tu répondait parlait bien de la doc d'une carte graphique.
Tu répondais:
Sort un peu de ton monde, et va me prendre un datasheet d'une puce matérielle (pas un truc avec un processeur a l'intérieur, et que tu push un code dedans, une VRAI puce matérielle).
Mais les cartes graphique actuelles sont justement des processeurs embarqués.
Ton post a donc été moinssé, très logiquement, parce qu'il n'était pas pertinent par rapport à celui auquel il répondait. Pour les suivants, c'est probablement parce que tu t'en-tête.
[^] # Re: Polémique
Posté par briaeros007 . Évalué à 1.
d'ailleur je l'ai explicité des qu'on ma fait remarqué que mon post ne cadrait pas forcément avec le sujet .
Je cite :
Ensuite que sur les cg , qui sont des systèmes complet, et pas une simple puce, il est possible que la doc soit des commandes proches d'une api, ce que je n'ai jamais refusé.
J'indique donc en plus que je ne parlais effectivement pas des systèmes complet.
Mais ais-je indiqué alors de quoi je parlais ?
La encore : oui.
le post initial :
Si ils fournissaient leur vraie doc, une API, et pas une liste de registre brut de forme, ca serait utilisable.
A parce qu'il y a une "api" sur une puce matérielle ?
On constate que dès mon premier message je me suis concentré sur des puces, et pas des systèmes complet.
Je tenais donc à indiquer que dire "une doc avec que des registres n'est pas une vrai doc" est réducteur et faux.
Tu remarquera que le "vrai" dans le post de zenitram est en gras, et que donc il insistait sur le point de vue qu'une doc avec des registres ne peut pas être une vraie doc.
Répondre par rapport à cette problèmatique, dans ce contexte, n'est pas ahurissant.
Donc c'est ce que j'ai voulu dire , est ce que je l'ai explicité après ?
A nouveau : oui.
euh désolé , mais je répondais comme quoi la doc d'un chipset ne devait pas être avec des registres pour que ce soit une "vrai doc".
Donc
Je te remercie de m'avoir explicité le premier moinssage, que je peux comprendre.
Mais cela n'explique toujours pourquoi des moinsseurs fou ont décidé de moinsser sans , selon toute vraisemblance, lire les autres messages explicatifs.
Pour les suivants, c'est probablement parce que tu t'en-tête.
Tu veux dire que quand j'explique mon premier post, après une réponse m'indiquant qu'il avait mal compris ce dernier, c'est un entêtement ?
D'autant plus que la réponse est un peu hautaine ("Par pitié" ) ?
On dois alors pas avoir la même réponse de "entêtement".
Note à moi même: ne pas expliciter ses posts sur linuxfr, c'est de l'entêtement, et en aucun cas une volontée de discuter posément.
[^] # Re: Polémique
Posté par beagf (site web personnel) . Évalué à 7.
A parce qu'il y a une "api" sur une puce matérielle ?
On constate que dès mon premier message je me suis concentré sur des puces, et pas des systèmes complet.
Je tenais donc à indiquer que dire "une doc avec que des registres n'est pas une vrai doc" est réducteur et faux.
Tu remarquera que le "vrai" dans le post de zenitram est en gras, et que donc il insistait sur le point de vue qu'une doc avec des registres ne peut pas être une vraie doc.
Répondre par rapport à cette problèmatique, dans ce contexte, n'est pas ahurissant.
D'après ce que tu dis, il faut tenir compte du contexte d'un commentaire pour y repondre. Je suis tout à fait d'accord avec toi la dessus et pour moi cela explique le moinsage.
Ton premier commentaire ne tennait pas compte du contexte. Dans le contexte il est parfaitement explicite que l'on parle ici des puces graphiques actuelle et donc une simple liste de registre ne constitue pas une vrai documentation.
Rajoute à ça le ton condescendant que tu utilise et je comprend le moinsage.
Dans ton deuxième commentaire, tu es agrésif et contrairement à ce que tu dis tu ne reconnais pas ton erreur. Tu prétend que l'erreur viens de ahuillet qui "n'a pas été capable de voir que tu ne tenait pas compte du contexte et que tu te foutait que tout le monde parle de carte graphique". En gros ça donne :
- la doc d'une carte graphique doit contenir la doc de l'api
- non la doc d'une puce autre que carte graphique n'en a pas besoin
- on parle pas de puce en général mais de celle des cartes graphiques
- tu es con je te parle des puces en général donc j'ai raison c'est moi qui ait la plus grosse
Donc ici aussi le moinsage est justifié à mon avis.
Pour le reste des commentaires je ne pense pas avoir besoin de t'expliquer le moinsage ? Ils sont parfaitement inutiles et mérittent de disparaitrent.
Donc commence par appliquer à toi même les conseils que tu donne aux autres.
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -1.
Un ton condescendant ?
Voyons voir :
A parce qu'il y a une "api" sur une puce matérielle ?
C'est condescendant ça ?
Si ca c'est condescendant, tout doit etre condescendant pour toi alors.
Sort un peu de ton monde, et va me prendre un datasheet d'une puce matérielle (pas un truc avec un processeur a l'intérieur, et que tu push un code dedans, une VRAI puce matérielle).
La oui à la rigueur c'est condescendant ...
mais si on regarde le message auxquel je répondais , je cite :
Mais non, le wrapper OpenGL --> carte est énorme, et seul le constructeur peut le faire.
ie ceux qui font du LL c'est que des sous merdes.
Mais là ca ne devient plus condescendant là...
Deuxième post aggresif ?
Regardons :
euh désolé , mais je répondais comme quoi la doc d'un chipset ne devait pas être avec des registres pour que ce soit une "vrai doc".
Et désolé, je persiste et je signe, pour des vrais "puces matérielles", ce sont avec des registres que tu joue.
Ensuite que sur les cg , qui sont des systèmes complet, et pas une simple puce, il est possible que la doc soit des commandes proches d'une api, ce que je n'ai jamais refusé.
Pas agressif pour un sou : explication de mon précédent commentaire.
La seule partie qui pourrait être aggresif serait :
Donc, par pitié, pour reprendre ton expression, lis au moins les commentaires correctement (ie le commentaire auxquel je répond, pour avoir le contexte).
Et si on regarde attentivement, on remarque un truc qui dis
pour reprendre ton expression,
donc pas plus agressif que le message auxquel je répondais.
Et ensuite je passe des références.
Alors si vous estimiez que mon ton est condescendant/agressif, ce n'était pas du tout mon but, je m'adaptait juste au ton des commentaires auxquel je répondais.
Ps tu remarquera que le commentaire qui utilisait le "par pitié", donc agressif pour toi, ne fut pas moinssé.
Donc commence par appliquer à toi même les conseils que tu donne aux autres.
Cad quand je moinsse, je donne une raison. Quand j'argumente, je donne des références etc... ?
Ben ca tombe bien, c'est ce que je fait.
La vie est bien faite quand même.
[^] # Re: Polémique
Posté par briaeros007 . Évalué à -1.
Reste donc le commentaire "applique donc le respect du contexte".
Tu remarquera que j'ai expliqué mon comportement, et que j'ai expliqué aussi pourquoi j'ai fait eu cette compréhension de la phrase de Zenitram.
Mais je présume que si un interlocuteur n'a pas la même compréhension du phrase que toi, c'est donc que c'est forcément ton interlocuteur qui a tort, et qu'il est donc normal de ne pas vouloir écouter ses explication.
Oui j'ai eu une compréhension ambigue d'une phrase. Donc j'ai forcément tort ? Même après avoir explicité en long en large et en travers, et que personne n'a pu me montrer 'mais c'est complètement illogique'.
La la remise en cause sur ce thread, je pense que c'est moi qui l'ai faite, et pas franchement les autres acteurs.
bonne pensée?
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 2.
Pas que de la 3D, il y a besoin d'amelioration sur la 2D en particulier sur EXA qui ne fonctionne pas bien avec le driver libre actuel (je n'ai pas teste avec fglrx mais ce dernier ne reste pas tres longtemps vu l'impossibilite de mettre en veille ou en hibernation avec).
[^] # Re: Polémique
Posté par IsNotGood . Évalué à 2.
Moi c'est avant tout la doc. L'absence de doc est une faute grave. Le driver est évidemment bienvenu.
[^] # Re: Polémique
Posté par abramov_MS . Évalué à 3.
Tiens j'ai vu nulle part que fglrx serait arrete d'ailleurs si ils arretent son developpement je me demande l'interet de l'avoir soit disant re-ecrit from scratch. J'ai bien dit soit disant car vu que les bugs des anciennes versions sont encore present dans le nouveau j'ai comme un doute sur le 100%. Les changelog sont assez rigolo car les 90% du temps ne corrige que 1% des anciens bugs sans adresser la moindre correction sur les nouveaux (exemple le bug avec l'AGP introduit dans la version 8.01 pas corrige dans la version 8.02). Apres il est vrai que niveau 3D il est bien plus performant que le driver libre (je soupconne que c'est parceque OpenGL est tres loin d'etre complet dans ce dernier) mais par contre la mise en veille ou en hibernation avec ces drivers tu peux toujours courir pour que cela fonctionne correctement et ca fait au moins 1 an et demi que la situation perdure sans l a moindre amelioration a l'horizon.
C'est cool si la doc 3D arrive bientot meme avec 3 ou 4 mois de retard. En esperant que les anciennes cartes R300 (je preche pour ma paroisse) tres tres commune sur les portables soient enfin supporte correctement a ce niveau la car actuellement j'ai plutot l'impression que toutes les ameliorations se font pour les cartes R600 et plus recentes.
# NV5X?
Posté par Prosper . Évalué à 1.
[^] # Re: NV5X?
Posté par Mjules (site web personnel) . Évalué à 4.
[^] # Re: NV5X?
Posté par Prosper . Évalué à 2.
# Quid des *BSD?
Posté par psychoslave__ (site web personnel) . Évalué à 5.
[^] # Re: Quid des *BSD?
Posté par Stephane Marchesin (site web personnel) . Évalué à 3.
# benchmark
Posté par BAud (site web personnel) . Évalué à 7.
Avez-vous en tête (ou déjà fait) d'avoir des benchmarks permettant
- d'assurer la non régression en terme de perfs pour les fanas des FPS
- de comparer éventuellement des matériels entre eux
Sur http://www.free3d.org/ je suis tombé sur
http://people.freebsd.org/~anholt/dri/benchmarks.html Eric Anholt’s page has DRI benchmarks for a few ATI cards on his Athalon system running BSD.
http://dri.freedesktop.org/wiki/R300Benchmark The DRI folks are trying to collect game benchmarks for the ATI R300 driver.
bon c'est pour ATI mais cela concernant DRI c'est sans doute applicable ?
À une époque j'avais trouvé un benchmark pour nexuiz https://linuxfr.org//~baud123/18393.html mais l'url n'a plus l'air disponible :/
Sinon un benchmark basé sur blender http://www.eofw.org/bench/ (très dépendant du processeur en même temps :/).
et pour les performances globales du système, un benchmark avec brl-cad [http://brl-cad.org] que j'avais lancé http://cookerspot.tuxfamily.org/wikka.php?wakka=CompileBrlca(...)
Il y a de quoi faire...
# bravo ... mais regret
Posté par M . Évalué à 6.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
[^] # Re: bravo ... mais regret
Posté par Stephane Marchesin (site web personnel) . Évalué à 4.
Pour la nv10, je ne promets rien, mais j'entends dire qu'un allumé du bulbe travaille en ce moment même sur un gallium basique pour cette carte (entre 2 commentaires sur linuxfr). La "couche" de support de ces cartes c'est l'affaire de quelques jours après ça.
PS: on reçoit régulièrement des dons/propositions de cartes si tu en a besoin d'une autre pour te remettre à coder.
[^] # Re: bravo ... mais regret
Posté par ʭ ☯ . Évalué à 4.
Combien de pilotes ephémères ont vu le jour sous Linux? Rappelez-vous les UtaxGLX jamais portés vers DRI/DRM...
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: bravo ... mais regret
Posté par Patrice Mandin . Évalué à 6.
Pour le DRM, il y a eu l'arrivée du TTM, chargé de gérer la mémoire de la carte vidéo. Pour le DRI de Mesa, déjà qu'il fallait passer pas mal de temps à comprendre comment faire un driver, il se trouve que Gallium3D pointait son nez.
Donc on se retrouvait souvent coincé entre l'enclume et le marteau, coté développeurs, entre le code qu'on pouvait écrire avec les infos qu'on avait trouvé par reverse engineering, et les nouvelles API "beaucoup plus mieux qu'avant" sur lesquels baser le code à écrire. Ce qui a fortement ralenti le développement je pense, en tout cas pour moi.
[^] # Re: bravo ... mais regret
Posté par reno . Évalué à 2.
Et vu la complexité du sujet, cela ne m'étonnerait pas que la phase de 'stabilisation' soit assez longue, avec bien sûr des impacts sur Nouveau.
# CUDA
Posté par Émilien Tlapale . Évalué à 4.
[^] # Re: CUDA
Posté par Pinaraf . Évalué à 8.
Cf http://zrusin.blogspot.com/2008/02/gpgpu.html
# Docs AMD
Posté par motörhead . Évalué à 3.
http://www.phoronix.com/scan.php?page=article&item=amd_t(...)
[^] # Re: Docs AMD
Posté par Olivier Esver (site web personnel) . Évalué à 1.
Si mes souvenirs sont bons la news était daté du 22 février (oui dans le futur) et cela parlait des doc sur la 3D pour les chips ainsi qu'un programme nommé tcore, utilisé lors de tests interne chez AMD pour la mise au point de leur drivers, qui pourrai être libéré.
Peut être que l'annonce officielle sera faite lors du FOSDEM.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.