Bonjour,

Je suis nouveau parmis vous, et vais éssayer de me faire une place :p
Après 2 ans sous Gentoo, j'ai décidé d'aller voir ailleurs pour du "clean"... et voilà, j'ai attérit sur FreeBSD.

J'en suis venu à m'inscrire ici, car comme beaucoup de newbies sur *BSD, j'ai quelques difficultés.

Et une en particulier : faire marcher correctement mon intel GMA 4500MHD. Les perfs en 2D sont vraiment mauvaises, et inutilisable si j'active le compositing pour la vraie transparence.
Je me suis penché sur Xorg.0.log et ça me parle d'un problème de drm master, apparement lié au fait que mon noyau ne supporte pas GEM.

J'hésite donc à passer sur la 9.0-RC1 pour pouvoir activer l'option GEM dans le noyau et pouvoir bénéficier de perfs x10. Qu'est-ce que vous en dîtes ?

Quelqu'un aurait-il un bon wiki/tuto pour opérer une upgrade de stable -> current ?

Merci pour tout
/alg0x32

Tout d'abord, poste quand même des détails concernant le problème avec ta GMA-bidule: ça pourrait inspirer quelqu'un et t'éviter des pirouettes…

Pour ce qui est d'upgrader vers la branche 9, l'essentiel est de lire UPDATING -> lorsqu'il y a quelque-chose de particulier à faire (changement non-trivial, ou surprenant), c'est ici que c'est signalé. Après, tu peux consulter le calendrier de la release et te faire une idée de l'état actuel de la branche en jetant un œil à la page 9.0 Todo du wiki FreeBSD. À toi de juger si tu montes sur le wagon avant l'arrêt complet et si le risque en vaut la peine… (je ne sais rien du support GEM)

alg0x32 wrote on 09. Nov 2011 at 14:14:

J'hésite donc à passer sur la 9.0-RC1 pour pouvoir activer l'option GEM dans le noyau et pouvoir bénéficier de perfs x10. Qu'est-ce que vous en dîtes ?

GEM est encore hautement expérimental.

http://wiki.freebsd.org/Intel_GPU

Peut-être pas l'idéal pour débuter mais si tu as l'âme aventureuse...

Sinon la méthode d'upgrade c'est celle du handbook.

alg0x32 wrote on 09. Nov 2011 at 14:14:

Et une en particulier : faire marcher correctement mon intel GMA 4500MHD. Les perfs en 2D sont vraiment mauvaises, et inutilisable si j'active le compositing pour la vraie transparence. Je me suis penché sur Xorg.0.log et ça me parle d'un problème de drm master, apparement lié au fait que mon noyau ne supporte pas GEM.

Tout d'abord, qu'avez vous défini comme pilote graphique pour Xorg ?


Quote:

J'hésite donc à passer sur la 9.0-RC1 pour pouvoir activer l'option GEM dans le noyau et pouvoir bénéficier de perfs x10. Qu'est-ce que vous en dîtes ?

Que, si vous débutez, c'est une mauvaise idée.

FreeBSD 9, n'est pas tout à fait tout à fait stable et comporte, de base, moult options de débogage.
D'autant que les modifications pourraient être rétrocédée sur la branche 8.


Si vous recherchez à monter en performance, ce ne sera pas le top.

