Comment est-il possible de connaître les caractéristiques de la carte
graphique d'une machine ?
Lspci liste les cartes mais sans détailler le matériel (pas son rôle,
sans doute). j'ai regardé dans /proc mais je n'y ai pas vu de rubrique
gpuinfo ; j'ai aussi cherché dans /etc/udev sans rien trouver de
pertinent. Il y a peut-être une option de X qui répondrait à ma question ?
Ça a l'air d'être complètement n'importe quoi, cette page. D'ailleurs, ce n'est pas la seule dans cette section.
Le profil du mec qui a édité la page laisse entendre qu'il est connu comme le clown de service, donc la page est peut-être un délire...
-- Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs ????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais oublié , y'a du Farce Télécom derrière, ca doit être ça ... -+- PP in: <http://www.le-gnu.net> - Tout, faut tout modérer -+-
Nicolas George <nicolas$george@salle-s.org> writes:
'Lut,
Ça a l'air d'être complètement n'importe quoi, cette page. D'ailleurs,
ce n'est pas la seule dans cette section.
Le profil du mec qui a édité la page laisse entendre qu'il est connu
comme le clown de service, donc la page est peut-être un délire...
--
Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs
????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais
oublié , y'a du Farce Télécom derrière, ca doit être ça ...
-+- PP in: <http://www.le-gnu.net> - Tout, faut tout modérer -+-
Ça a l'air d'être complètement n'importe quoi, cette page. D'ailleurs, ce n'est pas la seule dans cette section.
Le profil du mec qui a édité la page laisse entendre qu'il est connu comme le clown de service, donc la page est peut-être un délire...
-- Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs ????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais oublié , y'a du Farce Télécom derrière, ca doit être ça ... -+- PP in: <http://www.le-gnu.net> - Tout, faut tout modérer -+-
Eric Masson
Pascal Hambourg writes:
'Lut,
Justement, sur une de mes machines la taille "available" indiquée correspond en fait à l'ouverture AGP ("aperture") réglée dans le BIOS, pas à la taille de mémoire embarquée sur la carte graphique.
La GART et l'AGP aperture semblent être liés (mise à disposition de textures depuis la ram système vers la carte graphique pour le rendu) http://www.techpowerup.com/articles/overclocking/vidcard/43 Ces deux éléments ne sont pas liés à la taille de ram présente sur la carte en elle-même.
-- N'ouvrez aucun message ayant pour objet RETURNED OR ENABLE TO DELIVER. ce virus se greffe tout seul à tout les composants de votre ordinateur et les détruit. Ce message vous est envoyé par l'équipe du QUICK DRIVE -+-AL in: Guide du Neuneu Usenet - Le virus Mad Cow frappe encore -+-
Justement, sur une de mes machines la taille "available" indiquée
correspond en fait à l'ouverture AGP ("aperture") réglée dans le BIOS,
pas à la taille de mémoire embarquée sur la carte graphique.
La GART et l'AGP aperture semblent être liés (mise à disposition de
textures depuis la ram système vers la carte graphique pour le rendu)
http://www.techpowerup.com/articles/overclocking/vidcard/43
Ces deux éléments ne sont pas liés à la taille de ram présente sur la
carte en elle-même.
--
N'ouvrez aucun message ayant pour objet RETURNED OR ENABLE TO DELIVER.
ce virus se greffe tout seul à tout les composants de votre ordinateur
et les détruit. Ce message vous est envoyé par l'équipe du QUICK DRIVE
-+-AL in: Guide du Neuneu Usenet - Le virus Mad Cow frappe encore -+-
Justement, sur une de mes machines la taille "available" indiquée correspond en fait à l'ouverture AGP ("aperture") réglée dans le BIOS, pas à la taille de mémoire embarquée sur la carte graphique.
La GART et l'AGP aperture semblent être liés (mise à disposition de textures depuis la ram système vers la carte graphique pour le rendu) http://www.techpowerup.com/articles/overclocking/vidcard/43 Ces deux éléments ne sont pas liés à la taille de ram présente sur la carte en elle-même.
-- N'ouvrez aucun message ayant pour objet RETURNED OR ENABLE TO DELIVER. ce virus se greffe tout seul à tout les composants de votre ordinateur et les détruit. Ce message vous est envoyé par l'équipe du QUICK DRIVE -+-AL in: Guide du Neuneu Usenet - Le virus Mad Cow frappe encore -+-
Luc.Habert.00__arjf
Herve Autret :
D'un autre côté je lis que pour que le proc vidéo puisse utiliser la méméoire partagée, il faut monter explicitement /dev/shm : http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Comme dit Nicolas, c'est n'importe quoi. Le /dev/shm sert à avoir de la mémoire partagée entre processus, ce qui n'a rigoureusement rien à voir avec l'affectation de RAM à la carte graphique.
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée, ce qui est plus efficace pour transférer des gros bitmaps.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm accellerait un truc à la noix qu'il utilise, et il a inventé tout le reste.
Herve Autret :
D'un autre côté je lis que pour que le proc vidéo puisse utiliser la
méméoire partagée, il faut monter explicitement /dev/shm :
http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Comme dit Nicolas, c'est n'importe quoi. Le /dev/shm sert à avoir de la
mémoire partagée entre processus, ce qui n'a rigoureusement rien à voir avec
l'affectation de RAM à la carte graphique.
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines
applications X parce qu'il y a une extension au protocole X qui permet de
communiquer entre serveur et client via de la mémoire partagée, ce qui est
plus efficace pour transférer des gros bitmaps.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm
accellerait un truc à la noix qu'il utilise, et il a inventé tout le reste.
D'un autre côté je lis que pour que le proc vidéo puisse utiliser la méméoire partagée, il faut monter explicitement /dev/shm : http://wiki.slackware-fr.org/administration:trucs:activer_la_memoire_partagee_d_une_carte_video
Comme dit Nicolas, c'est n'importe quoi. Le /dev/shm sert à avoir de la mémoire partagée entre processus, ce qui n'a rigoureusement rien à voir avec l'affectation de RAM à la carte graphique.
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée, ce qui est plus efficace pour transférer des gros bitmaps.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm accellerait un truc à la noix qu'il utilise, et il a inventé tout le reste.
Herve Autret
Bonjour,
Luc Habert a écrit:
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée, ce qui est plus efficace pour transférer des gros bitmaps.
Si je dépose un fichier dans /dev/shm, la quantité de mémoire partagée (cat /proc/meminfo|grep Shmem) augmente. Cette mémoire partagée passe d'environ 150 à 404 ko quand je lance X, que /dev/shm soit monté ou non. Pour finir, elle ne varie pas quand j'affiche une assez grosse scène avec une appli qui utilise OpenGL (2'30" pour rafraîchir la fenêtre), sans texture explicites. Pour l'instant ; le jour où j'en aurai besoin, je surveillerai cet aspect.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm accellerait un truc à la noix qu'il utilise, et il a inventé tout le reste.
De mon côté, j'éviterai de m'étendre sur le cas de celui qui a cité cette page sans l'avoir étudiée. :-^
à + -- Hervé
Bonjour,
Luc Habert a écrit:
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur
certaines applications X parce qu'il y a une extension au protocole X
qui permet de communiquer entre serveur et client via de la mémoire
partagée, ce qui est plus efficace pour transférer des gros bitmaps.
Si je dépose un fichier dans /dev/shm, la quantité de mémoire partagée
(cat /proc/meminfo|grep Shmem) augmente.
Cette mémoire partagée passe d'environ 150 à 404 ko quand je lance X,
que /dev/shm soit monté ou non.
Pour finir, elle ne varie pas quand j'affiche une assez grosse scène
avec une appli qui utilise OpenGL (2'30" pour rafraîchir la fenêtre),
sans texture explicites.
Pour l'instant ; le jour où j'en aurai besoin, je surveillerai cet aspect.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm
accellerait un truc à la noix qu'il utilise, et il a inventé tout le
reste.
De mon côté, j'éviterai de m'étendre sur le cas de celui qui a cité cette
page sans l'avoir étudiée. :-^
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée, ce qui est plus efficace pour transférer des gros bitmaps.
Si je dépose un fichier dans /dev/shm, la quantité de mémoire partagée (cat /proc/meminfo|grep Shmem) augmente. Cette mémoire partagée passe d'environ 150 à 404 ko quand je lance X, que /dev/shm soit monté ou non. Pour finir, elle ne varie pas quand j'affiche une assez grosse scène avec une appli qui utilise OpenGL (2'30" pour rafraîchir la fenêtre), sans texture explicites. Pour l'instant ; le jour où j'en aurai besoin, je surveillerai cet aspect.
Bref, le guignol qui a écrit cette page a vu qu'avoir un /dev/shm accellerait un truc à la noix qu'il utilise, et il a inventé tout le reste.
De mon côté, j'éviterai de m'étendre sur le cas de celui qui a cité cette page sans l'avoir étudiée. :-^
à + -- Hervé
Hugues
Ce cher Nicolas George <nicolas$ a posté :
Herve Autret , dans le message <4ea90f68$0$25885$, a écrit :
Ça a l'air d'être complètement n'importe quoi, cette page.
En effet, et ça fait peur ...
Dans la liste des énormités relevées :
- /dev/shm est un répertoire périphérique.. Mais bien sûûr... C'est un répertoire, point. Et en l'occurence, carrément un point de montage pour un système de fichiers de type tmpfs (présent physiquement en RAM.. Aucun rapport avec la carte video.)
- l'utilisation de la RAM par la carte vidéo à travers le système de fichiers, j'y crois à 100%... En effet, pourquoi ne pas accéder directement à la RAM si on peut faire plus compliqué ? :) Techniquement, c'est faisable, mais dans ce cas on devrait au moins avoir 2/3 options de configuration à passer au driver de la carte graphique, ne serait-ce que pour qu'il sache où aller déposer ses petites cochonneries... Où sont-elles ? L'auteur n'en parle pas.. (Et même si ça se pouvait, quelle idée de faire ça à travers le vfs..)
- la taille définie pour /dev/shm dépend directement de la "mémoire partagée de la carte video".. Mais n'importe quoi.... ...d'autant que plus loin il dit qu'il vaut mieux mettre le double si on utilise d'autres applis... Faudrait savoir ! :)
D'ailleurs, ce n'est pas la seule dans cette section.
Erf, ça me donne pas très envie de lire le reste :)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Nicolas George <nicolas$george@salle-s.org> a posté :
Herve Autret , dans le message <4ea90f68$0$25885$426a74cc@news.free.fr>,
a écrit :
Ça a l'air d'être complètement n'importe quoi, cette page.
En effet, et ça fait peur ...
Dans la liste des énormités relevées :
- /dev/shm est un répertoire périphérique.. Mais bien sûûr...
C'est un répertoire, point. Et en l'occurence, carrément un point de
montage pour un système de fichiers de type tmpfs (présent
physiquement en RAM.. Aucun rapport avec la carte video.)
- l'utilisation de la RAM par la carte vidéo à travers le système de
fichiers, j'y crois à 100%... En effet, pourquoi ne pas accéder
directement à la RAM si on peut faire plus compliqué ? :)
Techniquement, c'est faisable, mais dans ce cas on devrait au moins
avoir 2/3 options de configuration à passer au driver de la carte
graphique, ne serait-ce que pour qu'il sache où aller déposer ses
petites cochonneries... Où sont-elles ? L'auteur n'en parle pas..
(Et même si ça se pouvait, quelle idée de faire ça à travers le vfs..)
- la taille définie pour /dev/shm dépend directement de la "mémoire
partagée de la carte video".. Mais n'importe quoi....
...d'autant que plus loin il dit qu'il vaut mieux mettre le double si
on utilise d'autres applis... Faudrait savoir ! :)
D'ailleurs, ce n'est pas la seule dans cette section.
Erf, ça me donne pas très envie de lire le reste :)
Ça a l'air d'être complètement n'importe quoi, cette page.
En effet, et ça fait peur ...
Dans la liste des énormités relevées :
- /dev/shm est un répertoire périphérique.. Mais bien sûûr... C'est un répertoire, point. Et en l'occurence, carrément un point de montage pour un système de fichiers de type tmpfs (présent physiquement en RAM.. Aucun rapport avec la carte video.)
- l'utilisation de la RAM par la carte vidéo à travers le système de fichiers, j'y crois à 100%... En effet, pourquoi ne pas accéder directement à la RAM si on peut faire plus compliqué ? :) Techniquement, c'est faisable, mais dans ce cas on devrait au moins avoir 2/3 options de configuration à passer au driver de la carte graphique, ne serait-ce que pour qu'il sache où aller déposer ses petites cochonneries... Où sont-elles ? L'auteur n'en parle pas.. (Et même si ça se pouvait, quelle idée de faire ça à travers le vfs..)
- la taille définie pour /dev/shm dépend directement de la "mémoire partagée de la carte video".. Mais n'importe quoi.... ...d'autant que plus loin il dit qu'il vaut mieux mettre le double si on utilise d'autres applis... Faudrait savoir ! :)
D'ailleurs, ce n'est pas la seule dans cette section.
Erf, ça me donne pas très envie de lire le reste :)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Nicolas George
Luc Habert, dans le message <j8bah3$fbm$, a écrit :
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée
Même pas : l'extension MIT-SHM dont tu parles utilise de la mémoire partagée SysV, où les segments de mémoire partagée sont désignés par une clef numérique et sont gérés spécifiquement par le noyau (cf. la sortie de la commande ipcs), alors que /dev/shm sert pour la mémoire partagée POSIX, où les segments sont désignés par un nom, qui sert en fait de nom de fichier sous /dev/shm.
Luc Habert, dans le message <j8bah3$fbm$1@news.ens.fr>, a écrit :
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines
applications X parce qu'il y a une extension au protocole X qui permet de
communiquer entre serveur et client via de la mémoire partagée
Même pas : l'extension MIT-SHM dont tu parles utilise de la mémoire partagée
SysV, où les segments de mémoire partagée sont désignés par une clef
numérique et sont gérés spécifiquement par le noyau (cf. la sortie de la
commande ipcs), alors que /dev/shm sert pour la mémoire partagée POSIX, où
les segments sont désignés par un nom, qui sert en fait de nom de fichier
sous /dev/shm.
Luc Habert, dans le message <j8bah3$fbm$, a écrit :
Maintenant, avoir un /dev/shm peut avoir un effet bénéfique sur certaines applications X parce qu'il y a une extension au protocole X qui permet de communiquer entre serveur et client via de la mémoire partagée
Même pas : l'extension MIT-SHM dont tu parles utilise de la mémoire partagée SysV, où les segments de mémoire partagée sont désignés par une clef numérique et sont gérés spécifiquement par le noyau (cf. la sortie de la commande ipcs), alors que /dev/shm sert pour la mémoire partagée POSIX, où les segments sont désignés par un nom, qui sert en fait de nom de fichier sous /dev/shm.
Luc.Habert.00__arjf
Nicolas George :
Même pas : l'extension MIT-SHM dont tu parles utilise de la mémoire partagée SysV
Ouin, j'ai eu la flemme de vérifier de laquelle il s'agissait. Bon, donc il n'y a meme pas un epsilon de factuel dans cet article, hallucinant.
Nicolas George :
Même pas : l'extension MIT-SHM dont tu parles utilise de la mémoire partagée
SysV
Ouin, j'ai eu la flemme de vérifier de laquelle il s'agissait. Bon, donc il
n'y a meme pas un epsilon de factuel dans cet article, hallucinant.
