Linux? - Page 198

Pour nouveau, as-tu essayé de laisser tomber optirun et de lancer ton application comme je l'ai dit:
DRI_PRIME=1 glxspheres64? Et es-tu sûr que tu n'as pas cassé Nouveau en installant le pilote propriétaire? (L'installation du pilote propriétaire blackliste normalement la partie noyau de Nouveau, donc il te faudra désactiver ça pour repasser à Nouveau.)

J'ai fini par essayer pour voir, pilote nouveau, avec tes paramètres : ~170fps, ~200Mpx/sec.
Au final, nouveau avec cette commande donne des résultats équivalents à nvidia avec optirun (aussi bien avec Intel qu'avec la CG en GPU).

Au final, la solution valable qu'il me semble rester pour avoir la pleine puissance graphique est le driver NVIDIA tournant au naturel sur GPU. L'inconvénient demeure donc pour l'heure que cela nécessite de recharger xorg en passant de l'un à l'autre.
Peut-être avec Wayland ou Mir ce changement pourra être invisible.

EDIT : le module de switch est assez efficace, presque comme un bouton on/off pour passer de Intel à nvidia et inversement. Le delog/relog est lui très rapide, de l'ordre de ~5sec (~2sec de nvidia vers Intel). La seule vraie contrainte donc est qu'avec le delog se ferment toutes mes applis quand je veux passer à du nvidia.
Mais même sur secteur je ne peux pas rester toujours sur nvidia, le double ventilo est demandeur.

En meme temps sous linux il n'y a rien de bien sérieux qui demande un vrai GPU, alors estime toi heureux d'avoir 160fps

Godzil (./5913) :
En meme temps sous linux il n'y a rien de bien sérieux qui demande un vrai GPU, alors estime toi heureux d'avoir 160fps

Blender il est cpu only ?

Et Tux Racer, et glxgears !

Hum blender peux utiliser un vrai GPU sur un vrai OS c'est vrai

(et sérieusement je crois qu'il marche tres bien sans acceleration materiel pour l'affichage)

et chromium alors ?

Meowcate (./5912) :
J'ai fini par essayer pour voir, pilote nouveau, avec tes paramètres : ~170fps, ~200Mpx/sec.Au final, nouveau avec cette commande donne des résultats équivalents à nvidia avec optirun (aussi bien avec Intel qu'avec la CG en GPU).

Donc on a atteint l'égalité de performance à conditions comparables, yippie!

Au final, la solution valable qu'il me semble rester pour avoir la pleine puissance graphique est le driver NVIDIA tournant au naturel sur GPU.

Pour les 60 fps de Nouveau en natif:

Meowcate (./5909) :
Driver nouveau, sans optirun : ~ 60fps, ~ 66Mpx/sec

c'est une feature, je cite man nouveau:

Option "GLXVBlank"
"boolean"Synchronize GLX clients to VBlank. Useful where tearing is a problem, harmful if the GPU isn't fast enough to keep up with the monitor refresh rate. Default: on.

Il en est de même pour le pilote Intel:

Meowcate (./5909) :
Driver nvidia, choix GPU sur Intel, sans optirun : ~60fps, ~66Mpx/sec

Je cite man intel:

Option "VSync"
"boolean"
This option controls the use of commands to synchronise rendering with the vertical refresh of the display. Some rendering commands have the option to be performed in a "tear-free" fashion by stalling the GPU to wait for the display to be outside of the region to be updated. This slows down all rendering, and historically has been the source of many GPU hangs. Default: enabled.

Ces pilotes se synchronisent par défaut sur les 60 Hz de ton écran, parce que ça ne sert strictement à rien d'afficher plus vite, l'écran ne te le montrera pas. Mais dans les 2 cas, ça se désactive dans xorg.conf.

Bon... si je comprends bien, quand j'utilise nouveau, je n'ai pas moyen de faire de benchmark parce qu'il se limitera toujours ?

Mais c'est débile : nvidia "normal" tourne à plein régime à ~1400fps. nouveau en mode "PRIME" tourne à 170fps. Et ne viens pas me dire que c'est bridé cette fois, puisque ça dépasse VBlank.
Ce que j'aimerai, c'est un vrai gros benchmark à la 3DMarks pour Linux afin de tester les performances globales dans des situations réelles d'utilisation intensives (3D, shadders, etc). Ça existe ?

