On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:De même, le driver frame-buffer Matrox est un des plus complet
sous Linux. Il permet vraiment de tout faire... (consoles multiples
avec des résolutions différentes partagées sur plusieurs écrans, ...).
Framebuffer ?!!! La kyro marche en framebuffer sur le noyau 2.6 mais je
ne peux pas changer la résolution calée en 1280*1024 et le
rafraîchissement en 60Hz.
Même si je ne joue sur ordinateur, j'aimerais pouvoir lire des dvd et
des divx de manière fluide !
Est-ce que ça marche correctement avec le 2.4 ?
Il y a eu de gros pb avec le framebuffer dans le kernel 2.6, dans les
couches génériques. Je n'ai pas suivi de près, je ne sais pas si c'est
résolu mais ça n'avait rien de spécifique à une carte.
Mais pour lire des dvd, ce n'est pas le frame-buffer qui est important,
c'est le buffer d'overlay. Il y a un driver spécifique dans mplayer
pour le gérer (aussi bien en frame-buffer que sous X).
En principe, la résolution du buffer d'overlay est indépendante de
la résolution du frame-buffer et le scaler des séries G est excellent:
il n'est pas rare d'être obligé de postprocesser les images, voire de
faire le scaling en soft pour avoir une image correcte, mais sur ces
cartes, l'interpolation est vraiment de très bonne qualité.Avec le kernel 2.4, j'utilise le driver proprio kyro, pas le
framebuffer. Mais sinon, avant que j'installe le driver c'est comme avec
le kernel 2.6 : 1280x1024 et 60hz
Précision : j'ai juste un Athlon 600 et 256 Meg de mémoire. carte mère
acceptant seulement l'agp 2x (c'est d'ailleurs pourquoi j'ai choisi la
kyro2). La kyro2 est une hercules 64 Meg sans tv out.
J'avoue que je ne connaissais pas du tout la notion de buffer d'overlay.
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
Concrètement, si on me dit que je peux être en framebuffer avec du 80hz
min, en 1024x768, 16 bits pour la couleur (tant pis pour le 24, j'ai
essayé ça ne marche pas) et que je peux lire des dvd et divx de manière
fluide sur un écran 19 pouces et sur cette petite config,je dis ok !!
Avec un Athlon 600, tu devrais être à l'aise pour les DVD, sans doute
moins pour les divx (qui nécessitent du postprocessing assez couteux).
Concrètement, avec un K6-2 500, je joue les DVD sans pb sur ma G200.
Mais en fait, pas mal de temps CPU est gaspillé pour les accès IDE:
en SCSI, mon K6-II 300 suffit.
Donc, sur un Athlon 600, surtout s'il fait du SSE (?), ça devrait
aller à l'aise, même sans overlay, je pense.
[...]J'ai des G200, 400 et 450, mais je n'ai de toute façon pas d'écran DVI,
donc je ne sais pas si ces fonctionalités là marchent correctement.
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:
De même, le driver frame-buffer Matrox est un des plus complet
sous Linux. Il permet vraiment de tout faire... (consoles multiples
avec des résolutions différentes partagées sur plusieurs écrans, ...).
Framebuffer ?!!! La kyro marche en framebuffer sur le noyau 2.6 mais je
ne peux pas changer la résolution calée en 1280*1024 et le
rafraîchissement en 60Hz.
Même si je ne joue sur ordinateur, j'aimerais pouvoir lire des dvd et
des divx de manière fluide !
Est-ce que ça marche correctement avec le 2.4 ?
Il y a eu de gros pb avec le framebuffer dans le kernel 2.6, dans les
couches génériques. Je n'ai pas suivi de près, je ne sais pas si c'est
résolu mais ça n'avait rien de spécifique à une carte.
Mais pour lire des dvd, ce n'est pas le frame-buffer qui est important,
c'est le buffer d'overlay. Il y a un driver spécifique dans mplayer
pour le gérer (aussi bien en frame-buffer que sous X).
En principe, la résolution du buffer d'overlay est indépendante de
la résolution du frame-buffer et le scaler des séries G est excellent:
il n'est pas rare d'être obligé de postprocesser les images, voire de
faire le scaling en soft pour avoir une image correcte, mais sur ces
cartes, l'interpolation est vraiment de très bonne qualité.
Avec le kernel 2.4, j'utilise le driver proprio kyro, pas le
framebuffer. Mais sinon, avant que j'installe le driver c'est comme avec
le kernel 2.6 : 1280x1024 et 60hz
Précision : j'ai juste un Athlon 600 et 256 Meg de mémoire. carte mère
acceptant seulement l'agp 2x (c'est d'ailleurs pourquoi j'ai choisi la
kyro2). La kyro2 est une hercules 64 Meg sans tv out.
J'avoue que je ne connaissais pas du tout la notion de buffer d'overlay.
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
Concrètement, si on me dit que je peux être en framebuffer avec du 80hz
min, en 1024x768, 16 bits pour la couleur (tant pis pour le 24, j'ai
essayé ça ne marche pas) et que je peux lire des dvd et divx de manière
fluide sur un écran 19 pouces et sur cette petite config,je dis ok !!
Avec un Athlon 600, tu devrais être à l'aise pour les DVD, sans doute
moins pour les divx (qui nécessitent du postprocessing assez couteux).
Concrètement, avec un K6-2 500, je joue les DVD sans pb sur ma G200.
Mais en fait, pas mal de temps CPU est gaspillé pour les accès IDE:
en SCSI, mon K6-II 300 suffit.
Donc, sur un Athlon 600, surtout s'il fait du SSE (?), ça devrait
aller à l'aise, même sans overlay, je pense.
[...]
J'ai des G200, 400 et 450, mais je n'ai de toute façon pas d'écran DVI,
donc je ne sais pas si ces fonctionalités là marchent correctement.
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:De même, le driver frame-buffer Matrox est un des plus complet
sous Linux. Il permet vraiment de tout faire... (consoles multiples
avec des résolutions différentes partagées sur plusieurs écrans, ...).
Framebuffer ?!!! La kyro marche en framebuffer sur le noyau 2.6 mais je
ne peux pas changer la résolution calée en 1280*1024 et le
rafraîchissement en 60Hz.
Même si je ne joue sur ordinateur, j'aimerais pouvoir lire des dvd et
des divx de manière fluide !
Est-ce que ça marche correctement avec le 2.4 ?
Il y a eu de gros pb avec le framebuffer dans le kernel 2.6, dans les
couches génériques. Je n'ai pas suivi de près, je ne sais pas si c'est
résolu mais ça n'avait rien de spécifique à une carte.
Mais pour lire des dvd, ce n'est pas le frame-buffer qui est important,
c'est le buffer d'overlay. Il y a un driver spécifique dans mplayer
pour le gérer (aussi bien en frame-buffer que sous X).
En principe, la résolution du buffer d'overlay est indépendante de
la résolution du frame-buffer et le scaler des séries G est excellent:
il n'est pas rare d'être obligé de postprocesser les images, voire de
faire le scaling en soft pour avoir une image correcte, mais sur ces
cartes, l'interpolation est vraiment de très bonne qualité.Avec le kernel 2.4, j'utilise le driver proprio kyro, pas le
framebuffer. Mais sinon, avant que j'installe le driver c'est comme avec
le kernel 2.6 : 1280x1024 et 60hz
Précision : j'ai juste un Athlon 600 et 256 Meg de mémoire. carte mère
acceptant seulement l'agp 2x (c'est d'ailleurs pourquoi j'ai choisi la
kyro2). La kyro2 est une hercules 64 Meg sans tv out.
J'avoue que je ne connaissais pas du tout la notion de buffer d'overlay.
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
Concrètement, si on me dit que je peux être en framebuffer avec du 80hz
min, en 1024x768, 16 bits pour la couleur (tant pis pour le 24, j'ai
essayé ça ne marche pas) et que je peux lire des dvd et divx de manière
fluide sur un écran 19 pouces et sur cette petite config,je dis ok !!
Avec un Athlon 600, tu devrais être à l'aise pour les DVD, sans doute
moins pour les divx (qui nécessitent du postprocessing assez couteux).
Concrètement, avec un K6-2 500, je joue les DVD sans pb sur ma G200.
Mais en fait, pas mal de temps CPU est gaspillé pour les accès IDE:
en SCSI, mon K6-II 300 suffit.
Donc, sur un Athlon 600, surtout s'il fait du SSE (?), ça devrait
aller à l'aise, même sans overlay, je pense.
[...]J'ai des G200, 400 et 450, mais je n'ai de toute façon pas d'écran DVI,
donc je ne sais pas si ces fonctionalités là marchent correctement.
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
On Mon, 07 Jun 2004 23:23:38 +0200, Mary wrote:
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
quand on aime on ne compte pas :), personnellement j'ai une G550 en j'en
suis vraiment satisfait, meme pour jouer a ET, UT ne marche pas parcontre,
quake c'est parfait, et lire des videos aussi.
a l'epoque je l'ai acheté 950Franc :(, mais pour des drivers libre et
pour ne pas etre emmerdé ce n'est pas vraiment chere je pense, j'en ai
meme acheté une deuxieme au cas ou matrox n'en fabrique plus. tellement
que cette carte est correcte sous linux
Là on reconnaît le fan ;-))
On Mon, 07 Jun 2004 23:23:38 +0200, Mary wrote:
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
quand on aime on ne compte pas :), personnellement j'ai une G550 en j'en
suis vraiment satisfait, meme pour jouer a ET, UT ne marche pas parcontre,
quake c'est parfait, et lire des videos aussi.
a l'epoque je l'ai acheté 950Franc :(, mais pour des drivers libre et
pour ne pas etre emmerdé ce n'est pas vraiment chere je pense, j'en ai
meme acheté une deuxieme au cas ou matrox n'en fabrique plus. tellement
que cette carte est correcte sous linux
Là on reconnaît le fan ;-))
On Mon, 07 Jun 2004 23:23:38 +0200, Mary wrote:
A quand ces cartes à moins de 60 euros !!? :-) Etant donné que je ne
rajoute pas de possibilités par rapport à Windows, j'aurais aimé ne pas
dépenser plus de 50 euros juste pour que ce soit compatible avec Linux.
quand on aime on ne compte pas :), personnellement j'ai une G550 en j'en
suis vraiment satisfait, meme pour jouer a ET, UT ne marche pas parcontre,
quake c'est parfait, et lire des videos aussi.
a l'epoque je l'ai acheté 950Franc :(, mais pour des drivers libre et
pour ne pas etre emmerdé ce n'est pas vraiment chere je pense, j'en ai
meme acheté une deuxieme au cas ou matrox n'en fabrique plus. tellement
que cette carte est correcte sous linux
Là on reconnaît le fan ;-))
On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:
[...]
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
une cg ? Il faut changer le Xconfig ? Est-ce la même procédure pour
toutes les cgs ?
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:
[...]
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
une cg ? Il faut changer le Xconfig ? Est-ce la même procédure pour
toutes les cgs ?
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
On Tue, 08 Jun 2004 20:16:31 +0200, @(none) wrote:
[...]
Les intérêts du buffer d'overlay sont:
- c'est un buffer indépendant du frame-buffer qui est toujours devant
lui.
- le hard est en général capable de le rescaller et de le positionner
ce qui fait qu'il n'y a pas besoin d'avoir un système de fenetrage
pour gérer une incrustation vidéo.
- C'est un buffer au format YUV alors que les frames-buffers sont
généralement en RGB (certains peuvent également faire du YUV). C'est
très avantageux car les cartes d'acquisitions sortent du YUV donc
peuvent directement acquérir la vidéo dans le buffer d'overlay sans
consomer de CPU (juste encombrer un peu le bus PCI :-) ). De plus,
la plupart des codecs vidéo sont en YUV, donc ça évite d'avoir à
convertir toutes les frames à afficher: on peut décoder directement
dans le buffer d'overlay (généralement, on utilise un double buffer,
c'est plus raisonable) ce qui économise encore pas mal de CPU.
Concrètement comment faire pour mettre en place le buffer overlay sur
une cg ? Il faut changer le Xconfig ? Est-ce la même procédure pour
toutes les cgs ?
On doit pouvoir trouver des G200 d'ocase pour pas cher..
Elle n'est plus vendue, je crois. Mais ceux qui en ont ne les
lachent pas comme ça :-)
Quoi que il me semble me rappeler avoir vu des G400/450 il n'y a pas
si longtemps sur f.p.i.materiel...
Mais, je suis d'accord, les prix de Matrox sont exagérés pour le
grand public. Mais temps que les graphistes et les milieux médicaux
(Matrox a l'air de fair pas mal d'imagerie médicale) seront prêt à
y mettre ce prix, je doute qu'ils changent leur politique...
Dommage qu'il n'y ait pas plus de concurrence...
UT pour Unreal Tournament mais "ET" ?
Oui mais mettre 80 ou 90 Euros, autant acheter une ATI 9200 (non SE)
pour laquelle DRI fait des drivers libres.
UT pour Unreal Tournament mais "ET" ?
Oui mais mettre 80 ou 90 Euros, autant acheter une ATI 9200 (non SE)
pour laquelle DRI fait des drivers libres.
UT pour Unreal Tournament mais "ET" ?
Oui mais mettre 80 ou 90 Euros, autant acheter une ATI 9200 (non SE)
pour laquelle DRI fait des drivers libres.
