Rémi Hérilier a écrit 206 commentaires

pour s'amuser, ya viewperf ... par contre, c'est un peu plus de 400 Mo à télécharger ;)

http://www.specbench.org/gpc/downloadindex.html(...)

Ne cherche plus, Ati et Nvidia les font ;)

Les réels éléments permettant de juger des performances sont :
- le nombres de triangles lissés/texturés/éclairés/tout_en_même_temps par seconde
- le nombre de texels (texture element) par seconde

Cela permet de juger des capacités du moteur géométrique et de celles des unités de textures.

Quelqu'un d'un tant soit peu averti ne s'intéressera sans doute jamais à 3dmark ou un bench sur Doom 3. Viewperf ( http://www.specbench.org/gpc/opc.static/vp8info.html(...) ) me semble être bien plus pertinent.

De plus, pour de réelles performances, il vaut mieux se tourner vers les GPU pro d'Ati et de Nvidia (respectivement firegl et quadro) ou encore les cartes de 3dlabs. En effet, une X800 ou une FX 6800 ont des perfs qui dégringolent relativement vite quand on manipule de gros maillages (je t'accorde que ce n'est pas la même bourse;). Dans une moindre mesure, taper dans les cartes pour gros gamers suffit largement (amha) puisqu'un graphiste ne change pas, selon moi, de carte graphique tout les 6 mois.

De plus, les graphistes 3D passent 90% de leurs temps en filaire ou en ombré et ce n'est qu'en de rares occasions qu'ils activent les shaders et là, le nombre de fps n'est plus une contrainte car ce n'est que pour avoir une aperçu avec textures, éclairages et tutti quanti.

Bref, de la carte qui affiche vite et "mal", ça se trouve facilement.

Oui mais est-ce qu'ils fournissentl vraiment des pilotes ouverts?

Qui ? l'ARB énoncent des specs qui sont publiées sur http://www.opengl.org(...) et n'importe qui est libre de développer ses propres pilotes ouverts (Cf MesaGL). Si c'est de XGI dont tu parles, je n'en sais absolument rien. Il faudrait que tu retrouves tes fameuses rumeurs et chercher à partir de là.

Personnellement, je ne vois ce que la diffusion des specs des GPUs XGI va changer au développement graphique basé sur OpenGL ?!

Diviser la bande passante ? C'est en effet ce qui arrive si on utilise un simple bus comme celui du PC.

À ton avis, comment les GPUs font-elles pour optimiser leurs accès mémoire (mémoire embarquée sur la carte graphique bien sûr:) alors qu'elles ont plusieurs unités de texture qui fonctionnent en parallèle ? Elles utilisent tout simplement une architecture qui permet à n processeurs d'accéder à m modules de mémoire et cela en parallèle et de façon non bloquante. Pas mal non ? Ce système porte le joli nom de crossbar =)

Un lien assez intéressant : http://www.interex.org/hpworldnews/hpw806/hpux/02hpux.html(...)

En cherchant sur les moteurs de recherches, tu trouveras pas mal d'exemples d'utilisation du crossbar (en gros, tout ce qui est parallélisme métériel).

Pour info, la Xbox utilise un système de type crossbar. Cela explique partiellement qu'elle est plus rapide qu'un PC de configuration équivalente.

Qu'appelles-tu plans de mémoire ?!

Mark Havel me semble plutôt développer des applications OpenGL. Focaliser son dev sur les ATI/Nvidia, c'est on ne peut plus normal et cela, pour 2 raisons :

1/ ils sont (quasiment) les seuls à ajouter des extensions à OpenGL
Cf http://www.delphi3d.net/hardware/allexts.php(...)

2/ les applications OpenGL bien conçues font une truc du genre :
si extension ATI
l'utiliser
sinon
si extension NVidia
l'utiliser
sinon
si extension ARB
l'utiliser
sinon
utiliser une astuce ou renvoyer un message d'erreur

XGI, pour sa part, ne fais que suivre les specs énoncés par l'ARB (aucune extension au préfixe GL_XGI). Développer seulement avec les extensions ARB, ça marchera de partout (où c'est supporté bien sûr;) mais pourquoi défavoriser ceux qui ont une ATI ou une Nvidia ?

Donc pas de soucis à avoir : les programmes de Mark Havel marcheront surement sur une XGI. Après, tout n'est qu'une question de puissance de calcul ;)

