Aller au contenu

tuXXX

Ancien
 Afficher le profil  Afficher son activité

  • Compteur de contenus

    6 836

  • Inscription

  • Dernière visite

 Type de contenu 

Messages posté(e)s par tuXXX

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    - tuner TV dans un portable. :D . C'est pas pour ceux qui veulent un ordi cette bête , c'est pour ceux qui veulent une télé de voyage.

    Moi j'en ai un, sur un portable pas trop mobile (15"4) c'est pratique :keskidit:

    C'est pas vraiment pour utiliser pendant les déplacements, plutôt une fois rentré chez soi, pour un desktop replacement quoi.

    (Enfin là c'est un 17" donc c'est encore plus vrai, puisque c'est vraiment plus un transportable à cette taille)

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    :keskidit:

    bc -l
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
2^32 / 10^9
4.29496729600000000000

    Ça vient d'où ces 3Go ?

    Ben peut-être que windows garde un bout de la mémoire adressable pour le kernel (un peu comme sous linux avec plus de 1Go de RAM sans le HIGHMEM 4G), soit la carte mère n'accepte pas plus, ce qui est possible aussi.

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Sur les OS libres, on se rend compte que la version 64 bits des bibliothèques ne permet pas de faire fonctionner des logiciels 32 bits. Et les bibliothèques 32 bits ne peuvent pas s'installer dans un environnement 64 bits ( problème des dépendances ). Evènement qui peut être réglé au cas par cas, mais évènement non conforme à la description du x86_64 réalisée par AMD.

    Notez que cela concerne uniquement les logiciels non libres comme Opera dont la version 32 bits ne s'installe pas dans un environnement full 64 bits ( sauf à poser le binaire portable dans un répertoire ou à chrooter un environnement 32 bits )...

    À priori le multilib résout ça. Bon par contre je connais que gentoo qui supporte ça, mais bref, c'est pas un problème technique quoi.

    ( http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#multilib )

    plus légère, vraissemblablement une debian ou une slackware, à la limite une dsl. Presque toutes les distrib proposent gnome maintenant.

    Aux dernières nouvelles, le créateur de Slackware a viré Gnome pour ne garder que KDE comme bureau, parce qu'il utilise KDE et que gérer à la fois KDE et Gnome c'est trop de paquets pour lui.

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Je crois que les drivers libres ne supportent pas les r600 (radeons X1xxx et X2xxx) (donc toutes les cartes depuis octobre 2005).

    Par contre, ça m'étonne que tu ne puisses faire que 2048x1536... normalement, en 2D, le driver est censé supporter 8192x8192 de surface pour les "virtual"... après, c'est peut-être le BIOS ou la puissance de la carte qui limite...

    Je ne parle pas de la taille virtuelle (qui effectivement peut être très grosse puisque gérée par X directement), mais de la résolution réelle que la carte peut afficher (sur une/chaque sortie).

    Même aujourd'hui y'a pas beaucoup d'écrans qui peuvent faire du 2048x1536, et sur une radeon 7000/VE, qui est presque le truc le plus bas de gamme possible, c'est déjà très bien.

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Pour la copilation il n'y a aucun problème : tout ce qui est compilé avec le noyau est libre avec le driver nvidia : il y a un .c qui fait le wrapper entre la partie binaire et la partie module noyau, et on a le code source, donc par rapport à ça la GPL est respectée.

    Ce qu'il y a après, c'est le concept de "derived work", et là c'est très contreversé. Par exemple pour Linus, quelque chose comme le driver binaire nvidia n'est pas un "derived work", et donc ne pose pas de problème par rapport à la GPLv2 :

    http://lkml.org/lkml/2007/6/15/284

    http://kerneltrap.org/node/1735

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Je relis le texte extrait de la doc ubntubntu; pour eux, explicitement, ce n'est pas uniquement quand xorg dépasse les 10% d'occupation CPU, mais aussi quand glxgears le fait... la phrase est claire... et tu es le premier à être d'accord (cf ma quote de ton post juste au-dessus)... je ne vois pas ce que tu me reproches sur ce point... où as-tu vu que c'était X.org qui me bouffait 90% de CPU?

    Ce pourquoi, d'ailleurs, j'estime qu'il renvoie n'importe quoi, c'est justement que ces chiffres n'ont pas une grande signification, et que se baser uniquement sur eux est extrêmement douteux... rien de plus, rien de moins...

    C'est un wiki, pas une documentation officielle, donc pas à prendre comme une quelconque vérité absolue. Et ils parlent quand même plusieurs fois de glxgears qui n'est pas un benchmark, etc... Donc c'est pas si mal que ça quand même.

    Pour le nombre de FPS qui est "n'importe quoi", pour moi c'est leur interprétation qui peut être n'importe quoi, les chiffres eux-même sont juste un fait.

    J'ai conspué une doc qui raconte, je persiste et signe, des inepties. Je n'ai fait passé personne pour un idiot. Ca me choque juste que le wiki d'une distro raconte des choses pareilles... surtout quand les gens finissent par les croire et par considérer les bonnes méthodes comme mauvaises...

    Ce site n'a de rapport avec ubuntu que de nom, la vrai documentation concernant l'accélération 3D sur ubuntu c'est : http://doc.ubuntu.com/ubuntu/desktopguide/C/hardware.html .

    ... que ça ne te plaise pas, c'est une chose... mais je ne vois pas en quoi j'ai manqué de respect à qui que ce soit en taxant, à raison, un (et même des, c'est vrai) propos d'ineptie(s)... j'aurais dit que le gars qui a écrit ça était un con, soit, j'aurais abusé, mais permet-moi justement espérer ne pas être assez con pour en arriver là...

    Ben tu dis que ce qui est marqué est stupide, c'est vraiment pas loin. Tu pouvais pas simplement dire que tu n'étais pas d'accord?

    là, je n'ai manqué de respect (à la limite, d'un peu de déférence, ce à quoi le respect ne se limite, heureusement, pas... comme j'ai pu le vérifier, avec soulagement) à aucune personne... on dit tous des conneries, moi le premier... ça ne fait pas de nous, définitivement, ni même vraiment ponctuellement, des cons...

    Ça dépend comment c'est dit.

    Quant à l'illégalité évoquée par Lorinc, j'imagine qu'il ne parlait pas bien sûr d'un hypothétique fait de devoir utiliser DRI... je le prends comme une allusion au caractère violateur de la GPL des drivers proprios, travaux dérivés du kernel, s'il en est, sous une licence incompatible avec lui... ils ne sont rien de plus que tolérés, ce qui ne les rend pas légaux pour autant.

    Ceci est quelque chose dont on ne peut à mon avis pas déterminer pour l'instant de vérité formelle, le concept de "travail dérivé" étant une définition très floue.

    Pour certains, prendre un driver qui marche sur plein d'OS et le faire marcher sur le noyau linux n'est pas un travail dérivé (Linus par exemple).

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    La seule chose que j'ai à dire là-dessus :
    vous voyez glxgears ou Xorg en tête des processus avec plus de 10% d'utilisation du temps processeur, c'est que vous n'avez pas d'accélération 3D matérielle

    ... c'est : "mais n'importe quoi!!!" :ouioui:

    J'ai déjà vu glxgears me pondre un 90% d'utilisation proc sur un X2 ou un C2D, alors que la carte fonctionnait parfaitement fluidement avec UT2003, sans mettre le proc à genoux (glxgears était fluide aussi, note bien... juste qu'il me plombait le CPU va savoir pourquoi)...

    Tu cites : on parle de Xorg qui prend plus de 10%, ce qui signifie qu'il fait quelque chose au niveau de la 3D, et donc que c'est de la 3D logicielle, toi tu parles de l'utilisation totale, ce qui n'a rien à voir. (Si tu parles réellement d'utilisation X à 90% sur un ordinateur qui fait tourner UT2003 fluidement, je veux bien voir)

    Ensuite tu dis qu'un PC capable de faire tourner UT2003 sans problème (donc avec l'accélération 3D matérielle) utilise 90% de CPU sur un processeur dual-core... Alors de 2 choses l'une : soit tu utilises un dual-core avec un noyau non-SMP, et dans ce cas là tu utilise ton dual-core comme un simple processeur de base. Soit tu dis quelque chose qui n'est pas possible puisque glxgears ne peux pas utiliser plus d'un seul processeur (étant mono-processus), et donc pas plus de 50% CPU sur un dual-core.

    glxgears n'est absolument pas, mais alors, absolument pas, optimisé pour quoi que ce soit...

    glxgears n'est pas sensé être "optimisé", c'est une application qui permet juste de tester glx en faisant tourner 3 roues en OpenGL...

    et en général, il renvoie n'importe quoi en fps

    Il ne renvoie pas n'importe quoi, il affiche juste le nombre d'images qu'il peut afficher par seconde. Ça dépend de plusieurs paramètres et n'est pas du tout représentatif d'un quelconque jeu vidéo ou autre application, mais c'est pas "n'importe quoi".

    Si tu pars de glxgears, que tu augmente la résolution en 1280x1024, ajoute de la texture, quelques polygones, et tu as un jeu vidéo.

    Quelques shaders en plus et tu as un jeu vidéo récent.

    Pour moi, glxgears n'est pas si loin que ça d'un jeu vidéo, fonctionnellement, et n'affiche pas un nombre de fps aléatoire. Après effectivement, le fait qu'il soit simpliste n'en fait pas un bon benchmark, mais c'est une autre histoire.

    et utilise le proc n'importe comment...

    C'est un programme très simple qui (comme la plupart des jeux vidéos), contient une boucle du style :

    while(true) { drawWheels(); }

    Donc ça utilise le CPU au maximum, et c'est fait exprès.

    c'est d'ailleurs ce dernier point qui l'empêche en premier lieu d'être considérable comme un benchmark... il peut tellement tirer des resources bizarrement qu'on ne peut pas décemment classer les résultats qu'il renvoie, pas plus qu'il n'est optimisé que pour tirer sur le GPU en touchant le moins possible au CPU...

    Non pour ça il faudrait balancer des shaders 3.0 + FSAA + Aniso sur des modèles 3D à plusieurs millions de polygones avec des textures multicouches de très grosse taille.

    Non, glxgears n'est pas un benchmark, et personne n'a dit ça.

    La méthode de regarder le "direct rendering = " dans le glxinfo n'est pas bonne non plus puisqu'on peut avoir de l'indirect rendering accéléré.

    ... après, la création d'un benchmark 3D libre, pertinent, et efficace serait une très bonne idée... malheureusement, il n'y en a pas vraiment... mais ce serait bien: ça éviterait d'avoir à se traîner cette cochonnerie de glxgears, complètement sous acides, que tellement de gens utilisent n'importe comment (en partant du postulat qu'il est utilisable pour quelque chose de précis)...

    En général, les gens veulent faire marcher une certaine application, sinon ils ne se soucient pas de la 3D. glxgears est parfois un bon outil de diagnostic. Personnellement, je n'ai jamais dit que glxgears était précis. Et de toute façon, quelqu'un qui utiliserait mal un outil comme glxgears aurait un problème tôt ou tard, donc ça n'est pas trop grave.

    Pour faire des benchmarks il y a de nombreux jeux libres (OpenArena, Nexuiz, Warsow, ...) qui font très bien l'affaire. Les joueurs le savent bien, les sites de tests informatiques le savent bien (phoronix par exemple).

    mais ça évite de finir par écrire des inepties comme :
    vous voyez glxgears ou Xorg en tête des processus avec plus de 10% d'utilisation du temps processeur, c'est que vous n'avez pas d'accélération 3D matérielle

    ... et ça, ça n'a pas de prix...

    Tu peux ne pas être d'accord, mais essayer de faire passer quelqu'un pour un idiot, 2 fois de suite, c'est totalement inacceptable pour moi. Le respect est à mon avis quelque chose de primordial.

    sinon ça arrive avec plein de blobs dégueux (plein, j'exagère) de ne pas avoir l'extension Xfree86-DRI, ça ne les empêche pas de faire fonctionner en hard un paquet de chose (illégalement).

    Aucune loi ne dit "Xfree86-DRI est obligatoire pour pouvoir accélérer des applications". Donc ce n'est pas "illégal"!

    Les différents drivers proprio utilisent leur propre chemin dans le driver, sans utiliser dri, et ça ne pose aucun problème juridique (au contraire, utiliser DRI avec des drivers non-libre, je ne sais pas si c'est autorisé par la license).

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Petites question en passant. Actuellement je suis sur Debian mais j'en ai marre que ce soit je ne sais trop qui qui décide quel paquets je peux ou non installer facilement avec aptitude.

    J'ai pensé à Gentoo : sur cette distrib, comment se passe la décision d'ajouter, ou non, un pacquage à la distribution ?

    Ben globalement, tu peux déjà installer tout ce qui est dans l'arbre portage de base de la distribution, ça ok.

    Et après on peut ajouter des "overlays" qui rajoutent des paquets supplémentaires, ces overlays soit tu utilise un outil layman (overlay manager) pour les récupérer, soit tu les prend directement toi-même sur des sites internet, soit fais ton propre overlay en copiant individuellement les paquets qui te plaisent.

    Au final c'est vraiment très permissif, ce qui je pense donne une bonne liberté (l'utilisateur fait ce qu'il veut)

×
×
  • Créer...