J'ai souvenir des mes essais laborieux  lors de l'intégration du pilote «nouveau» qui nécessitait des aménagement concernant DRM dans le noyau du tout nouveau et pas encore stable (à l'époque) FreeBSD8...

Si vous êtes prêt à rendre compte de vos résultat à la communauté, et à essayer tous les patchs, par contre, allez y.
Essayer une nouvelle fonctionnalité dans le noyau, c'est du boulot.

fgudin wrote on 09. Nov 2011 at 15:17:

Tout d'abord, poste quand même des détails concernant le problème avec ta GMA-bidule: ça pourrait inspirer quelqu'un et t'éviter des pirouettes…

Voici des détails (liés au compositing):
-Le processus "Xorg" utilise 20% d'UC sous top, et dans la colonne STATE j'ai CPU0.
-Dans le terminal xcompmgr me renvoi des erreurs :

Code (]error 9: BadDrawable (invalid Pixmap or Window parameter) request 151 minor 1 serial 537
error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 538
error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 539[/code):

Mon xorg.conf : [code]Section "ServerLayout"      Identifier     "X.org Configured"      Screen      0  "Screen0" 0 0      InputDevice    "Mouse0" "CorePointer"      InputDevice    "Keyboard0" "CoreKeyboard" EndSection Section "Files"      ModulePath   "/usr/local/lib/xorg/modules"      FontPath     "/usr/local/lib/X11/fonts/misc/"      FontPath     "/usr/local/lib/X11/fonts/TTF/"      FontPath     "/usr/local/lib/X11/fonts/OTF"      FontPath     "/usr/local/lib/X11/fonts/Type1/"      FontPath     "/usr/local/lib/X11/fonts/100dpi/"      FontPath     "/usr/local/lib/X11/fonts/75dpi/"   FontPath     "/usr/local/lib/X11/fonts/URW/"   FontPath     "/usr/local/lib/X11/fonts/freefonts/"   FontPath     "/usr/local/lib/X11/fonts/TrueType/" EndSection Section "Module"      Load  "extmod"      Load  "record"      Load  "dbe"      Load  "glx"      Load  "dri"   Load  "dri2"   Load  "freetype" EndSection Section "InputDevice"      Identifier  "Keyboard0"      Driver      "kbd"      Option      "XkbModel" "pc105"   Option      "XkbLayout" "fr"   Option      "XkbVariant" "nodeadkeys"      Option                  "CustomKeycodes" "off"      Option                  "XkbOptions" "terminate:ctrl_alt_bksp" EndSection Section "InputDevice"      Identifier  "Mouse0"      Driver      "mouse"      Option          "Protocol" "auto"      Option          "Device" "/dev/sysmouse"   Option          "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor"      Identifier   "Monitor0"      VendorName   "Monitor Vendor"      ModelName    "Monitor Model" EndSection Section "Device"         ### Available Driver options are:-         ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",         ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"         ### [arg]: arg optional         #Option     "NoAccel"                  # [<bool>]         #Option     "SWcursor"                # [<bool>]         #Option     "ColorKey"                # <i>         #Option     "CacheLines"               # <i>         #Option     "Dac6Bit"                  # [<bool>]         #Option     "DRI"                     # [<bool>]         #Option     "NoDDC"                   # [<bool>]         #Option     "ShowCache"               # [<bool>]         #Option     "XvMCSurfaces"            # <i>         #Option     "PageFlip"                # [<bool>]      Identifier  "Card0"      Driver      "intel"      VendorName  "Intel Corporation"      BoardName   "Mobile 4 Series Chipset Integrated Graphics Controller"      BusID       "PCI:0:2:0"   Option      "AccelMethod" "UXA"      Option                  "VideoRam" "24576"      Option                  "FramebufferCompression" "false"      Option                  "SwapbuffersWait"      "false" EndSection Section "Screen"      Identifier "Screen0"      Device     "Card0"      Monitor    "Monitor0"         DefaultDepth 24      SubSection "Display"            Viewport   0 0            Depth     1      EndSubSection      SubSection "Display"            Viewport   0 0            Depth     4      EndSubSection      SubSection "Display"            Viewport   0 0            Depth     8      EndSubSection      SubSection "Display"            Viewport   0 0            Depth     15      EndSubSection      SubSection "Display"            Viewport   0 0            Depth     16      EndSubSection      SubSection "Display"            Viewport   0 0            Depth     24                 Modes     "1280x800"      EndSubSection EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "DRI"            Mode 0666 EndSection

Et mon log Xorg :
http://paste.pocoo.org/show/505917/

Autres soucis sous X mais sans rapport au compositing :
Je suis sous awesome-wm et lorsqu'un terminal urxvt est lancé en mode fullscreen, l'affichage est très très lent.
Par exemple, un "ls /ton/rep/" va sortir le résultat ligne par ligne ! 1/4h à l'ouverture d'un fichier de 1000 lignes  :D

Pour ce qui est de passer à la 9.0-RC1, j'vais attendre un peu je crois.

alg0x32 wrote on 10. Nov 2011 at 19:35:

Autres soucis sous X mais sans rapport au compositing : Je suis sous awesome-wm et lorsqu'un terminal urxvt est lancé en mode fullscreen, l'affichage est très très lent. Par exemple, un "ls /ton/rep/" va sortir le résultat ligne par ligne ! 1/4h à l'ouverture d'un fichier de 1000 lignes  Cheesy

Ce n'est pas si sûr.
Je sais que rxvt a pour but de réduire la consommation mémoire,
mais, quand je vois tout ce qu'il demande:
[code]
david:/<1>ports/x11/rxvt-unicode>make run-depends-list
/usr/ports/devel/gio-fam-backend
/usr/ports/devel/glib20
/usr/ports/devel/ncurses
/usr/ports/devel/pkg-config
/usr/ports/graphics/gdk-pixbuf2
/usr/ports/lang/perl5.14
/usr/ports/x11-fonts/fontconfig
/usr/ports/x11-fonts/libXft
/usr/ports/x11/libXpm
/usr/ports/x11/libXrender
[/code]
...J'ai un doute.

D'autant que XRender, est un module qui gère la transparence.
Transparence gérée par le compositeur...

alg0x32 wrote on 10. Nov 2011 at 19:35:

Voici des détails (liés au compositing): -Le processus "Xorg" utilise 20% d'UC sous top, et dans la colonne STATE j'ai CPU0.

C'est énorme, en effet.

Qu'est ce que ça donnerait sans activer le compositeur ?

[xorg.conf]

Hum, l'accélération «UXA» a été écrite pour utiliser «GEM», que vous n'avez pas.

Essayez avec l'ancienne «EXA», ou la toute dernière «SNA».

.

[xorg.log]
Vous avez fait quelques chose de particulier pour avoir le «drm» d'activé dans le noyau ?

C'est assez bavard, les intels.

Il faudrait aussi résoudre les problème de polices de caractères (fonts) au passage.

David Marec wrote on 10. Nov 2011 at 21:26:

alg0x32 wrote on 10. Nov 2011 at 19:35: Autres soucis sous X mais sans rapport au compositing : Je suis sous awesome-wm et lorsqu'un terminal urxvt est lancé en mode fullscreen, l'affichage est très très lent. Par exemple, un "ls /ton/rep/" va sortir le résultat ligne par ligne ! 1/4h à l'ouverture d'un fichier de 1000 lignes  Cheesy Ce n'est pas si sûr. Je sais que rxvt a pour but de réduire la consommation mémoire, mais, quand je vois tout ce qu'il demande: Code (] david:/<1>ports/x11/rxvt-unicode>make run-depends-list /usr/ports/devel/gio-fam-backend /usr/ports/devel/glib20 /usr/ports/devel/ncurses /usr/ports/devel/pkg-config /usr/ports/graphics/gdk-pixbuf2 /usr/ports/lang/perl5.14 /usr/ports/x11-fonts/fontconfig /usr/ports/x11-fonts/libXft /usr/ports/x11/libXpm /usr/ports/x11/libXrender [/code): ...J'ai un doute. D'autant que XRender, est un module qui gère la transparence. Transparence gérée par le compositeur... Lorsque xcompmgr n'est pas lancé, la conso' cpu chute et oscille entre 1 et 3%, soit 10x moins. De même, lorsque la fenêtre qui reçoit le compositing s'agrandit, alors la conso' cpu augmente proportionnellement (jusqu'à 50~55%). D'où le soucis d'affichage dans urxvt en fullscreen. Donc tout est lié au compositing finalement. J'ai éssayé de passer sur l'accélération EXA puis SNA, et ça n'a pas réglé le problème. Sinon oui, pour le drm je l'ai activé dans le noyau : [code] device    drm device    i915drm

A vous les studios !  :)

PS: Ca fait plaisir un forum acceuillant comme celui-ci !

//EDIT
Petite information qui me revient : j'utilise le port intel29, et pas la version 2.7. Cette dernière fonctionne aussi mal que l'intel 2.9 mais en plus ça, elle ne me permet pas d'utiliser autre chose qu'UXA. Avec EXA/XAA, le serveur X ne veut pas se lancer...

alg0x32 wrote on 10. Nov 2011 at 23:09:

Lorsque xcompmgr n'est pas lancé, la conso' cpu chute et oscille entre 1 et 3%, soit 10x moins.

Je pensais aussi à l'option

Code (]"Composite" "Enable"[/code):

D'autre part, j'aurais activé l'option «FramebufferCompression». Avez vous trouvé une documentation de toutes ces options du pilote graphique Intel ? Quote: Donc tout est lié au compositing finalement. Pas tout, l'affichage des fenêtres: oui. Je n'utilise plus les effets «composite» dans les gestionnaires de fenêtres. Je m'en suis très vite lassé. Ce qui ne m'empêche pas de jouer en 3D/OpenGL. Pour vérifiez vos performances (sans le compositeur), lancez: [code] glxgears

du port mesa-demos.


Par exemple, vous pouvez `jouer` avec les options:
Option "PageFlip" "true"
Option "TripleBuffer" "true"

Pour la 3D uniquement, vous auriez des performances dégradées avec un compositeur en activant cela. (2D/3D)

David Marec wrote on 11. Nov 2011 at 08:53:

Je n'utilise plus les effets «composite» dans les gestionnaires de fenêtres. Je m'en suis très vite lassé. Ce qui ne m'empêche pas de jouer en 3D/OpenGL.

A vrai dire, seul les performances en 2D m'intéresse. Pour la 3D, je compte pas en faire sur ce laptop.
Je veux activer le compositing uniquement pour mes terminaux, la fausse transparence c'est pas top (le shading n'est pas réglé en fonction du focus, par exemple).

