OpenGL, GLX, DRI ve Mesa3D arasındaki ilişki nedir?


17

Linux'ta düşük seviyeli 3D programlama yapmaya başlıyorum. Üst düzey grafik API OpenInventor kullanma konusunda çok deneyimim var.

Tüm bu şeylerin birbirine nasıl uyduğunun farkında olmanın kesinlikle gerekli olmadığını biliyorum, ama sadece merak ediyorum. OpenGL'nin grafik uygulamaları için sadece bir standart olduğunu biliyorum. Mesa3D bu standardın açık kaynaklı bir uygulaması gibi görünmektedir.

Peki GLX ve DRI nereye uyuyor? Vikipedi ve tüm bu web sitelerini araştırırken, bunların nasıl bir araya geldiğine dair henüz bir açıklama bulamadım. Donanım hızlandırma nerede olur? Tescilli sürücülerin bununla ne ilgisi var?

Yanıtlar:


15

OpenGL dışında bu kütüphaneleri hiç kullanmadım, ama wikipedia sayfalarını okuduğunuz gibi tahmin etmeye çalışacağım.

Mesa konusunda haklý görünüyorsun. İşte ek bilgiler:

"X pencere sistemi, ağa bağlı bilgisayarlar için bir temel GUI sağlayan bir bilgisayar yazılım sistemi ve ağ protokolüdür. Bir donanım soyutlama katmanı oluşturur."

"GLX, X Pencere Sistemi tarafından sağlanan bir pencerede bunu yapmak için OpenGL kullanmak isteyen programlara olanak tanır.
GLX üç bölümden oluşur:
- OpenGL işlevleri sağlayan bir API.
- İstemcinin 3D göndermesini sağlayan X protokolünün bir uzantısı. rendering komutları - X sunucusunun oluşturma komutlarını istemciden alan ve bunları yüklü OpenGL kütüphanesine aktaran bir uzantı
İstemci ve sunucu aynı bilgisayarda çalışıyorsa ve hızlandırılmış bir 3D grafik kartı varsa, eski iki bileşen İstemci programının grafik donanımına doğrudan erişmesine izin verilir. "

"Doğrudan Görüntü Oluşturma Altyapısı (DRI), X Pencere Sisteminde, kullanıcı uygulamalarının X sunucusundan veri aktarılmasına gerek kalmadan video donanımına erişmesine olanak tanıyan bir arabirimdir."

"Open Inventor, OpenGL için daha yüksek bir programlama katmanı sağlamak üzere tasarlanmış bir C ++ 3D grafik API'sıdır"

İşleri kolaylaştırmak için, bu API'ların her birinin giriş ve çıkışlarında gerçekleşen basitleştirilmiş bir veri akışı (ve komutları) düşünelim. En başta bilgisayarınızdan çalıştırdığınız uygulama programınız (derlenmiş kod) vardır. Sonunda ekranınızda görüntülenen görüntüler var.

Bu soruların cevaplarını kısıtlayacağım birkaç durum var: -
grafik fonksiyonlarını işlemek için bilgisayarınızda bir grafik kartı (GPU) veya sadece bir CPU var mı?
-Uygulamanız x-window sisteminin penceresine gömülü mü?
-x pencere sistemini kullanırsanız, "x sunucusu" bilgisayarınızda mı yoksa ağdaki başka bir bilgisayarda mı çalışıyor?
Varsa, GPU'nuz için sürücülere sahip olduğunuzu ve yazılım oluşturma için Mesa'ya sahip olduğunuzu varsayacağım).

İlk senaryo: X Pencere Sistemini kullanmadan OpenInventor ile yazılmış bir grafik uygulamasını çalıştırırsınız ve bir grafik kartınız yoktur. Program akışı şuna benzer:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Mesa
  ↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
  ↓
3D Images on your screen

Burada olanlara "yazılım oluşturma" denir: grafik komutu herhangi bir grafik donanımı tarafından değil, genel olarak yazılımınız olan işlemci tarafından kullanılır.

İkinci senaryo: Şimdi yukarıdaki koşullarla aynı şekilde bir grafik kartınız olduğunu hayal edin. Akış daha çok şöyle görünecektir:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Proprietary Drivers
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Şimdi olanlara "donanım hızlandırma" denir, genellikle ilk senaryodan daha hızlıdır.

