Que fait réellement LIBGL_ALWAYS_INDIRECT = 1?

KDE SC 4.5.0 a quelques problèmes avec certaines cartes vidéo, dont la mienne. À la sortie, Arch a recommandé plusieurs solutions de contournement . Dont l'un était

exporter "LIBGL_ALWAYS_INDIRECT = 1" avant de démarrer KDE

J'ai décidé que c'était la méthode la plus simple et la meilleure. Mais je ne sais pas ce qu'il fait ni comment cela affecte mon système. Est-ce plus lent que la valeur par défaut? dois-je me souvenir de garder un œil sur le problème et de le désactiver plus tard une fois qu'il est résolu?

Le rendu indirect signifie que le protocole GLX sera utilisé pour transmettre les commandes OpenGL et que X.org fera le vrai dessin.

Le rendu direct signifie que l'application peut accéder directement au matériel sans communication avec X.org via mesa.

Le rendu direct est plus rapide car il ne nécessite pas de changement de contexte dans le processus X.org.

Clarification: dans les deux cas, le rendu est effectué par GPU (ou techniquement - peut être effectué par GPU). Cependant, dans le rendu indirect, le processus ressemble à:

1. Le programme appelle une ou plusieurs commandes
2. La ou les commandes sont envoyées à X.org par le protocole GLX
3. X.org appelle le matériel (ie GPU) pour dessiner

En rendu direct

1. Le programme appelle une ou plusieurs commandes
2. La ou les commandes sont envoyées au GPU

Veuillez noter que parce qu'OpenGL a été conçu de manière à pouvoir fonctionner sur le réseau, le rendu indirect est plus rapide que l'implémentation naïve de l'architecture, c'est-à-dire qu'il permet d'envoyer une série de commandes en une seule fois. Cependant, il y a une surcharge en termes de temps CPU passé pour les changements de contexte et le protocole de gestion.

Tout d'abord, LIBGL_ALWAYS_INDIRECTest un indicateur lié à l'implémentation OpenGL côté client Mesa 3D (libGL.so). Il ne fonctionnera pas avec les pilotes binaires d'autres fournisseurs (par exemple NVIDIA).

Deuxièmement, pour répondre directement à votre question, la dernière fois que j'ai regardé le code Mesa, le drapeau fonctionne comme ceci:

Avant ~ 2008, lorsque Mesa travaillait avec un serveur X indirect (par exemple, vous aviez ssh -Xdéfini ou défini explicitement votre affichage sur un serveur non local), la liste des visuels GLX fournis par le serveur X distant était disponible pour votre application GLX. Les appels d'application, par exemple glXChooseVisual () et Mesa trouveraient quelque chose de raisonnable à faire correspondre, et les glFoo()appels ultérieurs seraient envoyés au serveur X distant où ils étaient exécutés par la libGL à laquelle le serveur X distant était connecté (probablement votre GPU).

Vers la fin de 2008, Mesa a été modifié de sorte qu'il souhaitait utiliser son logiciel de rendu OpenGL interne ( pilote Xlib ) pour les connexions X à distance. (Certaines distributions comme SuSE ont spécifiquement corrigé cela pour revenir à l'ancien comportement.) Cela ne se déclencherait que si le serveur X distant offrait un visuel GLX qui correspondait exactement à l'un du moteur de rendu logiciel interne. (Sinon, vous obtiendriez le " Erreur: impossible d'obtenir un visuel RVB à double tampon ".) Si un tel visuel était trouvé, Mesa rendrait toutes les glFoo()commandes avec le CPU local (à l'application), et pousserait le résultat vers le serveur X distant via des images raster ( XPutImage()); Réglage LIBGL_ALWAYS_INDIRECT=1(avant Mesa 17.3, toute valeur fonctionnerait, car alors vous devez utiliser 1 ou true) indique à Mesa d'ignorer le rendu direct normal ou le logiciel de rendu interne et d'utiliser le rendu indirect comme il le faisait auparavant.

Le choix du rendu indirect ou du rendu logiciel direct affectera deux choses:

Version OpenGL

• Le rendu indirect est généralement limité à OpenGL 1.4.
• Le rendu logiciel direct prendra en charge tout ce que le rasterizer logiciel Mesa prend en charge, probablement OpenGL 2.1+

Performance

• Si votre application est conçue pour les connexions indirectes (elle utilise des listes d'affichage, minimise les requêtes aller-retour), vous pouvez obtenir des performances raisonnables.
• Si votre application fait quelque chose de stupide comme glGetInteger()100 fois par image, même sur un réseau local rapide, chacune de ces requêtes prendra facilement 1 ms, ou 100 ms au total par image, ce qui signifie que vous ne pourrez jamais obtenir plus de 10 FPS dans votre application.
• Cette même application, si la charge de rendu n'est pas trop lourde, peut très bien fonctionner avec le rendu logiciel direct, car tous ces glGetInteger()appels reçoivent une réponse directe en quelques micro ou nanosecondes.
• Si votre application crée une liste d'affichage à un million de vertex et effectue ensuite beaucoup de rotations, le rendu indirect avec un vrai GPU à l'autre extrémité donnera de bien meilleures performances.
• Une application peut également retomber sur un chemin de code différent lorsqu'elle ne dispose que d'OpenGL 1.4 vs 2.x, ce qui peut également affecter les performances.

Ainsi, vous pouvez voir sans les détails exacts de votre application et des caractéristiques de votre réseau, il est impossible de dire si le rendu logiciel direct ou indirect est meilleur pour une situation donnée.

Dans votre cas, il semble que vous exécutiez une instance kwin locale, donc l'effet de LIBGL_ALWAYS_INDIRECTest de forcer le rendu indirect sur votre serveur X local. Cela modifie apparemment kwinle comportement de (OpenGL 1.4 uniquement) ou évite un autre bug.

Vous souhaitez certainement supprimer cet indicateur lorsque le problème sous-jacent est résolu.