LIBGL_ALWAYS_INDIRECT = 1 gerçekte ne yapar?


22

KDE SC 4.5.0'da benimki de dahil olmak üzere bazı ekran kartlarında bazı sorunlar var. Sürüm Yayını üzerine, birkaç geçici çözüm önerildi . Biri olan

KDE'ye başlamadan önce "LIBGL_ALWAYS_INDIRECT = 1" ifadesini dışa aktarın

En kolay ve en iyi yöntem olduğuna karar verdim. Ama ne yaptığını veya sistemimi nasıl etkilediğini bilmiyorum. Varsayılandan daha yavaş mı? Sorunla ilgilenmeyi ve sonra çözüldükten sonra onu devre dışı bırakmayı hatırlamalı mıyım?

Yanıtlar:


13

Dolaylı oluşturma, GLX protokolünün OpenGL komutlarını iletmek için kullanılacağı ve X.org'un gerçek çizimi yapacağını ifade eder.

Doğrudan oluşturma , uygulamanın önce X.org ile mesa aracılığıyla iletişim kurmadan donanıma doğrudan erişebilmesi anlamına gelir.

Doğrudan oluşturma, X.org işleminde bağlam değişikliği gerektirmediğinden daha hızlıdır.

Açıklama: Her iki durumda da işleme GPU tarafından yapılır (veya teknik olarak - GPU tarafından yapılabilir). Ancak dolaylı görüntülemede işlem şöyle görünür:

  1. Program komutları çağırıyor
  2. Komut (lar) GLX protokolü ile X.org'a gönderilir / gönderilir
  3. X.org çizmek için donanım çağırır (örn. GPU)

Doğrudan görüntülemede

  1. Program komutları çağırıyor
  2. Komutlar GPU'ya gönderildi / gönderildi

Lütfen OpenGL'nin ağ üzerinden çalışabilecek şekilde tasarlandığından dolaylı görüntülemenin daha hızlı olacağından, mimarinin saf bir şekilde uygulanabileceğini, yani bir seferde bir demet komut göndermeye izin verdiğini unutmayın. Bununla birlikte, bağlam anahtarları ve işleme protokolü için harcanan CPU zamanı bakımından bir miktar ek yük vardır.


Bu, CPU'mun video çipim yerine renderleme atm yaptığı anlamına mı geliyor?
xenoterracide