Üçüncü senaryo: Şimdi okuduğum birkaç Wikipedia satırına dayanarak X Pencere Sistemi akışını veya en azından nasıl düşündüğümü tanıtalım.
Bir süre grafik donanım ve API'yı unutalım. Akış şöyle görünmelidir:

Your application (X Window System sees it as an "X Client")
  ↓ (sends requests defined by the X Window System Core Protocol)
X Server
  ↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
  ↓
Windows or 2D images on your screen

X Pencere Sistemini kullanırken ekranınızın ve uygulamanızı çalıştırdığınız bilgisayarın "doğrudan" bağlı olmayabileceğini, ancak bir ağ üzerinden bağlanabileceğini unutmayın.

Dördüncü senaryo: bir önceki örnekten X Client uygulamanıza süslü 3B grafik oluşturma eklemek istediğinizi varsayalım. Bana öyle geliyor ki X Pencere Sistemi başlangıçta bunu yapamıyor ya da en azından bir OpenGL API fonksiyonunun eşdeğerini gerçekleştirmek için çok kıvrımlı kod gerektiriyor.
Neyse ki, sisteme OpenGL komutları için destek eklemek için GLX'i kullanabilirsiniz. Artık sizde:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
  ↓ (convert your request to OpenGL commands)
OpenGL
  ↓ (redirects function calls to implementation defined by)
 ...

Artık ilk senaryoda "OpenGL" den sonraki son oku yeniden bağlayabilirsiniz: Ekranınıza 3D görüntüler alabilirsiniz!

Sonunda DRI hakkında ne düşündüğümü hakkında:
Mesa GPU'ya erişmesine izin veriyor gibi görünüyor, böylece ilk senaryonun akışını şu şekilde değiştiririz:

...
  ↓
Mesa
  ↓ (forwards OpenGL commands)
DRI
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Ayrıca, sunucusunun ve istemcisinin aynı bilgisayarda olması ve bir GPU'nuz olması koşuluyla, GLX kullanırken akışı kısa devre yapıyor gibi görünüyor. Bu durumda dördüncü senaryomuzun grafiği basitçe şöyle olur:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
  ↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Bu kadar !
Şimdi Unix ortamlarında uzman olmadığımı unutmayın, bu yüzden en iyi tavsiyem, ne yapabileceğini tam olarak bilmek için bu API'ların her birinin belgelerini incelemek.
Önceki grafiği tek bir grafikle birleştirmek, işlerin daha kolay anlaşılmasını sağlayabilir. Bunu sana bir egzersiz olarak bıraktım!


1
bu sadece birkaç cümlenin çıkarılmasına dayanan bir teoridir. gerçek bu değil.
KawaiKx

8

OpenGL platform agnostiktir; bu OpenGL API'sinin platformdan bağımsız olduğu anlamına gelir.

OpenGL durumları ve arabellekleri genellikle bağlam denilen soyut bir nesne tarafından toplanır.

Barındırma platformu, temel platform için OpenGL içeriği oluşturmak için bazı API sağlamaktan sorumludur. Windows'da wgl * rutinleri (GL için Windows), Unix'te glX * rutinleri (GL for X) vardır.

Aslında GLX, uygulamanın OpenGL API'sini kullanmak için OpenGL içeriği oluşturmasına izin veren bir API'den başka bir şey değildir.

Genel WGL / GLX işlemleri, bir pencere oluşturma, ekran dışı bir arabellek oluşturma, bir iş parçacığında OpenGL bağlamını güncelleştirme, çizme arabelleklerini değiştirme ...

Bunun yerine DRI, XServer'ı geçerek grafik kartı ile doğrudan iletişime izin veren ve aslında uygulamayı OpenGL rutinlerini kullanarak hızlandıran bir çekirdek katmanıdır.


3

http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html