Si tu désactives GLXVBlank dans xorg.conf, tu devrais avoir un benchmark plus utilisable. Mais les outils de type glxgears ou glxspheres ne sont pas vraiment de bons benchmarks parce que ce n'est pas une situation réaliste.

C'est aussi ce que je me suis dit au final, après une brève recherche je DL Heaven Benchmark et je donnerai mes résultats.

Meowcate (./5919) :
Ce que j'aimerai, c'est un vrai gros benchmark à la 3DMarks pour Linux afin de tester les performances globales dans des situations réelles d'utilisation intensives (3D, shadders, etc). Ça existe ?

Unigine Valley ou Heaven.

En faisant de nouveaux benchmarks, j'ai fini par remarquer quelque chose, sans saisir pourquoi : nouveau ne se préoccupe pas de ma carte graphique. Il n'utilise que mon processeur. Utiliser DRI_PRIME=1 donne les mêmes résultats que vblank_mode=0, autrement dit faire tourner le CPU à pleine puissance pour le rendu graphique, sans la limite de rafraichissement de l'écran. Pas étonnant que mes scores nvidia explosent nouveau.
Et comme mon PC fonctionne convenablement ainsi, et que je peux accepter le léger soucis de devoir me relog quand je veux switcher entre Intel/nvidia, je vais laisser ainsi pour l'heure.

C'est bien parce que je m'accroche à Linux, ma partition Windows 10, de fait, ne souffre pas de ce soucis.

Fais une VM Linux

Meowcate (./5923) :
En faisant de nouveaux benchmarks, j'ai fini par remarquer quelque chose, sans saisir pourquoi : nouveau ne se préoccupe pas de ma carte graphique. Il n'utilise que mon processeur. Utiliser DRI_PRIME=1 donne les mêmes résultats que vblank_mode=0, autrement dit faire tourner le CPU à pleine puissance pour le rendu graphique, sans la limite de rafraichissement de l'écran. Pas étonnant que mes scores nvidia explosent nouveau.

Je ne comprends pas comment tu arrives à la conclusion que ce soit le CPU qui fait le travail. vblank_mode=0 désactive la synchronisation entre le GPU et les 60 Hz de l'écran et permet donc de mesurer la vraie vitesse du GPU. Si tu veux vraiment comparer avec du pur CPU, essaie LIBGL_ALWAYS_SOFTWARE=1 (avec la libGL de Mesa (Intel/Nouveau), pas celle de NVidia), tu verras que ce sera nettement plus lent.

Kevin Kofler (./5925) :
Je ne comprends pas comment tu arrives à la conclusion que ce soit le CPU qui fait le travail.

Un simple exemple : un xranrd --listproviders avec le pilote nvidia me donne trois sources (un nvidia et deux intel). La même commande avec le pilote nouveau me donne une seule source, une intel.
Mais le problème, si ce que tu dis est vrai, est que les résultats que j'obtiens avec nouveau sont presque 10 fois plus lent qu'avec le processeur nvidia.

J'ai lancé le benchmark Heaven sur quelques préréglages déjà un brin exigeant, j'ai eu une moyenne de 50fps (en comparaison le niveau "normal" m'a donné 113fps, le niveau "extrème" 39.7fps). Avec nouveau, je n'ai pas poussé le benchmark jusqu'à la fin : pendant la première minute, j'avais déjà une moyenne de 5fps. Et ce, bien sûr, avec ce DRI_PRIME=1.

On en revient à: Es-tu sûr que le pilote Nouveau fonctionne, en particulier, que le composant noyau (nouveau_kms) n'est pas blacklisté quand tu testes Nouveau?

Pour comparer avec le pur CPU, cf. LIBGL_ALWAYS_SOFTWARE=1. Si ça donne la même chose, alors il y a de fortes chances que ton pilote ne fonctionne pas.

Sinon, la sortie de DRI_PRIME=1 glxinfo est probablement aussi intéressante. Si tu lis quelque chose de type:
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)alors c'est que tu es en mode pur CPU (llvmpipe = pilote qui utilise LLVM pour convertir OpenGL en des instructions pour le CPU).

meow: on en revient au middle finger de Linus. seule la carte Intel fonctionne avec les pilotes open source. Je sais même pas pourquoi tu te fais iech, mets le pilote nvidia et joue avec tes fps.

Mais pourquoi jouer sous Linux surtout ?

alors qu'on peut passer son temps à développer, c'est clair !

