Stephane Marchesin a écrit 254 commentaires

Le DRI a son cvs sur freedesktop.org depuis longtemps. Le DRI est donc bien entendu compatible X.org (d'ailleurs il tendrait plutôt à avoir des problèmes avec XFree86 ces derniers temps).

Sinon la page de sourceforge (dri.sf.net) va prochainement être migrée sur http://dri.freedesktop.org/(...) d'où la présence d'une page vide.

j'ai remarqué déjà depuis un moment qu'à chaque fois, SDL ne prend pas en compte certaines touches des claviers français configuré avec le kbmap "fr" par X,

C'est faux, SDL gère très bien ces touches. Simplement, si l'application n'a pas été prévue pour supporter des claviers internationaux eh bien ça ne risque pas de marcher.

De plus rares sont les programmes qui permettent de modifier le mapping par défaut. Alors ma question est la suivante, comment demander à SDL d'utiliser correctement les touches, et est-ce faisable au moins ?

Il faut le demander aux auteurs des logiciels que tu utilises. Parfois ajouter un simple SDL_EnableUNICODE() peut faire des miracles.

Ben pas forcément, ils ont engagé une personne (Michel Daenzer pour ne pas le nommer) qui bossait sur les drivers libres (dri) avant. Je suppose qu'ils ont embauché d'autres personnes d'après leur annonce. En tout cas cette personne est très compétente sur le sujet.

Une chose est sûre, c'est que ca ne fait pas du tout suite à la pétition. Ça s'est fait bien avant.

Bon, moi comme cartes ATI j'ai une mach64 et une radeon 7000, donc vous me raconterez si les drivers proprio s'améliorent parce que ça ne me concernera pas ;)

Bon je ne trouve pas que tes preuves soient des vraies preuves. Je sais je pinaille un peu mais :
% strings /bin/tar |sort -u >tar-strings.txt
% strings /bin/bash |sort -u >bash-strings.txt
% cat tar-strings.txt bash-strings.txt | sort | uniq -d |wc -l
137

Tout ça ne veut pas dire que tar est une copie de bash.

Attention, je ne mets pas en doute le fait qu'ils aient pris des softs libres (d'autant plus que aviplay est surement le player de http://avifile.sf.net(...)) mais je trouve juste que tes preuves ne sont pas tangibles.

Impossible. Les 9600 sont des rv350, qui ne sont pas supportés pas les drivers 3D libres.
Alors soit :
- tu utilises un autre OpenGL comme mesa soft (mais à 2746 fps dans glxgears je pense pas) ou les drivers ATI (mais je ne vois pas comment ils se seraient installés à l'insu de ton plein gré). Un coup de glxinfo te dira quels drivers tu utilises.
- tu as une firegl 9000 et pas 9600 (un coup de lspci répondra à cette question)
- tu es un mythomane (mais sur linuxfr ca ne s'est jamais vu :)

C'est pas évident, tant sur le plan technique que sur le plan légal :

- le driver OpenGL windows pour les radeon premières du nom, une fois desassemblé, fait 2,5 millions de lignes. Ça fait beaucoup, même quand tu sais ce que tu cherches.

- selon les pays, tu n'as pas le droit de désassembler un driver (même si c'est pour en écrire un autre). Du coup si tu contribues des patches obtenus de cette manière à un driver libre tu peux leur causer des problèmes (ça peut rendre tout le projet illégal).

- sinon en France je crois qu'on a une loi qui autorise le reverse engineering pour des motifs d'interoperabilité. Maintenant va savoir comment ça se passe en droit international. Est-ce que le driver obtenu a le droit d'être exporté ? Est-ce que tu peux envoyer des patches à un projet hébergé dans un autre pays aux lois différentes ?

- on pourrait par exemple avoir le support du S3TC (compression de texture) dans les drivers libres. Le patch existe, mais la technique est brevetée, et donc le patch ne peut pas être intégré dans les drivers libres :
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index(...)

Une bonne idée de pétition serait de demander à VIA (détenteur actuel du brevet) d'accorder le droit d'utiliser le S3TC dans les logiciels libres, par exemple. Ou de demander des specs sur des points précis (hyper-z pour les radeon). Mais demander les specs jusqu'aux radeon 9800, ça me paraît beaucoup.

Juste une remarque sur le point 7 :

7.) "How about providing the information necessary for the DRI project to make their own drivers for your hardware?"