Mes résultats sous glxgears (SNA  et FramebufferCompression activés) / Compositing désactivé :

Code (]
2027 frames in 5.0 seconds = 405.347 FPS
2080 frames in 5.0 seconds = 415.936 FPS
[...):

[/code] Idem, mais avec le compositing d'activé : [code] 1699 frames in 5.0 seconds = 339.668 FPS 1738 frames in 5.0 seconds = 347.585 FPS [...]

Le compositing consomme ~20%, d'où la baisse de perfs d'environ 50fps. Cependant le composite n'est pas activé sur la fenêtre glxgears.

alg0x32 wrote on 11. Nov 2011 at 11:36:

Mes résultats sous glxgears (SNA  et FramebufferCompression activés) / Compositing désactivé : Code (] 2027 frames in 5.0 seconds = 405.347 FPS 2080 frames in 5.0 seconds = 415.936 FPS [...): [/code] Outch, ici, une carte NVIDIA toute bête, pilote nvidia propriétaire: [code] 9919 frames in 5.0 seconds = 1983.714 FPS 9844 frames in 5.0 seconds = 1968.746 FPS

J'ai des résultats aussi faibles que les vôtres, en plein écran.

En plein écran : 3.411 fps \o/

Je sais vraiment plus quoi faire...

Du nouveau !