(sur un windows, en plus !)

./5929 Et bien d'abord parce que j'aime Linux, même si certains insistent beaucoup pour me faire changer d'avis, ensuite c'est mon espace de travail principal, donc quand un jeu est dispo autant sur Linux que Windows, je l'installe sur Linux pour ne pas avoir à rebooter quand je veux jouer à ce jeu.
De plus j'ai fait l'effort de mettre un dual-boot Windows, sur mon précédent pc gamer je ne m'en étais pas soucié. Depuis que Steam pour Linux gagne du terrain, il y avait peu de jeux m'intéressant qui n'étaient pas soit sur Linux soit sur ma XBox.

./5928 Le soucis comme j'ai dit est que je dois delog pour switcher entre Intel et nvidia pour le graphisme. Je dois passer sur nvidia quand je veux jouer à du lourd, mais je ne peux y rester en permanence parce que ça me bouffe la batterie et le double-ventilo fait du bruit.
Paradoxalement, si j'ai plus de puissance avec ce nou... ce driver plus récent nvidia (si je dis "nouveau driver nvidia" ça risque d'être dur à suivre ^^) qu'avant, bumblebee m'était plus efficace par le passé pour permettre ce on/off manuel.
Peut-être simplement n'ai-je pas encore trouvé comment avoir un switch à chaud.

J'avais pas compris que tu utilisais Linux comme OS principal, OK.

Poettering dans toute sa gloire :
https://github.com/systemd/systemd/issues/2402

Franchement, Lennart n'est pas le coupable ici. Monter efivarfs ro n'est pas une solution parce que des applications comme grub-install et même systemd lui-même ont besoin d'y écrire. Il faudrait que le noyau empêche l'écriture dans les variables qu'on n'a pas le droit de modifier parce que le matériel est bogué. Userspace est absolument le mauvais endroit pour cette protection.

Quoi qu'il en soit, la réponse appropriée à un bug report qui signale un problème qui endommage le matériel n'est certainement pas "non tout va bien, c'est fait exprès".

Kevin Kofler (./5935) :
Franchement, Lennart n'est pas le coupable ici. Monter efivarfs ro n'est pas une solution parce que des applications comme grub-install et même systemd lui-même ont besoin d'y écrire. Il faudrait que le noyau empêche l'écriture dans les variables qu'on n'a pas le droit de modifier parce que le matériel est bogué. Userspace est absolument le mauvais endroit pour cette protection.

Oui, le noyau devrait l'empêcher.
Mais cela n'empêche pas qu'un accès si direct à a des variables qui peuvent briquer une machine ne devrait pas être permis par défaut, même pour root ! Si on va dans cette logique, on peut se demander pourquoi avoir un compte utilisateur différent de root. Après tout certaines applications ont besoin d'être root.
grub-install & systemd peuvent très bien faire un remount rw avant de faire les modifications (puis un remount ro) avant de faire les opérations ayant besoin d'avoir un tel niveau d'accès.
(Et tout çà, oui, c'est parce que UEFI, c'est de la merde).

Il faut aussi dire que les concepteurs de ces firmwares n'avaient certainement pas en tête une interface de type efivarfs qui permet à un logiciel userspace de tout modifier, même sans qu'il sache qu'il est en train de toucher à UEFI.

PpHd (./5937) :
Mais cela n'empêche pas qu'un accès si direct à a des variables qui peuvent briquer une machine ne devrait pas être permis par défaut, même pour root !

Kevin Kofler (./5938) :
Il faut aussi dire que les concepteurs de ces firmwares n'avaient certainement pas en tête une interface de type efivarfs qui permet à un logiciel userspace de tout modifier, même sans qu'il sache qu'il est en train de toucher à UEFI.

Mais complètement :x
Franchement, l'extrémisme du tout fichier devrait avoir ses limites :/
Les variables EFI c'est sensé être de la conf système complètement spécifique (enfin y'a des bouts ± génériques, mais à côté on y fout aussi complètement ce qu'on veut). Avoir un accès aussi facile à cette conf c'est presque aussi néfaste que d'avoir accès au BIOS en écriture :/

(Et franchement, c'est pas parce que le userland Linux gère UEFI comme un trou de balle que c'est de la merde hein. Enfin bon.)

ça me rappelle ces gens qui font des procès aux collectivités parce qu’ils sont tombés dans un gouffre, alors qu'il n'y avait pas de barrière autour...