For older generation hardware, they have all the information that is needed. As you are all aware, 3D Video card technology is being enhanced at a furious pace, hence ATI cannot give away information that will potentially benefit our competitors.

Of the companies that provide a proprietary driver, the Open Source drivers for ATI's cards are the most fully featured. This is primarily due to the openness of ATI to registered developers who wish to develop for ATI's hardware.

Les développeurs du dri n'ont pas accès à toutes les specs (et pourtant il faut être sous NDA pour avoir ces specs) : le hyper-z (qui permet en moyenne des gains de 20 à 30% de performances) est absent de ces specs. Et ce même pour les radeon première génération (radeon ddr/sdr, 7000, 7200, 7500 et M6).

Donc pour ATI "all the information that is needed" ça veut dire juste de quoi faire un driver, mais pas avoir les performances.

Un journal ne sera pas nécessaire, ça vient d'arriver. Les beaux graphiques sont là :
http://www.nixnuts.net/benchmarks/040815/(...)

Le score de glxgears, ce n'est pas vraiment pertinent comme mesure de performances :
- il n'y a pas de textures
- il y a très peu de sommets
- du coup la carte passe la plupart de son temps à effacer les buffers

Voila un petit bench interessant, remarque comme les perfs de glxgears ne sont pas proportionnelles aux perfs dans les jeux :
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg1838(...)

Sinon, pour que ça bouge il y a une solution, aider les gens du dri, ça manque cruellement de monde il y a finalement très peu de contributeurs solides.

A ma connaissance il n'y a que matrox qui file les specs, (en plus ce sont des canadiens, donc, l'argent ne servira pas a financer la guerre en Irak).

Hmm, rapelle moi d'où ils sont ATI ? ;)
(oui, ATI c'est canadien)

Tu trouveras plein de jeux old school sur la page des jeux utilisant SDL :
http://www.libsdl.org/games.php(...)

Jette aussi un coup d'oeil à la "linux game list" :
http://icculus.org/lgfaq/gamelist.php(...)

non mais utiliser subl me fait gagner 17 % en temps....
Problème de scheduling. Bienvenue dans la magie de l'execution out of order :)
Essaye de bouger un peu le dec entre les instructions flottantes.

j'ai fait le test avec 256 et c'est les meme resultat qu'avec 128. La taille des vecteurs varie entre 1 et 1500. Dans un meme calcul, il peut y avoir des vecteur de toute taille.
Ah, mais 1500 c'est tout petit !

Essaye d'insérer des prefetch à intervalle de 64 avant la boucle :

prefetchtnta (...)
prefetchtnta 64(...)

Bien sûr, ne dépasse pas l'endroit où tu préfetches dans la boucle (ne mets pas un 128 si il y en a deja un dans la boucle, quoi).

"subl $1, %1\n\t"

et dec c'est pour les chiens ? ;)



"prefetcht2 -128(%3, %1, 8)\n\t"

"prefetcht2 -128(%2, %1, 8)\n\t"


Tu devrais essayer avec prefetchnta plutôt que prefetcht2

Essaye aussi un prefetch à une distance de 256, ca peut être plus rapide (tu ne donnes pas la taille moyenne de tes vecteurs).

Essaye aussi d'aller dans le sens incrémental pour parcourir ton vecteur (les chipsets sont capables de faire des prefetchs hardware uniquement dans ce sens).

Aligne ta mémoire (man memalign).

Sinon, vu comme ta boule de calcul est courte, je pense que quasiment tous les gains se feront sur les accès mémoire.

Moi je suis contre à la suite d'un problème perso avec ça.

Je bosse sur quelques projets sur sourceforge, et ils utilisent des RBL. Eh bien il y a quelque chose comme deux mois, ils ont blacklisté les serveurs smtp de wanadoo.fr (oui oui). La raison invoquée par les gens de SF était que ces serveurs avaient relayé des spams. Le résultat est que pendant un mois je n'ai pu poster sur aucune mailing list hébergée par sourceforge (comme tous les autres wanadiens d'ailleurs).

