Le réseau ethernet est full duplex, c'est-à-dire 1 gigabit en entrée et un autre en sortie. Donc il nous faut de l'ordre de 2*128Mo/s de débit sur le bus pour que ça passe. Ce qui veut dire qu'on ne peut pas atteindre les débits maximaux du gigabit avec une carte PCI standard.
Alors, il existe effectivement un driver GLX qui fonctionne avec les NV04 (TNT), NV05 (TNT2) et toutes les variantes de NV10 (geforce 1, geforce 2mx, geforce 2ti/gts, geforce 4 mx). Le problème c'est que ce driver utilise les geforces comme si c'étaient des TNT/TNT2 (ces cartes ont en effet un mode rétro-compatible avec la famille TNT).
Si on se refère aux docs des cartes : http://nouveau.cvs.sourceforge.net/nouveau/renouveau/nv_obje(...)
ça veut dire qu'au lieu d'utiliser NV10_TCL_PRIMITIVE_3D il utilise NV04_DX5_TEXTURED_TRIANGLE et donc ne tire pas partie de tout un tas de fonctionnalités, dont le TCL matériel (et bien d'autres choses, je t'invite à comparer les 2 objets en question).
D'autre part ce driver est un driver GLX, c'est-à-dire qu'il tourne complètement en user space et donc nécessiterait une réecriture si on voulait récupérer le code.
Donc finalement, ce driver est principalement intéressant pour comprendre le fonctionnement des TNT/TNT2, mais je ne pense pas que récupérer son code soit une bonne idée.
Peut-ête veut-il dire avant que la carte ne soit plus vendue?
J'espère que non :) Je pense en particulier aux possesseurs de TNT, TNT2, et Geforce 1 ou 2 qui sont obligés d'utiliser le pilote "legacy" de nvidia. Ces cartes ne sont certes plus vendues, mais pourraient très bien supporter AIGLX.
Pour ces utilisateurs, l'arrivée d'un pilote implémentant AIGLX serait intéressante même si leurs cartes ne sont effectivement plus en vente depuis longtemps.
A la base c'était la sortie d'un gcc -E... et je crois pas que ce soit la forme préferée pour faire des modifications.
Attention, si on veut pinailler, la "forme préferée pour faire des modifications" n'est imposée que par la GPL, pas par la license MIT qui est justement celle qui couvre ce pilote. Et on considère pourtant en général que la license MIT est libre...
Combien de model de radeon dont nous avons finalement toutes les specs suffisantes, fonctionnent-elles au poil?
En fait peu de développeurs ont les specs des radeon, ce sont ceux qui ont signé un NDA il y a plusieurs années, et c'était pour R100 ou R200. Les docs R300 se limitent à des registres décrivant la 2D.
Le projet DRI semble aller dans tous les sens en même temps.
Tous les sens ? Par rapport au fait qu'on travaille sur ATI et Nvidia ? Ce ne sont pas les mêmes personnes, et puis je pense qu'on n'a pas d'obligation de travailler sur tel ou tel modèle de cartes, en particulier quand on fait ça dans son temps libre et bénévolement. Il faut se faire plaisir avant tout !
Alors partir sur du Nvidia sans infos et arriver à faire mieux - ou équivalent - que leurs ingénieurs qui, soit dit en passant, font d'excellent pilotes, me fait doucement rire ...nerveusement.
Ne vous y trompez pas, j'envie autant que vous des pilotes de libres pour cartes graphiques*, mais bon qu'elles sont nos chances d'avoir quelque chose de fonctionnel et dans les temps?
Je t'accorde que les pilotes de nvidia sont très bons. C'est sûr que si tu vises des performances tip-top, c'est ceux-là qu'il faut utiliser. Maintenant si tu veux des pilotes libres, ou que tu as un powerpc, ou une autre machine un peu exotique, tu es content de trouver une alternative.
Pour ce qui est d'avoir quelque chose de fonctionnel "dans les temps" je ne vois pas vraiment ce que tu veux dire. Tu as une échéance précise en tête ?
La question est pertinente. Oui, nous partons du driver "nv" et nous nettoyons le code et rajoutons le support pour la 3D. Non, ce n'est pas fait dans l'arborescence officielle parce que cettte arboressence est maintenue par des developeurs travaillant pour nvidia, et que ça pourrait causer des conflits.
- Je travaille pour l'instant majoritairement sur NV40 (j'ai un NV44 donc geforce 6200). L'architecture du NV40 est très proche du NV30 (donc geforce 5x00), et il semble possible d'unifier le code d'envoi de primitives pour supporter aussi NV10 et NV20 (comme c'est fait dans le CVS nv10_swtcl.c). De la même manière, je pense que le support du G70 (geforce 7x00) restera assez proche.
- Je n'exclus pas le support des vieilles cartes comme NV03/NV04/NV05, en tout cas au moins un support minimal. En particulier le NV03 n'a pas actuellement de support de la 3D du tout, ni libre ni propriétaire.
- Je vais pinailler mais L'un des outils créés pour l'occasion enregistre les changements faits au niveau des registres de la carte vidéo sur le bus PCI n'est pas tout à fait exact. Ce que l'outil fait est simplement d'afficher le contenu de la fifo de commandes de la carte.
- Si quelqu'un récupère la video de la conf, je veux bien l'avoir aussi. Donc n'hésitez pas à me faire un email si vous tombez dessus.
- J'en profite aussi (et surtout) pour lancer un appel à contributions : si vous avez envie de participer, vous pouvez venir sur #dri-devel sur freenode, et/ou m'envoyer un mail. Il y a du travail pour tous, surtout pour découvrir les fonctionnalités des cartes, ça ne demande pas énormément de compétences en programmation et c'est une partie très importante du travail.
Perso, je ne vois rien de nouveau, ils ne propose du GNU/Linux que sur leurs "petites" configs à base de proc Intel, comme Sun ou IBM.
Pour les archis plus sérieuses, se basant sur le proc maison (MIPS, Sparc, Power) ... ils s'en tiennent toujours à leur Unix proprio, développé spécialement pour cette archi.
Je dirais que c'est exactement le contaire. Linux est maintenant utilisé pour le haut de gamme, et en bas de gamme (ou plutôt en fin de série) on trouve les stations sous irix. Les prism sont faites pour monter à plusieurs dizaines de CPU et autant de pipelines graphiques. Il s'agit donc du haut du panier en matière de machines de visualisation.
D'ailleurs c'est la même chose pour les machines de calcul comme l'altix : sgi utilise linux. Et ce n'est pas non plus le bas de gamme, une altix est numéro 2 sur top500.org en ce moment.
Bien sûr, il ne s'agit pas de bêtement copier, mais si Carmack, ou en général aucun développeur professionnel (je parle des superproductions type NeverwinterNights, Unreal Tournament, Doom 3...) n'utilise SDL, par exemple, c'est bien qu'il y a une raison.
Franchement, tu pourrais te documenter avant de sortir de telles âneries. Sur tes 3 exemples, tu t'es planté pour deux ! En effet, NeverwinterNights et Unreal Tournament 2003/2004 utilisent SDL. D'ailleurs la plupart des jeux portés par Ryan Gordon utilisent SDL (America's Army, Postal 2, Serious Sam 2, Army Ops...).
C'est pourquoi m'est venue cette réflexion :
- la liberation des drivers SiS ne permettrait elle pas, indirectement, de comprendre certains principes de fonctionnement commun aux cartes concurrentes (ATI, nVidia)?
- Et donc éventuellement d'aider à l'écriture de drivers libres pour les puces ATi et nVidia?
Non, malheureusement ça n'aide pas.
Pour résumer, toutes les cartes graphiques font effectivement la même chose (dessiner des triangles avec des textures). On sait assez précisément ce qui se passe à l'intérieur (le comportement est spécifié par des specs comme OpenGL), mais tout le problème est en général de savoir comment s'en servir. En effet, pour programmer une carte on utilise des registres, qui ne sont que des adresses (et on ne sait pas à priori quel registre fait quoi). Et tout le problème quand on ecrit un driver sans docs est justement d'associer une adresse à une fonctionnalité, et pas de comprendre les foncitonnalités elles-mêmes (pour comprendre ces fonctionnalités, il suffit de lire des docs sur OpenGL).
Pour comparer avec de la programmation en C, c'est un peu comme si on avait le code (les .c) et qu'on savait ce qu'il fait, mais qu'on ne connaisse pas les interfaces pour s'en servir (les .h).
< pub>
D'ailleurs, pour ceux que ca intéresse de bosser sur des drivers 3d libres, il y a une mailing list (dri-devel sur sourceforge) et un channel irc #dri-devel sur freenode.
< /pub>
si il y a des trucs "bizarre" a utiliser -03 ou -fast-math, alors c'est un bug de gcc ou de l'appli et ça se corrige.
En fait, -ffast-math donne un comportement qui ne respecte pas le standard IEEE sur les calculs flottant, en particulier sur les nombre denormals (dénormaux ?) et infinis. Ce genre d'erreur peut se propager dans tout un calcul et même passer totalement inaperçue et mener à des résultats erronés.
Et il ne s'agit pas là d'un bug dans un programme. L'application attend un certain standard dont elle a besoin pour tourner correctement et il faut que le compilateur le respecte.
J'utilise LZO pour transmettre des données entre plusieurs machines, et la seule technique est d'envoyer la taille avec les données compressées, par exemple dans une en-tête. Il n'y a effectivement aucun moyen de connaître la taille décompressée sans faire la decompression.
toi, t'as pas essayé doom3 et ses 5fps et ses bugs un peu partout :)
Non, j'ai une radeon 7000 de toute manière :)
Cela dit, Doom3 est lent parce que sur les radeon il est censé utiliser ATI_fragment_shader, et que cette extension n'est pas implémentée par le DRI puisque très peu de gens ont les specs de la carte. Du coup doom3 sur DRI utilise les extensions ARB de base, et ça a comme effet d'aller plus lentement, et d'avoir un rendu de moins bonne qualité.
Avec mon XP2500+ et cette fichue carte, j'ai les perfs d'un Celeron 933 avec une i810.
Justement, les améliorations de performance sont très récentes (elles datent d'un mois environ), et devraient être plus importantes encore sur les chips IGP. Donc tu as interêt à passer en Xorg cvs/DRI cvs/DRM cvs.
Les ATI sont pas franchement les pires, car tu as des pilotes libres qui marchent en 3D (certe c'est lent, mais ça marche).
Mais mais mais pas du tout !
Avec une r200 (par exemple radeon 8500, 9000, 9200) les derniers pilotes DRI (cvs) sont plus rapides pour quake 3 et Enemy Territory, les derniers pilotes ATI (8.8.25) sont plus rapides pour ut2003 :
... a fait de l'ingénérie inverse pour faire marcher le hyperz le color tiling. Pour les infos techniques, voyez la mailing liste ou passez sur irc. Mais concrètement, on gagne au minimum 40% de perfs (ah je sens que vous êtes intéressés d'un coup :). Vivement que tout ça soit terminé et aille dans le CVS qu'on puisse faire des benchmarks par rapport à fglrx.
J'espere que cela ne s'arretera pas la, et que bientot "univ-r" (la plateforme utilisée comme "laboratoire virtuel", mais aussi utilisé comme bureau accessible de partout aux étudiants) passera bientot sur une plate forme libre, et deviendra plus utilisable (l'interface actuelle, sous win2k3 est lourde et peu ergonomique.
Cf mon commentaire ci-dessous, ils sont complètement liés à microsoft.
J'espere aussi que les enseignements à l'ULP se tourneront aussi vers le libre (je pense notement a nos enseignement de bases de données, qui s'appuient sur Oracle, alors que PosgreSQL serait tout approprié).
J'avais demandé à nos profs il y a quelques années et la raison c'est que "dans les entreprises on utilise oracle, donc on vous ensigne ça pour que ca fasse bien sur le CV".
Et ben c'est à dire que j'ai justement du Raid 5 software. Mais c'est pas pour autant que ca me certifie que mes données sont integrent.
La problematique, c'est que mes disques sont neuf et je dois recreer la matrice tout les 15 jours environ(lorsque la machine est assez solicité), notament sur le disque hda, mais pourtant il semble etre bon.
Je vais peut-être te décevoir, mais ça fait au moins 5 ans que tous les disques durs vendus intègrent des mécanismes de CRC. Donc ça veut dire que ce que tu confies à ton disque, il le régurgite toujours à l'octet près après avoir fait les vérifications de CRC (et si le CRC est mauvais, il fait en général un reset du disque et relit le secteur, et s'il y a vraiment un problème il fait des reset à l'infini et tu obtiens le chant du cygne caractéristique des disques durs mourrants). Ce qui veut dire que ton problème est ailleurs :
- ta ram est défaillante ( -> memtest86 :)
- problème de chipset (dû à un overclocking ou à un driver IDE buggé ou à une carte mère mourrante...).
Mais je penche plutôt pour la premiere explication.
Franchement l'époque où les disques durs étaient stupides est révolue depuis longtemps. Maintenant ils sont capables de s'auto réparer (par exemple ils ont des secteurs en rabe, et quand ils en trouvent des défectueux ils peuvent les déplacer. Mais toute l'opération est transparente même pour l'OS). On dispose d'ailleurs d'outils pour interroger les status du disque, commme par exemple le package ide-smart.
En fait il n'y a pas vraiment de documentation simple et complète. Le mieux que j'ai trouvé c'est :
- http://graphics.tomshardware.com/graphic/20020718/radeon9700-08.htm(...)
C'est dans le test de la radeon 9700, mais en fait ça décrit le fonctionnement de l'hyperz dans les radeon de type R100, sûrement que ATI ne voulait pas parler du fonctionnement sur R300.
- http://www.beyond3d.com/reviews/ati/radeon8500p2/index3.php(...) (et les pages qui suivent) qui décrit à peu près l'hyperz tel qu'il est sur les cartes de type R200.
- http://www.merl.com/hwws00/presentations/ATIHot3D.pdf(...) qui est la présentation faite au Siggraph workshop on graphics hardware de 2000. C'est plus technique et en fait c'est grâce à ce document que j'ai commencé à comprendre comment ça marchait vraiment.
Bref le dri c'est bon, mangez-en (enfin moi j'ai une radeon 7000 donc j'ai pas d'autre choix :).
Concernant ce que j'entend par "ça marche encore assez moyennement", il me semble, si je ne me trompe pas, que tu es plutôt bien placé pour connaitres les problèmes qui sont présents pour l'instants ;) (je me plante peut être...)
Oui, ce n'était pas une critique mais juste un encouragement à faire remonter les bugs report, parce qu'on en manque. A priori, tous les programmes qui ne font pas de lectures dans le z buffer (99% des jeux) devraient fonctionner correctement, d'où ma question.
La seule chose manquante c'est le support du hierarchical z sur r200 mais ça ne devrait affecter que les performances (et uniquement sur ce type de cartes) et pas la correction. Je pense que faire marcher le hierarchical z est une cause perdue, et en plus ça pose un tas de problèmes anexes (par exemple sous doom 3 il doit être desactivé pour avoir un rendu correct, et ce même avec les pilotes ati propriétaires ou sous windows).
Cela dit, on n'a pas encore épuisé les sources d'optimisations sur radeon et il reste encore de la marge (je dirais en gros une 20aine de %). Y a plus qu'à écrire le code :)
En ce moment, une "super" chose a été rajouté aux pilotes, mais ça marche encore assez moyennement, l'hyperz qui semble booster les perfs...
Hum, qu'entends tu par "ça marche encore assez moyennement" ? Tu as des problèmes avec ? Si oui, un petit bug report serait le bienvenu (les bugs report à propos des glReadPixels sur le zbuffer sont exclus :) ).
[^] # Re: Concurrence Intel
Posté par Stephane Marchesin (site web personnel) . En réponse au journal OpenGraphic. Évalué à 3.
PCI = 32bits * 33Mhz = 132Mo/s
Le réseau ethernet est full duplex, c'est-à-dire 1 gigabit en entrée et un autre en sortie. Donc il nous faut de l'ordre de 2*128Mo/s de débit sur le bus pour que ça passe. Ce qui veut dire qu'on ne peut pas atteindre les débits maximaux du gigabit avec une carte PCI standard.
[^] # Re: nouveau driver nouveau ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 3.
Si on se refère aux docs des cartes :
http://nouveau.cvs.sourceforge.net/nouveau/renouveau/nv_obje(...)
ça veut dire qu'au lieu d'utiliser NV10_TCL_PRIMITIVE_3D il utilise NV04_DX5_TEXTURED_TRIANGLE et donc ne tire pas partie de tout un tas de fonctionnalités, dont le TCL matériel (et bien d'autres choses, je t'invite à comparer les 2 objets en question).
D'autre part ce driver est un driver GLX, c'est-à-dire qu'il tourne complètement en user space et donc nécessiterait une réecriture si on voulait récupérer le code.
Donc finalement, ce driver est principalement intéressant pour comprendre le fonctionnement des TNT/TNT2, mais je ne pense pas que récupérer son code soit une bonne idée.
[^] # Re: nouveau driver nouveau ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 4.
J'espère que non :) Je pense en particulier aux possesseurs de TNT, TNT2, et Geforce 1 ou 2 qui sont obligés d'utiliser le pilote "legacy" de nvidia. Ces cartes ne sont certes plus vendues, mais pourraient très bien supporter AIGLX.
Pour ces utilisateurs, l'arrivée d'un pilote implémentant AIGLX serait intéressante même si leurs cartes ne sont effectivement plus en vente depuis longtemps.
[^] # Re: nouveau driver nouveau ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 3.
Attention, si on veut pinailler, la "forme préferée pour faire des modifications" n'est imposée que par la GPL, pas par la license MIT qui est justement celle qui couvre ce pilote. Et on considère pourtant en général que la license MIT est libre...
[^] # Re: nouveau driver nouveau ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 8.
En fait peu de développeurs ont les specs des radeon, ce sont ceux qui ont signé un NDA il y a plusieurs années, et c'était pour R100 ou R200. Les docs R300 se limitent à des registres décrivant la 2D.
Le projet DRI semble aller dans tous les sens en même temps.
Tous les sens ? Par rapport au fait qu'on travaille sur ATI et Nvidia ? Ce ne sont pas les mêmes personnes, et puis je pense qu'on n'a pas d'obligation de travailler sur tel ou tel modèle de cartes, en particulier quand on fait ça dans son temps libre et bénévolement. Il faut se faire plaisir avant tout !
Alors partir sur du Nvidia sans infos et arriver à faire mieux - ou équivalent - que leurs ingénieurs qui, soit dit en passant, font d'excellent pilotes, me fait doucement rire ...nerveusement.
Ne vous y trompez pas, j'envie autant que vous des pilotes de libres pour cartes graphiques*, mais bon qu'elles sont nos chances d'avoir quelque chose de fonctionnel et dans les temps?
Je t'accorde que les pilotes de nvidia sont très bons. C'est sûr que si tu vises des performances tip-top, c'est ceux-là qu'il faut utiliser. Maintenant si tu veux des pilotes libres, ou que tu as un powerpc, ou une autre machine un peu exotique, tu es content de trouver une alternative.
Pour ce qui est d'avoir quelque chose de fonctionnel "dans les temps" je ne vois pas vraiment ce que tu veux dire. Tu as une échéance précise en tête ?
[^] # Re: nouveau driver nouveau ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 10.
La question est pertinente. Oui, nous partons du driver "nv" et nous nettoyons le code et rajoutons le support pour la 3D. Non, ce n'est pas fait dans l'arborescence officielle parce que cettte arboressence est maintenue par des developeurs travaillant pour nvidia, et que ça pourrait causer des conflits.
# Rejoindez nous dans NouVeau on s'amuse bien
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 10.
J'ai différentes réponses à des questions/remarques :
- Les diapos de la présentation sont là : http://icps.u-strasbg.fr/~marchesin/presentation-nvidia-fosd(...)
- Je travaille pour l'instant majoritairement sur NV40 (j'ai un NV44 donc geforce 6200). L'architecture du NV40 est très proche du NV30 (donc geforce 5x00), et il semble possible d'unifier le code d'envoi de primitives pour supporter aussi NV10 et NV20 (comme c'est fait dans le CVS nv10_swtcl.c). De la même manière, je pense que le support du G70 (geforce 7x00) restera assez proche.
- Je n'exclus pas le support des vieilles cartes comme NV03/NV04/NV05, en tout cas au moins un support minimal. En particulier le NV03 n'a pas actuellement de support de la 3D du tout, ni libre ni propriétaire.
- Je vais pinailler mais L'un des outils créés pour l'occasion enregistre les changements faits au niveau des registres de la carte vidéo sur le bus PCI n'est pas tout à fait exact. Ce que l'outil fait est simplement d'afficher le contenu de la fifo de commandes de la carte.
- Si quelqu'un récupère la video de la conf, je veux bien l'avoir aussi. Donc n'hésitez pas à me faire un email si vous tombez dessus.
- J'en profite aussi (et surtout) pour lancer un appel à contributions : si vous avez envie de participer, vous pouvez venir sur #dri-devel sur freenode, et/ou m'envoyer un mail. Il y a du travail pour tous, surtout pour découvrir les fonctionnalités des cartes, ça ne demande pas énormément de compétences en programmation et c'est une partie très importante du travail.
[^] # Re: sdl
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Que pensez-vous du SDK de développement de jeu Torque 2D/3D ?. Évalué à 9.
Alors d'une part, les alpha blitters en soft de SDL sont parmi les plus rapides qu'on peut trouver (écris en assembleur MMX).
Et d'autre part, avec glSDL (SDL qui utilise OpenGL pour la 2D) on peut avoir l'alpha blending en hard :
http://icps.u-strasbg.fr/~marchesin/sdl/SDL12-experimental.tgz(...)
http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html(...)
Espérons qu'on trouvera bientôt glSDL dans les release officielles de SDL...
[^] # Re: Bof ...
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Du linux chez sgi. Évalué à 6.
Pour les archis plus sérieuses, se basant sur le proc maison (MIPS, Sparc, Power) ... ils s'en tiennent toujours à leur Unix proprio, développé spécialement pour cette archi.
Je dirais que c'est exactement le contaire. Linux est maintenant utilisé pour le haut de gamme, et en bas de gamme (ou plutôt en fin de série) on trouve les stations sous irix. Les prism sont faites pour monter à plusieurs dizaines de CPU et autant de pipelines graphiques. Il s'agit donc du haut du panier en matière de machines de visualisation.
D'ailleurs c'est la même chose pour les machines de calcul comme l'altix : sgi utilise linux. Et ce n'est pas non plus le bas de gamme, une altix est numéro 2 sur top500.org en ce moment.
[^] # Re: paradigmes divergents !
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Développer des jeux vidéos sous Linux ?. Évalué à 2.
Franchement, tu pourrais te documenter avant de sortir de telles âneries. Sur tes 3 exemples, tu t'es planté pour deux ! En effet, NeverwinterNights et Unreal Tournament 2003/2004 utilisent SDL. D'ailleurs la plupart des jeux portés par Ryan Gordon utilisent SDL (America's Army, Postal 2, Serious Sam 2, Army Ops...).
[^] # Re: une avancée pour les drivers des autres cartes?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XGI et VIA libèrent le code de leurs pilotes. Évalué à 10.
- la liberation des drivers SiS ne permettrait elle pas, indirectement, de comprendre certains principes de fonctionnement commun aux cartes concurrentes (ATI, nVidia)?
- Et donc éventuellement d'aider à l'écriture de drivers libres pour les puces ATi et nVidia?
Non, malheureusement ça n'aide pas.
Pour résumer, toutes les cartes graphiques font effectivement la même chose (dessiner des triangles avec des textures). On sait assez précisément ce qui se passe à l'intérieur (le comportement est spécifié par des specs comme OpenGL), mais tout le problème est en général de savoir comment s'en servir. En effet, pour programmer une carte on utilise des registres, qui ne sont que des adresses (et on ne sait pas à priori quel registre fait quoi). Et tout le problème quand on ecrit un driver sans docs est justement d'associer une adresse à une fonctionnalité, et pas de comprendre les foncitonnalités elles-mêmes (pour comprendre ces fonctionnalités, il suffit de lire des docs sur OpenGL).
Pour comparer avec de la programmation en C, c'est un peu comme si on avait le code (les .c) et qu'on savait ce qu'il fait, mais qu'on ne connaisse pas les interfaces pour s'en servir (les .h).
< pub>
D'ailleurs, pour ceux que ca intéresse de bosser sur des drivers 3d libres, il y a une mailing list (dri-devel sur sourceforge) et un channel irc #dri-devel sur freenode.
< /pub>
[^] # Re: Bheu ?
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Shadow warrior!. Évalué à 1.
http://www.vgmuseum.com/images/01/shadoww.html(...)
http://www.zxscreens.i12.com/zxscreens/shadow_warriors.htm(...)
Ce qui était assez sympa c'est qu'il pouvait s'accrocher aux éléments du décor genre les réverbères pour faire des attaques spéciales...
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Optimiser sa Gentoo. Évalué à 2.
En fait, -ffast-math donne un comportement qui ne respecte pas le standard IEEE sur les calculs flottant, en particulier sur les nombre denormals (dénormaux ?) et infinis. Ce genre d'erreur peut se propager dans tout un calcul et même passer totalement inaperçue et mener à des résultats erronés.
Et il ne s'agit pas là d'un bug dans un programme. L'application attend un certain standard dont elle a besoin pour tourner correctement et il faut que le compilateur le respecte.
# Il faut transmettre la taille...
Posté par Stephane Marchesin (site web personnel) . En réponse au journal LZO et allocation mémoire. Évalué à 1.
[^] # Re: Grrr
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche La Commission refuse une nouvelle première lecture. Évalué à 2.
http://www.recherche.gouv.fr/campagne/brevet/brevet.htm(...)
[^] # Re: vu et revu
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Contructeur et Pilotes. Évalué à 1.
Non, j'ai une radeon 7000 de toute manière :)
Cela dit, Doom3 est lent parce que sur les radeon il est censé utiliser ATI_fragment_shader, et que cette extension n'est pas implémentée par le DRI puisque très peu de gens ont les specs de la carte. Du coup doom3 sur DRI utilise les extensions ARB de base, et ça a comme effet d'aller plus lentement, et d'avoir un rendu de moins bonne qualité.
[^] # Re: vu et revu
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Contructeur et Pilotes. Évalué à 2.
Justement, les améliorations de performance sont très récentes (elles datent d'un mois environ), et devraient être plus importantes encore sur les chips IGP. Donc tu as interêt à passer en Xorg cvs/DRI cvs/DRM cvs.
[^] # Re: vu et revu
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Contructeur et Pilotes. Évalué à 1.
Mais mais mais pas du tout !
Avec une r200 (par exemple radeon 8500, 9000, 9200) les derniers pilotes DRI (cvs) sont plus rapides pour quake 3 et Enemy Territory, les derniers pilotes ATI (8.8.25) sont plus rapides pour ut2003 :
http://marc.theaimsgroup.com/?l=dri-devel&m=110805250325559&(...)
# Et pendans ce temps là, le DRI...
Posté par Stephane Marchesin (site web personnel) . En réponse au journal lundi prochain... grande nouvelle.. Évalué à 3.
[^] # Re: La bonne voie.
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Libersciences.net : un "laboratoire virtuel" de promotion des logiciels libres pour l'enseignement des sciences.. Évalué à 1.
Cf mon commentaire ci-dessous, ils sont complètement liés à microsoft.
J'espere aussi que les enseignements à l'ULP se tourneront aussi vers le libre (je pense notement a nos enseignement de bases de données, qui s'appuient sur Oracle, alors que PosgreSQL serait tout approprié).
J'avais demandé à nos profs il y a quelques années et la raison c'est que "dans les entreprises on utilise oracle, donc on vous ensigne ça pour que ca fasse bien sur le CV".
# Mouais...
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Libersciences.net : un "laboratoire virtuel" de promotion des logiciels libres pour l'enseignement des sciences.. Évalué à 2.
http://www.microsoft.com/france/education/admin/temoignages/info/in(...)
"Faites ce que je dis, pas ce que je fais."
[^] # Re: RAID
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Intégrité des fichiers en temps réel. Évalué à 5.
La problematique, c'est que mes disques sont neuf et je dois recreer la matrice tout les 15 jours environ(lorsque la machine est assez solicité), notament sur le disque hda, mais pourtant il semble etre bon.
Je vais peut-être te décevoir, mais ça fait au moins 5 ans que tous les disques durs vendus intègrent des mécanismes de CRC. Donc ça veut dire que ce que tu confies à ton disque, il le régurgite toujours à l'octet près après avoir fait les vérifications de CRC (et si le CRC est mauvais, il fait en général un reset du disque et relit le secteur, et s'il y a vraiment un problème il fait des reset à l'infini et tu obtiens le chant du cygne caractéristique des disques durs mourrants). Ce qui veut dire que ton problème est ailleurs :
- ta ram est défaillante ( -> memtest86 :)
- problème de chipset (dû à un overclocking ou à un driver IDE buggé ou à une carte mère mourrante...).
Mais je penche plutôt pour la premiere explication.
Franchement l'époque où les disques durs étaient stupides est révolue depuis longtemps. Maintenant ils sont capables de s'auto réparer (par exemple ils ont des secteurs en rabe, et quand ils en trouvent des défectueux ils peuvent les déplacer. Mais toute l'opération est transparente même pour l'OS). On dispose d'ailleurs d'outils pour interroger les status du disque, commme par exemple le package ide-smart.
[^] # Re: DRI et Xorg
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Test des cartes NVIDIA et ATI. Évalué à 2.
- http://graphics.tomshardware.com/graphic/20020718/radeon9700-08.htm(...)
C'est dans le test de la radeon 9700, mais en fait ça décrit le fonctionnement de l'hyperz dans les radeon de type R100, sûrement que ATI ne voulait pas parler du fonctionnement sur R300.
- http://www.beyond3d.com/reviews/ati/radeon8500p2/index3.php(...) (et les pages qui suivent) qui décrit à peu près l'hyperz tel qu'il est sur les cartes de type R200.
- http://www.merl.com/hwws00/presentations/ATIHot3D.pdf(...) qui est la présentation faite au Siggraph workshop on graphics hardware de 2000. C'est plus technique et en fait c'est grâce à ce document que j'ai commencé à comprendre comment ça marchait vraiment.
Bref le dri c'est bon, mangez-en (enfin moi j'ai une radeon 7000 donc j'ai pas d'autre choix :).
[^] # Re: DRI et Xorg
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Test des cartes NVIDIA et ATI. Évalué à 4.
Oui, ce n'était pas une critique mais juste un encouragement à faire remonter les bugs report, parce qu'on en manque. A priori, tous les programmes qui ne font pas de lectures dans le z buffer (99% des jeux) devraient fonctionner correctement, d'où ma question.
La seule chose manquante c'est le support du hierarchical z sur r200 mais ça ne devrait affecter que les performances (et uniquement sur ce type de cartes) et pas la correction. Je pense que faire marcher le hierarchical z est une cause perdue, et en plus ça pose un tas de problèmes anexes (par exemple sous doom 3 il doit être desactivé pour avoir un rendu correct, et ce même avec les pilotes ati propriétaires ou sous windows).
Cela dit, on n'a pas encore épuisé les sources d'optimisations sur radeon et il reste encore de la marge (je dirais en gros une 20aine de %). Y a plus qu'à écrire le code :)
[^] # Re: DRI et Xorg
Posté par Stephane Marchesin (site web personnel) . En réponse au journal Test des cartes NVIDIA et ATI. Évalué à 4.
Hum, qu'entends tu par "ça marche encore assez moyennement" ? Tu as des problèmes avec ? Si oui, un petit bug report serait le bienvenu (les bugs report à propos des glReadPixels sur le zbuffer sont exclus :) ).