J'ai désactivé le compositing pour passer sur de la fausse transparence avec urxvt. Résultat : Pareil, en plein écran, mon terminal lag sévère, et la consommation de Xorg oscille entre 30 et 35% !

De pire en pire  :-?

alg0x32 wrote on 11. Nov 2011 at 18:34:

Du nouveau ! J'ai désactivé le compositing pour passer sur de la fausse transparence avec urxvt. Résultat : Pareil, en plein écran, mon terminal lag sévère, et la consommation de Xorg oscille entre 30 et 35% ! De pire en pire  :-?

Attention, «glxgears» n'est pas un «bentchmark» (c'est ce qui est répété ad nauseam sur les ml). Il semblerait même que les résultats soient intentionnellement plafonnés  pour décourager son usage.

Pour revenir au sujet, que ce soit la transparence ou  tout bidule exotique amené par le compositeur, si le pilote graphique ne le gère pas, il sera traité par logiciel;
donc, lourd et gourmand en consommation de ressources.

Vous pouvez toujours demander de l'aide sur les listes de diffusion ou sur le forum. ( en anglais )

Car je ne suis pas très au fait de l'évolution des pilotes Intel et des modules graphiques dédiés (KMS, GEM, DRI,DRM etc.), d'où sort une nouvelle technologie par an ou presque.


Pour résumer, si vous tenez absolument à avoir un pilote capable de faire de la 3D/transparence et autres, on peut tenter un passage en 9.

Si vous tenez à conserver un système stable et éprouvé, restez en 8, sans transparence et sans chichis, en attendant que tout cela soit stabilisé dans la branche 9, ou rétrocédé dans la 8.


En fait, je suis toujours surpris de voir que l'on puisse supporter de regarder au travers un terminal semi transparent ou transparent, sans s' exploser les yeux. :-)



Déjà que j'ai cessé de jouer à world of padman, puisqu'à chaque partie, une veine oculaire a laché.

Tampis, je vais lâcher l'affaire et attendre patiement que la release 9.0 soit stable pour migrer dessus. Par contre, impossible de trouver des informations quant à sa date de sortie prévue.

Pour ce qui du "eyes killing", je trouve qu'une lègère transparence passe très bien.

alg0x32 wrote on 12. Nov 2011 at 16:00:

Tampis, je vais lâcher l'affaire et attendre patiement que la release 9.0 soit stable pour migrer dessus. Par contre, impossible de trouver des informations quant à sa date de sortie prévue.

C'était prévu en septembre : http://www.freebsd.org/releases/9.0R/schedule.html

En fait ça sort quand c'est prêt... Il n'est pas rare d'avoir plus de trois mois de retard sur une version majeure.

Vu l'avancement je dirais vers Noël.

Septembre ?! Ah okay, voilà pourquoi j'ai pas compris quand j'ai vu le calendrier hier...

Merci pour l'info ;)

Hop,

Bonjour à tous, me voilà de retour parmis vous ! :)

Je suis enfin passé sur la release 9.0-p3 [stable]. Et ce, en espérant pouvoir enfin profiter d'un support GEM/KMS pour mon gpu intel.
Et j'vois que c'est toujours pas au point !

J'ai bien activé WITH_NEW_XORG et WITH_KMS dans mon /etc/make.conf mais impossible de compiler le driver intel.
Apparement il faut appliquer un patch sur le port libdrm.

J'ai tenté d'appliquer le patch dans /usr/ports/graphics/libdrm/files/ et j'ai obtenu des erreurs.

Si quelqu'un sait comment mettre en place gem/kms sur freebsd 9.0, ce serait sympa qu'il me fasse part de comment il a procédé.

Merci !