Apa yang sebenarnya dilakukan oleh LIBGL_ALWAYS_INDIRECT = 1?

KDE SC 4.5.0 memiliki beberapa masalah dengan beberapa kartu video termasuk kartu saya. Setelah Rilis Arch merekomendasikan beberapa solusi . Salah satunya

ekspor "LIBGL_ALWAYS_INDIRECT = 1" sebelum memulai KDE

Saya memutuskan bahwa itu adalah metode termudah dan terbaik. Tetapi saya tidak tahu apa fungsinya atau bagaimana itu berdampak pada sistem saya. Apakah lebih lambat dari standar? haruskah saya ingat untuk mengawasi masalah dan menonaktifkannya nanti setelah diperbaiki?

Render tidak langsung berarti protokol GLX akan digunakan untuk mengirimkan perintah OpenGL dan X.org akan melakukan gambar yang sebenarnya.

Perenderan langsung berarti aplikasi dapat mengakses perangkat keras secara langsung tanpa komunikasi dengan X.org terlebih dahulu melalui mesa.

Render langsung lebih cepat karena tidak memerlukan perubahan konteks ke proses X.org.

Klarifikasi: Dalam kedua kasus rendering dilakukan oleh GPU (atau secara teknis - dapat dilakukan oleh GPU). Namun dalam rendering tidak langsung prosesnya terlihat seperti:

1. Program memanggil perintah
2. Perintah adalah / dikirim ke X.org oleh protokol GLX
3. X.org memanggil perangkat keras (yaitu GPU) untuk menggambar

Dalam rendering langsung

1. Program memanggil perintah
2. Perintah dikirim ke GPU

Harap dicatat bahwa karena OpenGL dirancang sedemikian rupa sehingga dapat beroperasi melalui jaringan rendering tidak langsung lebih cepat maka akan menjadi implementasi naif dari arsitektur yaitu memungkinkan untuk mengirim perintah perintah sekaligus. Namun ada beberapa overhead dalam hal waktu CPU yang dihabiskan untuk sakelar konteks dan protokol penanganan.

Pertama, LIBGL_ALWAYS_INDIRECTadalah bendera yang terkait dengan implementasi OpenGL sisi-klien 3D Mesa (libGL.so). Ini tidak akan berfungsi dengan driver biner dari vendor lain (mis. NVIDIA).

Kedua, untuk menjawab pertanyaan Anda secara langsung, terakhir saya melihat kode Mesa yang berfungsi seperti ini:

Sebelum ~ 2008 ketika Mesa bekerja dengan server X tidak langsung (mis. Anda melakukan ssh -Xatau secara eksplisit mengatur tampilan Anda ke server non-lokal) itu akan membuat daftar visual GLX yang disediakan oleh server X jauh tersedia untuk aplikasi GLX Anda. Panggilan aplikasi misalnya glXChooseVisual () dan Mesa akan menemukan sesuatu yang masuk akal untuk dicocokkan, dan glFoo()panggilan berikutnya akan dikirim ke server X jarak jauh di mana mereka dieksekusi oleh libGL apa pun yang dihubungkan dengan server X jarak jauh (kemungkinan GPU Anda).

Sekitar akhir 2008 Mesa diubah sehingga ingin menggunakan perangkat lunak internal OpenGL renderer ( driver Xlib ) untuk koneksi X jarak jauh. (Beberapa distribusi seperti SuSE secara khusus menambal ini untuk kembali ke perilaku lama.) Ini hanya akan masuk jika server X jarak jauh menawarkan visual GLX yang persis sama dengan salah satu perender perangkat lunak internal. (Kalau tidak Anda akan mendapatkan umum, " Kesalahan: tidak bisa mendapatkan RGB, visual buffered ganda ".) Jika visual seperti itu ditemukan maka Mesa akan membuat semua glFoo()perintah dengan CPU lokal (untuk aplikasi), dan tekan hasil ke server X jarak jauh melalui gambar raster ( XPutImage()); Pengaturan LIBGL_ALWAYS_INDIRECT=1(sebelum Mesa 17.3 nilai apa pun akan berfungsi, sejak saat itu Anda harus menggunakan 1 atau truememberitahu Mesa untuk mengabaikan rendering langsung normal atau renderer perangkat lunak internal dan menggunakan rendering tidak langsung seperti dulu.

Memilih render tidak langsung atau render perangkat lunak langsung akan memengaruhi dua hal:

Versi OpenGL

• Render tidak langsung umumnya dibatasi untuk OpenGL 1.4.
• Render perangkat lunak langsung akan mendukung apa pun yang didukung oleh rasterizer perangkat lunak Mesa, mungkin OpenGL 2.1+

Performa

• Jika aplikasi Anda dirancang untuk koneksi tidak langsung (menggunakan daftar tampilan, meminimalkan pertanyaan bolak-balik) maka Anda bisa mendapatkan kinerja yang wajar.
• Jika aplikasi Anda melakukan sesuatu yang bodoh seperti glGetInteger()100 kali per frame maka bahkan pada LAN yang cepat setiap query tersebut akan dengan mudah mengambil 1ms, atau total 100ms per frame, artinya Anda tidak akan pernah mendapatkan lebih dari 10 FPS dalam aplikasi Anda.
• Aplikasi yang sama, jika beban rendering tidak terlalu berat, dapat berkinerja sangat baik dengan rendering perangkat lunak langsung, karena semua glGetInteger()panggilan dijawab secara langsung dalam hitungan mikro atau nanodetik.
• Jika aplikasi Anda membuat daftar tampilan jutaan titik dan kemudian melakukan banyak rotasi maka rendering tidak langsung dengan GPU nyata di ujung yang lain akan memberikan kinerja yang jauh lebih baik.
• Suatu aplikasi juga dapat kembali ke jalur kode yang berbeda ketika hanya tersedia OpenGL 1.4 vs 2.x, yang juga dapat mempengaruhi kinerja.

Jadi, Anda dapat melihat tanpa detail aplikasi dan karakteristik jaringan Anda, tidak mungkin untuk mengatakan apakah perenderan perangkat lunak langsung atau perenderan tidak langsung lebih baik untuk situasi apa pun.

Dalam kasus Anda tampaknya Anda menjalankan instance kwin lokal, jadi efeknya LIBGL_ALWAYS_INDIRECTadalah memaksa rendering tidak langsung ke server X lokal Anda. Ini tampaknya mengubah kwinperilaku (hanya OpenGL 1.4) atau menghindari beberapa bug lainnya.

Tentunya Anda ingin menghapus flag ini ketika masalah mendasar diperbaiki.