Et comme ils sont très têtus chez sourceforge, ils voulaient pas enlever leur blacklist et m'ont répondu un truc comme "contactez wanadoo, dites leur de nous contacter (sourceforge) quand ils auront mis en place des filtres anti spam". Et comme chez wanadoo ils répondent pas aux clients (en même temps tout seul c'est pas évident de demander à wanadoo d'installer des filtres anti spam sur ses serveurs de mail), ben j'étais bloqué (les gens de SF m'ont entre autres suggéré que je pouvais changer de fournisseur d'accès et que ça résoudrait mon problème. super on sent les gens très compétents).

Finalement au bout d'un mois ça s'est remis à marcher j'ai pas cherché à comprendre comment. Mais si tu vas sur la partie "demande d'aide" de sourceforge, tu trouveras toujours des gens se plaignant des RBL et venant de divers fournisseurs d'accès (ce sont les gens qui reçoivent une erreur 550).

2.6.4-mm
D'oh autant pour moi tu pointes le 2.6.4-ck. Je devrais regarder la tronche des liens avant de cliquer, j'ai cru à un 2.6.4-mm

Bon pour etre clair on parle de deux choses :
- les -mm qui n'ont pas SCHED_ISO mais un bel ordonnanceur tout neuf
- les -ck qui apportent SCHED_ISO et je crois pas grand chose (rien ?) pour l'ordonnanceur

Ah, je croyais que tu l'avais trouvé. En fait je sais pas où ca en est exactement, mais l'ordonnaceur de -mm est basé sur des bouts de celui de nick piggin qui est là :
http://www.kerneltrap.org/~npiggin/v19a/broken-out/sched-policy.pat(...)

Staircase c'est pas un hack "a la va vite" mais un changement en profondeur de sched.c (d'ailleur il est domage que sous linux on ne puisse pas avoir proprement plusieurs ordonanceurs à la FreeBSD par exemple, mais je peux encore ne pas avoir suivit les tout dernier developements). Il remet en cause pas mal de principes apportés par le patch de molnar.
Non non loin de moi l'idée que c'est un hack, j'ai juste dit que c'était pas fini :)

si tu regardes le patch pour le SCHED_ISO tu verras de quoi je parles :-)

Hehe... je me suis posé des questions, parce que j'ai greppé et j'ai rien trouvé. Mais en fait, dans le 2.6.6-mm4 ça n'y est plus. Et effectivement, en regardant le lien que tu pointes, le 2.6.4-mm, ça y est.

Sur la page de ck :
Isochronous scheduling?
Isochronous scheduling (or guaranteed time scheduling) is an alternative to real time scheduling that can be used without root privileges. SCHED_ISO tasks do not "expire" in the scheduler, guaranteeing relatively low latency even if they are fully cpu bound. This is good for cpu intensive tasks that would not normally be seen as interactive. It is useful for gaming, video capture, video playback at limits of performance, audio sampling etc. You can also set a task as SCHED_ISO using the schedtools utility. eg: ' schedtool -I -e "streamer ..." ' will start the video capture application streamer as ISO. Alternatively if you start an application that tries to get real time scheduling (like xmms) but you do not have root privileges, it will automatically be made SCHED_ISO.

C'est juste pour dire que c'est censé faire exactement ce qu'on en attend.

J'ai bien compris le principe du SCHED_ISO par contre je ne suis pas sur de voir toutes les implications dans le monde réel du deadline--. Faudra que j'y reflechisse un peu ! Mais il semble que ce soit la réponse élégante à la question. Faut juste que j'arrive a jauger jusqu'à quel point la réponse est pertinante par rapport à la question.

deadline-- ? Je vois pas de quoi tu parles.

Sinon, à en juger par la partie qu j'ai mise en gras, ça répond à la question.

Je suis pas du tout les noyaux -mm en ce moment. Hormis sched domains qui n'a rien a voir avec la tambouille tu peux me dire ce qu'il y d'interessant dans la tambouille ? Je viens de matter le patch-series du 2.6.6-mm4 et j'ai rien pu trouver avec un nom qui semble interessant.

Je skip, tu y as répondu.