La bande passante est en effet un énorme problème mais ce n'est pas le système graphique qui est en cause mais l'architecture du PC (je ne suis jamais allé voir dans les Macs) : ce "fichu" bus intermédiaire (agp, pci-x) entre le système central et le système graphique.

SGI (et surement d'autre) en son temps avait bien compris le problème en partageant la mémoire des stations entre système et gpu (ça devait aussi faire quelques économies:). D'ailleurs, je pense que la gpu faisait plus office de coprocesseur (comme les copro arithmétiques du temps des 386sx) que de processeur à part (comme on l'a sur PC).

Mais bon, il n'y a plus grand monde (chez les fabricant de micro info) pour concevoir une nouvelle architecture et l'imposer :-(

À part attendre les prochaines consoles et y mettre un clavier et un linux =)

Te souviens-tu de où tu avais lu ça ? Je ne trouve rien de plus récent que juillet 2003 (des posts sur le forum de gamedev.net):

/me qui croise les doigts ...

Je trouve justement que le terme de fragment convient très bien. Au delà de l'idée qu'une carte graphique ne sert qu'à faire du graphisme, elle est surtout une unité de calcul d'une puissance inégalable par un cpu.

Même en restant que dans le graphisme, les algorithmes à plusieurs passes sont de plus en plus utilisé et ce n'est souvent que la dernière passe qui peut se définir comme traitant des pixels, les autres s'occupant de champs scalaires ou vectoriels quelconques.

Quelques exemples d'applications des gpu (je sais, je parle surtout de recherche:) :
- faire du calcul vectoriel,
- simulation de fluide
- rendu basé sur le lancer de rayons (les textures servent à stocker la géométrie et une table d'index pour accélérer la recherche d'intersection).

D'autre part, avec l'arrivée du support des nombres flottants pour les buffers, on peut aisement représenter autre chose que de simple pixels. De plus, avec la possibilité qu'un shader écrive dans plusieurs buffers en une seule passe (nouveauté de cet ogl2), la sortie ne peut plus vraiment s'appeler un pixel.

Mais bon, ce n'est qu'un avis personnel et je ne sais pas quelles ont été les réelles motivations de l'ARB =)

OpenGL 2.0 est un peu decevant car juste c'est juste une compilation des differentes extensions... Pas de nouveautes revolutionnaires, donc.

Pour info, cette version d'ogl n'est que transitoire. La vrai version 2 d'ogl sera la prochaine (appelée "pure" OpenGL 2) et qui perdra toute compatibilité avec les versions d'ogl existantes.

Au programme (de mémoire car 3dlabs à supprimé les white paper de son site)):
- un refonte de l'API,
- 2 unités programmables supplémentaires (pour l'envoi et la réception de données vers et depuis ogl2),
- une généralisation du concept de buffer (Cf ce que l'on nomme super_buffer ou über_buffer selon les pages oueb),
- des primitives pour de la gestion de mémoire,
- des primitives pour jouer avec le caractère synchrone et asynchrone d'ogl2.

Pour un bref résumé de l'histoire : http://www.romulus2.com/articles/guides/opengl2/ogl1.shtml(...)

En fin de changelog, on peut lire :

<torvalds@ppc970.osdl.org>
Linux 2.6.8.1

j'ose espérer que c'est suffisant pour se dire qu'il est officiel :)

Pourquoi dépenser des sous pour protéger quelques choses et le mettre aussi sec dans le domaine public ? Tu as donc autant d'argent à gaspiller ?

publie le, partage et le cas échéant protège toi comme descrit dans ce post : http://linuxfr.org/comments/453477.html#453477(...)

Ça reviendra bien moins cher et ça ne financera pas l'OEB.

Par oreille et par platine ?! Même si c'est le rêve des majors, faut p'être pas abuser ... les cd sont en stéréo quand même :)

Pourquoi pas des cds avec 4 voix et un laser octarine que seuls les gens munis de 4 oreilles pourront écouter ? :))

C'est pour ça que je récupère la slackware-current via rsync : mises à jour régulières ET de quoi me faire un cd d'installation au cas où.

Je suppute que n'importe quelle distrib en est capable.

A ne pas confondre Inde/indien qui font référence au pays et hindouisme/hindou qui font référence à la religion.

Dixit le lien wikipédia donné plus haut, il parle bien d'indien et non d'hindou.

