Non, par exemple les nouveaux xserver-xorg-video-intel et -nv viennent automatiquement comme toute mise à jour normale, pas besoin de demander explicitement pour avoir du support de plus de cartes graphiques intel ou nvidia.
Non, c'est beaucoup plus que Etch mise à jour 4 vu qu'il y a du support matériel ajouté et pas seulement des mises jour de sécurité comme dans les autres mises à jour. Il suffit de lire le message d'annonce pour comprendre un peu, au lieu de troller au pif...
Avec une distribution correcte, tu auras des paquets précompilés des release candidates de Mesa 7.1 qui contiennent le driver 3d pour r500. Genre il y a Mesa 7.1-rc3 dans Debian experimental.
En fait, c'était des termes anglais sans même avoir vaguement songé à essayer de les traduire :) Je préfère coller à ce qu'on trouve dans ton /proc/mtrr ("uncachable") plutôt que d'essayer de traduire (pas la peine de lancer un troll sur est-ce que le mot cache est français :))
Le support de PAT n'a pas été demandé pour gérer le cache, pas plutôt pour les drivers réseau et graphiques qui voulaient faire du PIO rapide grâce au Write-Combining (WC, qui regroupe des écritures contigues en mémoire en une seule grosse écriture sur le bus). Pour le cache, les MTRR suffisaient très souvent car la répartition cachable/uncachable est souvent très simple (une grande zone de RAM cachable suivie d'une grande zone de mémoire I/O uncachable).
Par contre, quand on commence à mettre du WC sur les cartes réseau et graphique, le nombre de plage à configurer dépasse rapidement le nombre de MTRR disponible (4 ou 8), d'où l'intérêt de PAT. Surtout que c'était disponible depuis longtemps dans les autres OS et que Linux continuait à ne pas le supporter avec des prétextes douteux pour refuser des patchs.
Par contre, le support de PAT n'est encore satisfaisant dans 2.6.26. Par exemple, quand on demande du WC, on a aucune garantie de l'avoir, on peut avoir du uncachable habituel. Mais pire, on n'est pas prévenu quand ca arrive (notamment quand PAT est désactivé, ce qui est le cas par défaut dans 2.6.26).
Et encore pire, comme PAT est prioritaire sur MTRR, on ne peut pas mettre un MTRR en plus "au cas où" car il sera ignoré à cause de PAT. Donc au final, PAT devient une solution de secours pour les drivers, alors que ca devait être la solution ultime. On va devoir essayer de mettre une MTRR WC d'abord, et si ca foire, on demandera du PAT WC en espérant ne pas avoir du uncachable à la place. Super...
> Fedora introduit la gestion optionnelle du modsetting pour les cartes Intel !
Le modesetting tout court, ca existe depuis des lustres pour plein de cartes (sinon tu ne pourrais pas avoir de X du tout).
C'est le modesetting *dans le noyau* qui est important ici, ca permet d'éviter de changer de mode plusieurs fois pendant le boot. L'idée est que le noyau met la carte dans le bon mode (résolution+rafraichissement) des le debut du boot pour eviter d'avoir a rechanger plus tard (changer de mode = ecran qui saute et devient noir quelques secondes, donc pas beau et lent).
Dans Linux, y a du LRO spécifique a certains drivers (neterion et netxen iirc) et du LRO générique depuis peu. A terme tout le monde devrait utiliser le générique...
Pour bien suivre la suite, je conseille d'ouvrir net/ipv4/inet_lro.c pour voir le code du LRO générique auquel je vais faire reference ci-dessous ainsi que driver/net/ehea/ehea_main.c pour son utilisation dans le driver eHEA.
Lorsqu'un paquet arrive, les drivers normaux appelent netif_receive_skb() (ou netif_rx() selon si NAPI est actif ou pas) qui passe le paquet aux couches supérieures (genre IP et TCP). Si tu supportes LRO, tu appelles lro_receive_skb() a la place.
La-dedans, le vrai travail est fait dans __lro_proc_skb(). Quand cette fonction n'arrive pas a LROer, elle retourne une erreur et lro_receive_skb() se rabat sur les netif_receive_skb() ou netif_rx() habituels.
Le détail de __lro_proc_skb() maintenant. D'abord, elle utilise un callback get_skb_header() du driver pour recuperer des infos sur le paquet. Comme chaque carte stocke les headers et donnees de sa propre maniere, le callback est defini par le driver a l'initialisation et le LRO l'appelle quand il a besoin de trucs specifiques, l'endroit ou est stocké le header dans le paquet actuel en l'occurence.
Ensuite, __lro_proc_skb() verifie que c'est du IPv4 et TCP puis on essaie de recuperer un "descripteur" de LRO (l'equivalent des sessions de neterion) par lro_get_desc. On l'initialise si nécessaire, on vérifie que le nouveau paquet va bien juste après ce qui a deja ete recu dans ce descripteur, puis l'ajoute avec lro_add_packet()
lro_get_desc(), c'est juste un tableau de connexions en cours de LRO. Chaque driver en supporte un certain nombre (genre 8), limite plus ou moins arbitraire. Chaque arrivee de plein de paquets d'une meme connexion cree une session, et on la flushe un peu plus tard en passant l'agregation de tous les paquets d'un coup aux couches superieures.
Comme en general, meme si on a plein de connexions ouvertes, on a pas plein de paquet entrelacés de toutes les connexions a la fois, 8 sessions suffisent a peu pres pour couvrir les connexions qui bourrinent vraiment. A noter que si une connexion alterne entre activité et calme, elle acquiera/relachera des sessions LRO au fur et a mesure. On ne peut pas garder une session indefiniment, elle sera flushee de force de temps en temps pour la preter aux autres connexions. Bref ca marche :)
__lro_proc_skb() finit par l'ajout de paquet avec lro_add_packet(). C'est des trucs chiants de manipulation des buffers contenus dans le skb (on les chaine a la queueleuleu), et d'adaptation des longueurs, checksums et seqnums, pas grand chose d'intéressant.
La question finale, c'est "quand est-ce qu'on arrete d'agreger?". Deja, il y a un nombre max de paquets defini par le driver (lro_mgr->max_aggr, 64 souvent). De plus Linux n'aime pas les paquets de plus de 64ko, donc on arrete d'agreger avant.
Concretement, arreter d'agreger, c'est fermer une session et la passer aux couches superieures. On utilise lro_flush() pour faire ca. Elle finit d'ajuster les headers TCP/IP et passe le gros paquet agregé a netif_receive_skb() (ou netif_rx() selon si NAPI est actif). Apres ca, le descripteur/session LRO est relaché, donc une autre connexion (ou la meme) pourra l'utiliser.
De plus, on agrege les paquets qui se suivent dans une mem connexion. Mais si ca arrive pas dans l'ordre, on arrete d'agreger. Ca evite d'avoir a gerer des trous. Et aussi ca evite par exemple de passer des paquets tres tres dans le desordre aux couches superieures. Par exemple un paquet recent serait deja remonté pendant que des paquets vieux continueraient a se faire agreger au niveau du driver au lieu de remonter eux aussi.
Et enfin, on arrete d'agreger a intervalle vaguement regulier (quand NAPI fait un coup de polling du driver) pour éviter que des paquets soient ralentis trop longtemps dans le driver pour rien. On appelle lro_flush_all() qui fait lro_flush() sur tous les descripteurs/sessions en cours.
Vous pouvez aussi regarder drivers/net/myri10ge/myri10ge.c qui utilise le LRO generique avec des fragments (pages physiques discontigues) par opposition a eHEA qui utilise des skb lineaires (socket buffer contigus en memoire virtuelle). C'est juste une differente gestion de la memoire et de la facon dont la carte depose les paquets en reception. Le LRO fournit des fonctions *_skb() et *_frags() pour gerer les 2 modeles.
Tout se passe dans xge_hal_lro_process_rx():
La carte vient de déposer un nouveau paquet en mémoire, le driver appelle d'abord__hal_lro_capable() pour savoir si on peut agreger ce paquet, puis __hal_get_lro_session() pour recuperer/creer la session de LRO, puis __hal_append_lro() pour accumuler le paquet dans cette session. Il n'y aucune intervention de la carte dans tout ca.
Et comme tu peux le remarquer, le code n'est pas très compliqué. Il s'agit grosso-modo d'ajuster les checksums, longueur et numeros de sequence dans les headers IP et TCP, et de chainer les buffers de donnees.
Tu veux peut-être aussi que je t'explique comment LRO marche dans le driver que je maintiens dans Linux ? :)
On y voit le code qui accumule logiciellement les paquets (code générique dans Linux, et code spécifique à 2 drivers dans FreeBSD). On se demande pourquoi ca s'appelle LR"O" au final...
> Toujours dans le domaine des réseaux il est maintenant possible
> d'utiliser certaines cartes accélératrices de type TSO (TCP/IP
> segmentation offload) et LRO (Large Receive Offload) au lieu de
> faire ces opérations uniquement avec le processeur central.
Cartes accélératrices est très abusé là...
TSO c'est juste découper un gros paquet à envoyer en plusieurs MTU et être capable d'ajuster quelques headers genre le numéro de séquence. Pas de quoi casser 3 pattes à un canard. Toutes les cartes modernes dignes de ce nom savent le faire.
LRO, c'est une autre histoire. Il n'a d'Offload que son nom. Agréger des paquets en réception implique de connaître l'état de toutes les connexions. C'est impossible dans les cartes réseau pour des raisons de ressources mémoire, de puissance et synchro avec l'hôte. Toutes les implémentations actuelles de LRO sont logicielles. C'est la pile basse de réception (au niveau des drivers) qui agrège des paquets avant de les passer à la pile haute (genre TCP) pour réduire les coûts. Mais on sait très bien faire ça sans assistance d'une carte "accélératrice". La plupart des drivers Linux qui font du LRO le font purement logiciellement.
Le seul point sur lequel les cartes peuvent aider le LRO, c'est le header-splitting qui consiste à déposer les headers et données en des endroits séparés en mémoire pour faciliter l'agrégation LRO au dessus. Certaines cartes savent faire ça (Neterion notamment), mais beaucoup de drivers n'en ont pas besoin pour avoir du LRO très performant (Myri-10G et eHEA notamment).
Dixit John Bridgman a XDS2007, ils ont aussi des clients qui bossent avec fglrx et ne veulent pas changer pour le driver libre, notamment car AMD/ATI leur fait du support pour ce driver (alors que le support pour le driver libre ne pourra jamais être garanti de la même façon...).
Donc ATI/AMD doit continuer à maintenir le driver proprio pour ces clients, qui évidemment veulent aussi de plus en plus de fonctionnalités.
> Désolé de te contredire, mais côté performances entre le pilote
> proprio ATI et le pilote libre, sur une carte ancienne (j'ai une Radeon
> 9800 Pro), le pilote proprio explose le pilote libre en performances
> 3D.
Ca depend des benchmarks. Avec glxgears oui, mais il est bien connu pour ne pas être un benchmark...
9800 Pro, c'est deja plutôt bien supporté, c'est du R350 iirc. Les specs pour ces chipsets arriveront plus tard et ne devraient pas apporter énormément (un peu quand même, surtout pour la 3D).
Meme s'il n'y aura pas de specs explicites pour r300, le moteur 3d est à peu près le même que dans r500, donc il y aura grosso-modo des specs pour la 3d sur r300 au final.
A part ça, sur ma Mobility X300 (rv370), xf86-video-ati marche bien depuis longtemps...
Le concept de RAM hotplug est plutot axé sur une intervention planifiée (notamment le retrait d'une barrette après avoir demandé au noyau de migrer toutes les données s'y trouvant). C'est très différent d'un noeud qui tombe en panne sans prévenir dans un SSI (les processus et données sont perdues s'il n'y a pas de checkpointing/réplication préalabre), ceci relève plutot de la tolérance aux pannes.
[^] # Re: On n'y comprend plus rien
Posté par Brice Goglin . En réponse à la dépêche Sortie de Debian « Etch et demi ». Évalué à 1.
[^] # Re: On n'y comprend plus rien
Posté par Brice Goglin . En réponse à la dépêche Sortie de Debian « Etch et demi ». Évalué à 1.
[^] # Re: On n'y comprend plus rien
Posté par Brice Goglin . En réponse à la dépêche Sortie de Debian « Etch et demi ». Évalué à 2.
[^] # Re: expérience avec les pilotes Radeon ?
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 1.
[^] # Re: expérience avec les pilotes Radeon ?
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 1.
Laissez tomber le driver radeonhd, xf86-video-ati est mieux et mieux supporté
</troll>
[^] # Re: PAT c'est surtout pour WC, pas pour les caches
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 5.
[^] # Re: PAT c'est surtout pour WC, pas pour les caches
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 1.
# PAT c'est surtout pour WC, pas pour les caches
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 8.
Par contre, quand on commence à mettre du WC sur les cartes réseau et graphique, le nombre de plage à configurer dépasse rapidement le nombre de MTRR disponible (4 ou 8), d'où l'intérêt de PAT. Surtout que c'était disponible depuis longtemps dans les autres OS et que Linux continuait à ne pas le supporter avec des prétextes douteux pour refuser des patchs.
Par contre, le support de PAT n'est encore satisfaisant dans 2.6.26. Par exemple, quand on demande du WC, on a aucune garantie de l'avoir, on peut avoir du uncachable habituel. Mais pire, on n'est pas prévenu quand ca arrive (notamment quand PAT est désactivé, ce qui est le cas par défaut dans 2.6.26).
Et encore pire, comme PAT est prioritaire sur MTRR, on ne peut pas mettre un MTRR en plus "au cas où" car il sera ignoré à cause de PAT. Donc au final, PAT devient une solution de secours pour les drivers, alors que ca devait être la solution ultime. On va devoir essayer de mettre une MTRR WC d'abord, et si ca foire, on demandera du PAT WC en espérant ne pas avoir du uncachable à la place. Super...
# Modesetting *dans le noyau*
Posté par Brice Goglin . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 6.
Le modesetting tout court, ca existe depuis des lustres pour plein de cartes (sinon tu ne pourrais pas avoir de X du tout).
C'est le modesetting *dans le noyau* qui est important ici, ca permet d'éviter de changer de mode plusieurs fois pendant le boot. L'idée est que le noyau met la carte dans le bon mode (résolution+rafraichissement) des le debut du boot pour eviter d'avoir a rechanger plus tard (changer de mode = ecran qui saute et devient noir quelques secondes, donc pas beau et lent).
[^] # Re: TSO et LRO
Posté par Brice Goglin . En réponse à la dépêche Sortie de FreeBSD 7.0 et 6.3. Évalué à 10.
Pour bien suivre la suite, je conseille d'ouvrir net/ipv4/inet_lro.c pour voir le code du LRO générique auquel je vais faire reference ci-dessous ainsi que driver/net/ehea/ehea_main.c pour son utilisation dans le driver eHEA.
Lorsqu'un paquet arrive, les drivers normaux appelent netif_receive_skb() (ou netif_rx() selon si NAPI est actif ou pas) qui passe le paquet aux couches supérieures (genre IP et TCP). Si tu supportes LRO, tu appelles lro_receive_skb() a la place.
La-dedans, le vrai travail est fait dans __lro_proc_skb(). Quand cette fonction n'arrive pas a LROer, elle retourne une erreur et lro_receive_skb() se rabat sur les netif_receive_skb() ou netif_rx() habituels.
Le détail de __lro_proc_skb() maintenant. D'abord, elle utilise un callback get_skb_header() du driver pour recuperer des infos sur le paquet. Comme chaque carte stocke les headers et donnees de sa propre maniere, le callback est defini par le driver a l'initialisation et le LRO l'appelle quand il a besoin de trucs specifiques, l'endroit ou est stocké le header dans le paquet actuel en l'occurence.
Ensuite, __lro_proc_skb() verifie que c'est du IPv4 et TCP puis on essaie de recuperer un "descripteur" de LRO (l'equivalent des sessions de neterion) par lro_get_desc. On l'initialise si nécessaire, on vérifie que le nouveau paquet va bien juste après ce qui a deja ete recu dans ce descripteur, puis l'ajoute avec lro_add_packet()
lro_get_desc(), c'est juste un tableau de connexions en cours de LRO. Chaque driver en supporte un certain nombre (genre 8), limite plus ou moins arbitraire. Chaque arrivee de plein de paquets d'une meme connexion cree une session, et on la flushe un peu plus tard en passant l'agregation de tous les paquets d'un coup aux couches superieures.
Comme en general, meme si on a plein de connexions ouvertes, on a pas plein de paquet entrelacés de toutes les connexions a la fois, 8 sessions suffisent a peu pres pour couvrir les connexions qui bourrinent vraiment. A noter que si une connexion alterne entre activité et calme, elle acquiera/relachera des sessions LRO au fur et a mesure. On ne peut pas garder une session indefiniment, elle sera flushee de force de temps en temps pour la preter aux autres connexions. Bref ca marche :)
__lro_proc_skb() finit par l'ajout de paquet avec lro_add_packet(). C'est des trucs chiants de manipulation des buffers contenus dans le skb (on les chaine a la queueleuleu), et d'adaptation des longueurs, checksums et seqnums, pas grand chose d'intéressant.
La question finale, c'est "quand est-ce qu'on arrete d'agreger?". Deja, il y a un nombre max de paquets defini par le driver (lro_mgr->max_aggr, 64 souvent). De plus Linux n'aime pas les paquets de plus de 64ko, donc on arrete d'agreger avant.
Concretement, arreter d'agreger, c'est fermer une session et la passer aux couches superieures. On utilise lro_flush() pour faire ca. Elle finit d'ajuster les headers TCP/IP et passe le gros paquet agregé a netif_receive_skb() (ou netif_rx() selon si NAPI est actif). Apres ca, le descripteur/session LRO est relaché, donc une autre connexion (ou la meme) pourra l'utiliser.
De plus, on agrege les paquets qui se suivent dans une mem connexion. Mais si ca arrive pas dans l'ordre, on arrete d'agreger. Ca evite d'avoir a gerer des trous. Et aussi ca evite par exemple de passer des paquets tres tres dans le desordre aux couches superieures. Par exemple un paquet recent serait deja remonté pendant que des paquets vieux continueraient a se faire agreger au niveau du driver au lieu de remonter eux aussi.
Et enfin, on arrete d'agreger a intervalle vaguement regulier (quand NAPI fait un coup de polling du driver) pour éviter que des paquets soient ralentis trop longtemps dans le driver pour rien. On appelle lro_flush_all() qui fait lro_flush() sur tous les descripteurs/sessions en cours.
Vous pouvez aussi regarder drivers/net/myri10ge/myri10ge.c qui utilise le LRO generique avec des fragments (pages physiques discontigues) par opposition a eHEA qui utilise des skb lineaires (socket buffer contigus en memoire virtuelle). C'est juste une differente gestion de la memoire et de la facon dont la carte depose les paquets en reception. Le LRO fournit des fonctions *_skb() et *_frags() pour gerer les 2 modeles.
[^] # Re: TSO et LRO
Posté par Brice Goglin . En réponse à la dépêche Sortie de FreeBSD 7.0 et 6.3. Évalué à 7.
Je vois un driver qui agrege en software...
Tout se passe dans xge_hal_lro_process_rx():
La carte vient de déposer un nouveau paquet en mémoire, le driver appelle d'abord__hal_lro_capable() pour savoir si on peut agreger ce paquet, puis __hal_get_lro_session() pour recuperer/creer la session de LRO, puis __hal_append_lro() pour accumuler le paquet dans cette session. Il n'y aucune intervention de la carte dans tout ca.
Et comme tu peux le remarquer, le code n'est pas très compliqué. Il s'agit grosso-modo d'ajuster les checksums, longueur et numeros de sequence dans les headers IP et TCP, et de chainer les buffers de donnees.
Tu veux peut-être aussi que je t'explique comment LRO marche dans le driver que je maintiens dans Linux ? :)
[^] # Re: TSO et LRO
Posté par Brice Goglin . En réponse à la dépêche Sortie de FreeBSD 7.0 et 6.3. Évalué à 2.
Pour les détails techniques, il vaut mieux regarder
http://lwn.net/Articles/244206/
http://fxr.watson.org/fxr/source/dev/mxge/mxge_lro.c?v=RELEN(...)
http://fxr.watson.org/fxr/source/dev/nxge/if_nxge.c?v=RELENG(...)
On y voit le code qui accumule logiciellement les paquets (code générique dans Linux, et code spécifique à 2 drivers dans FreeBSD). On se demande pourquoi ca s'appelle LR"O" au final...
# TSO et LRO
Posté par Brice Goglin . En réponse à la dépêche Sortie de FreeBSD 7.0 et 6.3. Évalué à 3.
> d'utiliser certaines cartes accélératrices de type TSO (TCP/IP
> segmentation offload) et LRO (Large Receive Offload) au lieu de
> faire ces opérations uniquement avec le processeur central.
Cartes accélératrices est très abusé là...
TSO c'est juste découper un gros paquet à envoyer en plusieurs MTU et être capable d'ajuster quelques headers genre le numéro de séquence. Pas de quoi casser 3 pattes à un canard. Toutes les cartes modernes dignes de ce nom savent le faire.
LRO, c'est une autre histoire. Il n'a d'Offload que son nom. Agréger des paquets en réception implique de connaître l'état de toutes les connexions. C'est impossible dans les cartes réseau pour des raisons de ressources mémoire, de puissance et synchro avec l'hôte. Toutes les implémentations actuelles de LRO sont logicielles. C'est la pile basse de réception (au niveau des drivers) qui agrège des paquets avant de les passer à la pile haute (genre TCP) pour réduire les coûts. Mais on sait très bien faire ça sans assistance d'une carte "accélératrice". La plupart des drivers Linux qui font du LRO le font purement logiciellement.
Le seul point sur lequel les cartes peuvent aider le LRO, c'est le header-splitting qui consiste à déposer les headers et données en des endroits séparés en mémoire pour faciliter l'agrégation LRO au dessus. Certaines cartes savent faire ça (Neterion notamment), mais beaucoup de drivers n'en ont pas besoin pour avoir du LRO très performant (Myri-10G et eHEA notamment).
[^] # Re: FireGL ?
Posté par Brice Goglin . En réponse à la dépêche Du nouveau chez ATI. Évalué à 4.
Donc ATI/AMD doit continuer à maintenir le driver proprio pour ces clients, qui évidemment veulent aussi de plus en plus de fonctionnalités.
[^] # Re: Petite précision sur la NDM :
Posté par Brice Goglin . En réponse à la dépêche Du nouveau chez ATI. Évalué à 1.
> proprio ATI et le pilote libre, sur une carte ancienne (j'ai une Radeon
> 9800 Pro), le pilote proprio explose le pilote libre en performances
> 3D.
Ca depend des benchmarks. Avec glxgears oui, mais il est bien connu pour ne pas être un benchmark...
[^] # Re: Petite précision sur la NDM :
Posté par Brice Goglin . En réponse à la dépêche Du nouveau chez ATI. Évalué à 1.
[^] # Re: ATI pilote proprio qui fonctionne bien?
Posté par Brice Goglin . En réponse à la dépêche Du nouveau chez ATI. Évalué à 3.
Pour la lenteur, tu peux essayer "disable low impact fallback" dans driconf.
[^] # Re: 900 pages ?
Posté par Brice Goglin . En réponse à la dépêche AMD fournit plus de 900 pages de spécifications pour ses GPU. Évalué à 3.
# 434+460<900
Posté par Brice Goglin . En réponse à la dépêche AMD fournit plus de 900 pages de spécifications pour ses GPU. Évalué à 2.
[^] # Re: 900 pages ?
Posté par Brice Goglin . En réponse à la dépêche AMD fournit plus de 900 pages de spécifications pour ses GPU. Évalué à 2.
[^] # Re: et pour les néophytes ?
Posté par Brice Goglin . En réponse à la dépêche AMD fournit plus de 900 pages de spécifications pour ses GPU. Évalué à 2.
[^] # Re: et pour les néophytes ?
Posté par Brice Goglin . En réponse à la dépêche AMD fournit plus de 900 pages de spécifications pour ses GPU. Évalué à 10.
[^] # Re: État d'avancement « suffisant » ?
Posté par Brice Goglin . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 1.
A part ça, sur ma Mobility X300 (rv370), xf86-video-ati marche bien depuis longtemps...
[^] # Re: 2.0.0 : une version de transition
Posté par Brice Goglin . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 1.
[^] # Re: Un projet prometteur, mais...
Posté par Brice Goglin . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 1.
Il a quoi d'inédit par rapport à un système comme GMS ou tous les autres travaux existants sur la pagination à distance ?