Dans le cas du 2.6 tu as en effet raison je viens de re-matter rapidos les sources.
Avec des nices a 0 et 19 et des taches bouffeuses de CPU un peu facilement prédire que les deux taches ne seront pas classées interactives. Donc ne seront jamais remise dans la queue courante. Vu qu'au minimum MIN_TIMESLICE est attribué a chaque tache lors de sa mise dans la seconde queue en effet les deux tâches s'executerons. Tiens c'est bizarre je suis paresseux aujourd'hui je te laisse faire le calcul grosso modo des timeslice allouées aux deux process :-)

A la louche, deux cpu hogs dont l'un est à nice 20 et l'autre à 0 se partagent le cpu à un ratio de 1 vs 20 (les slices max et min). Le problème, c'est que celui qui est à 0 tourne plus et donc est pénalisé. Donc c'est un peu plus que 1/21 pour celui qui est à nice 20. 1 pour 10 ?

Autrement en relisant le code je n'ai pas pu trouver de tracer de SCHED_BATCH qui me semble pourtant bien avoir existé. ie une classe d'ordonnancement ou les taches recoivent des timeslice de l'ordre de 10 * MAX_TIMESLICE mais ne peuvent préempter aucune autre tache et un simple round robin est fait entre les tâches. J'ai revé ou 1/ je devrais me raffraichir la mémoire 2/ ca a été viré depuis les premiers patchs ? Je me souviens même du .c donné par molnar pour passer une tache en SCHED_BATCH.

Skip, tu as répondu.
Sinon, SCHED_BATCH ça se trouve en général dans les systèmes de calcul hautes performances ou l'ordonnancement est statique (fait par un système qui fait l'association 1 process <-> 1 cpu). Les memes systèmes tournent d'ailleurs avec HZ=20, en général.

Pour ton log :
Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs;

C'est une affirmation correcte mais pas complete. Tout les ordos generalistes que je connais (regarde decay par exemple, 2.4 en est une adaptation) punissent toujours les taches consomatrices de CPU donc a priori non interactives. Ce qui serait interessant c'est de voir exactement la différent au niveau de la punission et de la répartition de chaque ordonnancement selon les ordonanceurs.

C'est vrai que ce n'est pas très précis. Mais l'idée est là : sur un 2.6, les taches qui mangent 100% de cpu peuvent se faire méchamment préempter à cause du système de sleep_avg spécifique aux 2.6 qui veut que si tu ne dors pas assez, tu es moins prioritaire.

La solution simple est toujours de passer la tache en temps réel (SCHED_FIFO/SCHED_RR) et la tu es sur qu'elle ne se fera pas massacrer par les autres autre mais toujours au risque de perdre la machine si le jeux se vautre.

C'est encore pire : tourner une appli non temps réel avec un scheduler temps réel relève de la folie. Si tu lis le log, en fait le gars a planté sa machine parce que son jeu prenait 100% de cpu et Xfree n'avait plus rien, ce qui l'a forcé à s-u-b (d'ailleurs après, il était faché, il parlait en gras, mais ca ne se voit pas dans le log :)

Bon si j'ai du temps a perdre je ferais des stats tiens

Euh.. des stats de quoi ?

Heu tu es au courant *tout* ordonnanceur pénalise certaines taches et en favorisent d'autre ? Ca tombe bien puisque c'est son job. L'ordo du 2.6 n'apporte rien de nouveau de ce côté grosso modo on regarde qui bouffe du CPU et on le puni pour favorisé les autres taches (je vais pas expliquer le pourquoi du comment ici).

Euh, tu es sur d'avoir suivi le développement du 2.6 ? On t'a dit que le scheduler a changé quasiment du tout au tout entre 2.4 et 2.6 ? Si tu as suivi ces discussions, tu te rapelleras la discussion sur XFree qui laggait plus avec le 2.5.X qu'avec les 2.4, et le fait que c'était lié aux modifs du scheduler, et le fait que le pauvre linus ne pouvait pas voir de différence sur son quadri proc :
http://kerneltrap.org/node/view/603/2629(...)

Le seul ordonnanceurs expérimentale qui existe et qui fonctionne a peu près a ma connaissance est staircase de ck. Pour l'avoir fait tourné pendant un mois il est pas au point (jolie famine par moment, et freeze de machine pour 1..10 secondes dans des cas pathologiques reproductible).

Bah, en meme temps, le staircase est loin d'etre fini. Et des schedulers experimentaux, il y en a des plus connus que celui-là. Essaye déjà les noyaux -mm.