perso, j'appelle ça : le beurre, l'argent du beurre, la crémière, etc.

bienvenue dans cette ère de non innovation :-(

http://www.european-patent-office.org(...)

.... heu .... EPO ?! cépabien (tm) !!!!!!

je suis déjà reparti.

hein ?! du RAID sur disquettes ?!

/me -> []

Ça, ça ne s'applique malheureusement pas qu'à l'informatique :-/

/me -> []

Pour ce qui est de OCaml, je pense qu'il est bien plus employé qu'on ne peut le croire. Toutefois, il est vrai qu'il ne remplacera jamais le C++, Java ou .Net dans 90% de leurs utilisations (je ne dirais rien sur objC que je ne connais que trop peu).

Mais bon, pour les systèmes experts ou les applications distribuées, les langages orientés objet seront toujours ridicules comparés à des langages tels qu'OCaml et Erlang.

Faut juste arrêter de croire que ya que le C++, Java et .Net dans l'informatique.

je sais, je suis HS à 200% mais pitié, soyez indulgents 8}

Qui sont ces grands groupes (en informatique bien sûr) ? Microsoft France, Sun France, HP France ? À part les sociétés françaises qui font de l'embarqué, je ne vois pas trop ... les SSII à la rigueur ? si quelqu'un peu m'éclairer ...

Ce qui est bizarre, ........ qu'à freiner l'innovation.

C'est bien là le problème, la théorie est bonne mais la pratique est toujours catastrophique :/

quelles extensions ARB ? GL_ARB_frament_program et GL_ARB_vertex_program ? Oui, celle-là existent déjà mais c'est de l'assembleur ... rien à voir avec le langage à la C qu'est GLSL et qu'apportent, entre autre, les (nouvelles) extentions ARB suivantes : GL_ARB_framgment_shader, GL_ARB_vertex_shader et GL_ARB_shading_language_100.

De toute façon, il n'y pas vraiment de hard grand public (à vérifier pour la FX6800 et la X800) qui supportent réellement les spécifications de ce langage (entre autre pas d'embranchement possible ... adieu les if() {} else {} bien complexes).

Mais bon, je souhaite aux ATIstes de pouvoir prochainement, eux aussi, doper à GLSL notre manchot préféré :)

Ce n'est pas que je m'ennuie mais je vais aller coder un peu =)

peut-être parce que le '1' signifie "utiliser le support AGP de Nvidia à la place d'AGPGART". Ce qui sous-entendrait que, dans le cas de vesafb, le driver de Nvidia marche mal (un bug quoi:) avec AGPGART :/

Est-ce moi où le lien pour le changelog mène à celui de la série des 9.x ? En effet, en suivant ce lien, on ne trouve aucunes occurrences de Gnome 2.6.x, KDE 3.2.x, Linux 2.6.x ou encore de X.org.

Le changelog de la slackware 10.0 serait donc plutôt ici : ftp://ftp.slackware.com/pub/slackware-current/ChangeLog.txt(...)

Par contre, c'est toujours bien encombré =)

Personnellement, je trouve regrettable que les maiteneurs de la distribution que tu utilises aient déplacées les polices de caractères vers un autre répertoire.

Sous Slackware, Patrick Volkerding a conservé pour X.org la même arborescence que celle de XFree86. Pi bon, je ne vois pas quel intérêt il y a à la modiffier.

Pour ce qui est des chemins pour les polices de caractères, dans xorg.conf section Files, tu peux utiliser le paramètre FontPath (un coup de vi ou d'emacs et c'est réglé). C'est vrai que si tu passes par une interface graphique, ça peut être plus contraignant. De toute façon, on ne passe de XFree86 à X.org qu'une seule fois =)

Pour les pilotes NVidia, et comme dit plus haut, tu vas être obligé de recomplier ton noyau ...

Il n'est pas question que ces accès soient transparents au niveau de l'application mais au niveau du "système". Il y a une grosse différence. De plus ton bel exemple ne sert pas à grand chose sur un serveur de fichier.

C'est sûr que l'utilisateur lambda se moquera de the Hurd comme de sa première paire de chausettes : ce qu'il a lui suffit. Mais un admin y verra sans doute une différence flagrante qui le fera passer à the Hurd.

Linux ou the Hurd ? l'avenir nous le dira ...

De toute façon, ce dont j'ai besoin, c'est d'un environnement GNU.