DRI olarak da bilinen Doğrudan Oluşturma Altyapısı, X Pencere Sistemi altındaki grafik donanımına güvenli ve verimli bir şekilde doğrudan erişime izin veren bir çerçevedir. X sunucusunda, çeşitli istemci kitaplıklarında ve çekirdekte (DRM, Direct Rendering Manager) değişiklikler içerir. DRI için en önemli kullanım Mesa için donanım hızlandırması sağlayan hızlı OpenGL uygulamaları oluşturmaktır. 3DFX, AMD (eski adıyla ATI), Intel ve Matrox tarafından üretilen yonga setleri sürücüleri de dahil olmak üzere birkaç 3D hızlandırılmış sürücü DRI spesifikasyonuna yazılmıştır.


2

Basitçe söylemek gerekirse OpenGL, grafik kütüphanesi tipi ve özelliğidir. Mesa temel bir alıştırmadır. DRI bir donanım arayüz sistemidir.

Mesa temel olarak tüm çerçeveyi ifade eder. Ancak, Mesa donanım sürücüsünden bahsettiğinizi varsayacağım.

DRI temel olarak donanımı işlemek için çekirdek arabirimidir. Teknik olarak başka şeyler için kullanılabilir, ancak Mesa için yapılmış ve öncelikle Mesa için kullanılır.

GLX tüm X ile nasıl arabirim !!

Her parçanın ne olduğunu anlamak için, birbirine nasıl uyduğunu bilmelisiniz.

Bir program herhangi bir openGL kütüphanesi ile arayüz oluşturacak şekilde tasarlanmıştır.

GLX, OpenGL'yi X11 ile veya X11 aracılığıyla arayüzlemek için bir araçtır. Bir "Doğrudan" veya "Dolaylı" arayüzünüz olup olmadığına bağlı olarak, programınızın bu konuda endişelenip endişelenmeyeceğine bağlıdır.

libGL bunlar için arayüzdür. Bir Mesa sürücüsü kullanıyorsanız genellikle Mesa tarafından sağlanır.

Dolaylı bir kurulumda şu şekilde gider: Uygulama Çerçevesi (yani, Yazılı uygulama, Motor veya Soyutlama API'sı) | LibGL | Mesa Sürücüsü | DRI | Donanım

Bu yapılandırmada, GLX sadece programınızın GL kullanımı ve diğer programlar arasındaki arabirimi işlemek için kullanılır. X11 yığını ve destek programları (Pencere Yöneticileri gibi) iletişim gerektiren şeyler yapmak için kullanılan GLX'e özgü çağrılar dışında GLX büyük ölçüde dokunulmaz. bu düzenlemede.

Ayrıca, komut geçişi ve paylaşılan bellek, bu sistemdeki katmanları daha da optimize etmek için kullanılabilir. Bu, gecikmeleri azaltır ve donanıma erişim hızını artırır. Genellikle istediğiniz budur.

Dolaylı olarak uygulama çerçeveniz | LibGL (Kullanıcı tarafı) | LibGLX | LibGL (X11 Tarafı) | Mesa Donanım Sürücüsü | DRI | Donanım

Bunun avantajı, bu kurulumu kullanmak için donanım ile doğrudan paylaşılan bir bellek arabelleğine ihtiyacınız olmamasıdır. (Ağ istemcilerinin yanı sıra daha sağlam ve daha güvenli bir kurulum için izin verme.)

Bu kurulum, tek bir video kartını paylaşan hatta ağ üzerinden erişen birden fazla VM'de çalışabilir. Bazı paylaşılan bellek türleri veya sanal paylaşılan "klonlanmış" bellek daha yeni uzantılar nedeniyle kullanılabilir, ancak doğrudan işleme modunda bulunan doğrudan video belleği erişimi değildir.

Dezavantajı, X11 ile arayüz oluşturmak için boruların veya ağ soketlerinin kullanılması yavaş olabilir, en azından iyi optimize edilmiş programlara gecikmeler getirir ve kötü optimize edilmiş olanlarda en kötü, önemli ölçüde azalan kare hızlarıdır.

Bu, ağa bağlı istemciler, daha sağlam güvenlik gerektiren kurulumlar ve birden çok İşletim Sisteminin aynı GL yığınını kullanarak donanım paylaşması gereken kurulumlar için daha iyi bir kurulum türüdür. Optimal olmaktan uzak ama size bir dereceye kadar donanım ivmesi sağlıyor.

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.