La solution ? Apprendre a se servir des primitives POSIX concernant l'ordonnancement ! Bin oui le bon vieux nice

nice A
nice +20 B

B ne passera *jamais* devant A par exemple.

Ca dépend ce que tu apelles "passer devant A". Si A et B sont tous les 2 des cpu hogs, chacun aura une part du CPU. Certes, B sera fortement défavorisé mais tournera quand meme un peu. Le fait meme que B obtienne une part du cpu veut dire que A (qui tourne pourtant à 100% de cpu tout le temps) a été préempté pour laisser passer B devant A.

Le nice n'influe pas sur ce problème, si tu avais essayé cette solution tu le saurais. D'ailleurs ça a été discuté avant hier à la réunion irc hebdomadaire du dri :
http://dri.sourceforge.net/IRC-logs/20040517.txt(...)
Où une personne a exactement ce problème, meme à un nice -19.

Sous les noyaux 2.6, l'ordonnanceur "punit" les processus trop gourmands en cpu (ceux qui tournent à 100% tout le temps) en donnant la main de préférence aux autres.

Du coup, solarwolf est pénalisé et lagge dès qu'il y a autre chose qui veut tourner. Par contre, chromium qui ne tourne pas à 100% de cpu n'a pas ce problème.

Que faire ? Changer d'ordonnanceur :
- repasser au 2.4 (eh oui pour les jeux c'est pas plus mal)
- patcher ton noyau 2.6. Le patch isochronous de Con Kolivas est ce que tu cherches, mais il nécessite de lancer les programmes avec des utilitaires user space
- essayer d'autres ordonnanceurs "experimentaux". Pareil il faudra patcher ton noyau. Je n'ai pas de patch en particulier qui me vient à l'esprit, là maintenant. Peut-etre que le noyau multimedia de mandrake intègre de tels patchs.

Je pense qu'il fait référence au fait que microsoft apparaît dans les sponsors sur le site de la présidence irlandaise du parlement européen :
http://www.eu2004.ie/sitetools/sponsorship.asp(...)

Non, il a raison, le backend x11 de SDL n'est pas capable de créer une surface "hardware". Ce n'est pas une limitation de x11 mais une limitation de SDL (en fait, pour rester portable on n'a pas trop le choix - il faut utiliser x11 de base et pas les extensions qui vont bien). Pour les perfs, il existe d'auter backends comme dga, directfb...

let screen = Sdlvideo.set_video_mode ~w ~h ~bpp [] in
(* pas de HWSURFACE, ça sert à rien avec le pilote x11 *)

Si on considère que SDL se place dans une optique de portabilité, c'est mal de dire "ça ne marche pas chez moi, donc les autres n'en profiteront pas non plus". D'autant plus que d'autres backends sous linux supportent les surfaces h/w comme directfb, dga ou (celui qui-va-tout-dépoter-quand-il-sera-fini) le futur glSDL.

Pour choisir d'utiliser ou non le flag HWSURFACE il faut considérer la manière dont ton application accède ) la surface vidéo le plus souvent (c'est-à-dire est-ce qu'elle accède directement à ses pixels, ou est-ce qu'elle y accède par l'intermédiaire de blits).

Sdlvideo.update_rect screen ;
(* ou flip, c'est pareil *)

Pas exactement, flip c'est quand on utilise un double buffer uniquement.

Sinon, je pense que la raison pour laquelle le programme original ne marche pas, c'est qu'il fait flip sur une surface video qui nest pas un double buffer. Donc il faudrait initialiser en demandant un double buffer. Ce qui donne en utilisant mes connaisssances très lointaines en caml :
let screen = Sdlvideo.set_video_mode ~w:w ~h:h ~bpp:bpp [`DOUBLEBUF];;
(en rajoutant aussi le flag HWSURFACE si c'est nécessaire, mais je n'irai pas jusqu'à retrouver le ou en caml)

Certes oui (pour l'heure c'est surement vrai, pour la date deja la taille peut varier), mais il ne faut pas oublier que le noyau sous sa forme bzImage est compréssé. Donc une fois la compression passée, il y a des chances que des noyaux différents soient compressés dans des fichiers de tailles différentes.