3
Hayır. Her iki durumda da, eğer hızlandırma varsa GPU çizim yapar - ancak ek yükler de vardır. Hızlandırılmamış çizim son derece yavaştır ve gerektirecek herhangi bir etki LIBGL_ALWAYS_INDIRECT=1onunla çalışmaz (yani dolaylı görüntü işleme geçici çözümü genellikle kompozit wm gibi OpenGL'nin ileri kullanımı için gereklidir).
Maciej Piechotka,

14

İlk olarak, LIBGL_ALWAYS_INDIRECTMesa 3D istemci tarafı OpenGL uygulamasına (libGL.so) ilişkin bir bayrak. Diğer üreticilerin ikili sürücüleri ile çalışmaz (ör. NVIDIA).

İkincisi, sorunuza doğrudan cevap vermek için, son olarak Mesa koduna baktım, bayrak şu şekilde çalışıyor:

Mesa, dolaylı bir X sunucusuyla çalıştığında (örneğin ssh -X, ekranınızı yerel olmayan bir sunucuya ayarladığınız veya açıkça ayarladığınız ) 2008 yılı öncesi , uzak X sunucusu tarafından sağlanan GLX görsellerinin listesini GLX uygulamanıza uygun hale getirecekti. Uygulama, örneğin glXChooseVisual () işlevini çağırır ve Mesa, uygun bir şey bulur ve ardından gelen glFoo()çağrılar, uzak X sunucusunun bağladığı libGL ile bağlanmış olan uzak X sunucusuna gönderilir (muhtemelen GPU'nuz).

2008 yılının sonlarında Mesa, uzak X bağlantıları için dahili yazılımı OpenGL renderer'ı ( Xlib sürücüsü ) kullanmak istemek için değiştirildi . (SuSE gibi bazı dağıtımlar bunu eski davranışa geri dönmek için özellikle yattı.) Bu, yalnızca uzak X sunucusunun, iç yazılım oluşturucusuyla tam olarak eşleşen bir GLX görselini sunması durumunda devreye girerdi. (Aksi takdirde, " Hata: bir RGB, Çift arabelleğe alınmış görsel elde edemedi " ifadesini alırsınız .) Eğer böyle bir görsel bulunursa, Mesa tüm glFoo()komutları yerel (uygulamaya) CPU ile işleyecekti ve Raster resimlerden uzak X sunucusuna sonuç ( XPutImage()); Ayar LIBGL_ALWAYS_INDIRECT=1(Mesa 17.3'ten önce herhangi bir değer işe yarar, o zamandan beri 1 veya true kullanmalısınız.) Mesa'ya normal doğrudan görüntülemeyi ya da dahili yazılım oluşturucuyu yoksaymasını ve eskisi gibi dolaylı görüntülemeyi kullanmasını söyler.

Dolaylı görüntülemeyi ya da doğrudan yazılım görüntülemeyi seçmek iki şeyi etkiler:

OpenGL Sürümü

  • Dolaylı görüntü oluşturma genellikle OpenGL 1.4 ile sınırlıdır.
  • Doğrudan yazılım oluşturma, Mesa yazılımı rasterizerinin desteklediği her neyse, muhtemelen OpenGL 2.1+ ürününü destekleyecektir.

performans

  • Uygulamanız dolaylı bağlantılar için tasarlandıysa (ekran listeleri kullanır, gidiş dönüş sorgularını en aza indirir) o zaman makul bir performans elde edebilirsiniz.
  • Uygulamanız glGetInteger()çerçeve başına 100 kez gibi aptalca bir şey yaparsa, hızlı bir LAN'da bile bu sorguların her biri kolayca 1ms veya çerçeve başına toplam 100ms alabilir; bu da uygulamanızda asla 10 FPS'den fazlasını alamayacağınız anlamına gelir.
  • Eğer oluşturma yükü çok ağır değilse, bu aynı uygulama doğrudan yazılım oluşturma ile çok iyi sonuç verebilir, çünkü tüm bu glGetInteger()çağrılar doğrudan bir mikro veya nanosaniye cinsinden cevaplanır.
  • Uygulamanız milyonlarca köşe görüntüleme listesi oluşturuyorsa ve daha sonra çok fazla döndürme yapıyorsa, diğer ucunda gerçek bir GPU ile dolaylı işleme daha iyi performans verecektir.
  • Bir uygulama ayrıca yalnızca OpenGL 1.4 vs 2.x kullanılabilir olduğunda performansı da etkileyebilecek farklı bir kod yoluna düşebilir.

Bu nedenle, uygulamanızın ve ağ özelliklerinin tam detayları olmadan, herhangi bir durum için doğrudan yazılım oluşturma veya dolaylı görüntülemenin daha iyi olup olmadığını söylemek mümkün değildir.

Sizin durumunuzda yerel bir kwin örneği çalıştırıyorsunuz gibi görünüyor, bu nedenle etkisi LIBGL_ALWAYS_INDIRECTdolaylı görüntülemeyi yerel X sunucunuza zorlamaktır. Bu görünüşte ya kwindavranışını değiştirir (sadece OpenGL 1.4) ya da başka hatalardan kaçınır.

Kesinlikle, temeldeki sorun çözüldüğünde bu bayrağı kaldırmak istiyorsunuz.


Not olarak: Diğer kullanıcılar nVidia ile şunları yapabilir: __GL_ALLOW_UNOFFICIAL_PROTOCOL ... Bunu gnome-session-wayland (3.18) kavramının uzaktan uygulama kanıtı için kullanıyorum.
elika kohen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.