Doğrudan İşleme Altyapısı - Direct Rendering Infrastructure

DRI-1.0
Orijinal yazar (lar)Precision Insight, Tungsten Graphics
Geliştirici (ler)freedesktop.org
İlk sürümAğustos 1998; 22 yıl önce (1998-08)[1]
Kararlı sürüm
2.4.x / Şubat 2009
YazılmışC
PlatformPOSIX
TürÇerçeve / API
LisansMIT ve diğer lisanslar[2]
İnternet sitesidri.freedesktop.org
DRI-2.0
Orijinal yazar (lar)Kristian Høgsberg et al.
Geliştirici (ler)freedesktop.org
İlk sürüm4 Eylül 2008; 12 yıl önce (2008-09-04)[3]
Kararlı sürüm
2.8 / 11 Temmuz 2012; 8 yıl önce (2012-07-11)[4]
YazılmışC
PlatformPOSIX
TürÇerçeve / API
LisansMIT ve diğer lisanslar[2]
İnternet sitesidri.freedesktop.org
DRI-3.0
Orijinal yazar (lar)Keith Packard et al.
Geliştirici (ler)freedesktop.org
İlk sürüm1 Kasım 2013; 7 yıl önce (2013-11-01)[5]
Kararlı sürüm
1.0 / 1 Kasım 2013; 7 yıl önce (2013-11-01)[5]
YazılmışC
PlatformPOSIX
TürÇerçeve / API
LisansMIT ve diğer lisanslar[2]
İnternet sitesidri.freedesktop.org
İki grafik donanım sürücüsü vardır: biri X'in içinde bulunur görüntü sunucusu. Bu sürücünün birkaç tasarımı vardı. Mevcut olan, onu iki bölüme ayırır: DIX (Cihazdan Bağımsız X) ve DDX (Cihaza Bağlı X)
Cazibe basitleştirecek X sunucusu, ve libGL-fglrx-glx tescilli yerine radeon açık kaynak sürücüsünün libDRM'sini kullanabilir ikili blob.
Rendering hesaplamalar için dış kaynak OpenGL için GPU gerçek zamanlı olarak yapılacak. DRI erişimi ve defter tutmayı düzenler.

Doğrudan İşleme Altyapısı (DRI) doğrudan erişime izin veren bir çerçevedir grafik donanımı altında X Pencere Sistemi güvenli ve verimli bir şekilde.[6] DRI'nin ana kullanımı, cihaz için donanım hızlandırma sağlamaktır. Mesa uygulanması OpenGL. DRI, aynı zamanda OpenGL hızlandırma sağlamak için de uyarlanmıştır. framebuffer konsolu olmadan görüntü sunucusu koşuyor.[7]

DRI uygulaması, X Sunucusu ve ilişkili istemci kitaplıkları, Mesa 3D ve Doğrudan Oluşturma Yöneticisi çekirdek alt sistemi.[6] Hepsi kaynak kodu dır-dir ücretsiz yazılım.

Genel Bakış

Klasik olarak X Pencere Sistemi mimari, X Sunucusuna özel erişime sahip tek süreçtir. grafik donanımı ve bu nedenle gerçek olanı yapan işleme üzerinde framebuffer. X istemcilerinin yaptığı tek şey, işleme komutlarını göndermek için X Sunucusu ile iletişim kurmaktır. Bu komutlar donanımdan bağımsızdır, yani X11 protokolü sağlar API Bu, grafik aygıtını soyutlar, böylece X istemcilerinin temeldeki donanımın özelliklerini bilmesine veya endişelenmesine gerek kalmaz. Herhangi bir donanıma özgü kod, Cihaz Bağımlı X, X Sunucusunun her tür video kartı veya grafik bağdaştırıcısını yöneten ve aynı zamanda genellikle video veya grafik sürücüsü.

Yükselişi 3B oluşturma bu mimarinin sınırlarını göstermiştir. 3D grafik uygulamaları büyük miktarlarda komut ve veri üretme eğilimindedir, bunların tümü işleme için X Sunucusuna gönderilmelidir. Miktarı olarak arası iletişim X istemcisi ve X Sunucusu arasındaki (IPC) arttı, 3B oluşturma performansı, X sürücü geliştiricilerinin en son grafik kartlarının 3B donanım yeteneklerinden yararlanmak için yeni bir IPC'siz mimariye ihtiyaç duyduğu sonucuna vardıkları noktaya kadar düştü. X istemcileri, tüm IPC ek yükünü koruyarak, üçüncü şahıs işlemlerine güvenmek yerine grafik donanımına doğrudan erişime sahip olmalıdır. Bu yaklaşım, klasik X mimarisi tarafından sağlanan "dolaylı oluşturma" nın aksine "doğrudan işleme" olarak adlandırılır. Doğrudan İşleme Altyapısı başlangıçta herhangi bir X istemcisinin bu "doğrudan oluşturma" yaklaşımını kullanarak 3B oluşturma gerçekleştirmesine izin vermek için geliştirilmiştir.

DRI'nin bir X istemcisinde hızlandırılmış 2B doğrudan işlemeyi uygulamak için kullanılmasını hiçbir şey engellemez.[3] Basitçe, 2D dolaylı işleme performansı yeterince iyi olduğu için kimsenin buna ihtiyacı yoktu.

Yazılım mimarisi

Doğrudan İşleme Altyapısının temel mimarisi üç ana bileşenden oluşur:[8]

  • DRI istemcisi - "doğrudan işleme" gerçekleştiren bir X istemcisi - üzerinde işlemek için mevcut video kartını veya grafik adaptörünü yönetebilen, donanıma özgü bir "sürücüye" ihtiyaç duyar. Bunlar DRI sürücüleri tipik olarak şu şekilde sağlanır paylaşılan kitaplıklar müşterinin olduğu dinamik olarak bağlantılı. DRI, 3B grafik donanımından yararlanmak üzere tasarlandığından, kitaplıklar normalde istemcilere 3B API'nin donanım hızlandırmalı uygulamaları olarak sunulur. OpenGL, 3D donanım satıcısının kendisi veya aşağıdaki gibi bir üçüncü tarafça sağlanır: Mesa 3D ücretsiz yazılım proje.
  • X Sunucusu, bir X11 protokol uzantısı - DRI uzantı - DRI istemcilerinin hem pencere sistemi ve DDX sürücüsü.[9] DDX sürücüsünün bir parçası olarak, X Server işleminin aynı zamanda DRI istemcileriyle aynı DRI sürücüsüne dinamik olarak bağlanması oldukça yaygındır, ancak X istemcilere donanım hızlandırmalı 3B oluşturma GLX dolaylı işleme için uzantı (örneğin, doğrudan oluşturmayı kullanamayan uzak X istemcileri). 2D oluşturma için DDX sürücüsü, aynı grafik aygıtını kullanan DRI istemcilerini de hesaba katmalıdır.
  • video kartına veya grafik bağdaştırıcısına erişim, şu adı verilen bir çekirdek bileşeni tarafından düzenlenir: Doğrudan Oluşturma Yöneticisi (DRM).[10] Hem X Sunucusunun DDX sürücüsü hem de her X istemcisinin DRI sürücüsü, grafik donanımına erişmek için DRM kullanmalıdır. DRM sağlar senkronizasyon grafik donanımının paylaşılan kaynaklarına - komut kuyruğu, kart kayıtları, video belleği, DMA motorları gibi kaynaklar - tüm bu birden çok rakip kullanıcı alanı işleminin eşzamanlı erişiminin çakışmamasını sağlamak herbiri. DRM ayrıca, herhangi bir X istemcisinin donanıma 3B oluşturmayı gerçekleştirmek için ihtiyaç duyduğunun ötesinde erişmesine izin vermeyen temel bir güvenlik uygulayıcısı olarak hizmet eder.

DRI1

Orijinal DRI mimarisinde, bellek boyutundan dolayı video kartları o sırada ekranın tek bir örneği vardı ön tampon ve arka tampon (ayrıca yardımcı derinlik tamponu ve şablon arabelleği ), tüm DRI istemcileri ve X Sunucusu tarafından paylaşılır.[11][12] Hepsi doğrudan arka arabelleğe işlendi, yani değiş tokuş ön tampon ile dikey boşluk aralığı zaman.[11] Arka arabelleğe işlemek için, bir DRI işlemi, oluşturma işleminin kırpılmış için ayrılmış alana pencere.[11][12]

senkronizasyon X Sunucusuyla sinyaller ve bir paylaşılan hafıza SAREA adı verilen tampon.[12] DRM cihazına erişim özeldi, bu nedenle herhangi bir DRI istemcisinin kilit başlangıcında işleme operasyon. Cihazın diğer kullanıcıları (X Sunucusu dahil) bu arada engellendi ve her iki işlem arasında herhangi bir çakışma olmasa bile mevcut oluşturma işleminin sonunda kilit serbest kalana kadar beklemek zorunda kaldılar.[12] Diğer bir dezavantaj, mevcut DRI işlemi cihazdaki kilidini serbest bıraktıktan sonra işlemlerin bellek ayırmalarını korumamasıydı, bu nedenle grafik belleğine yüklenen veriler dokular yaklaşan işlemler için kaybedildi ve grafik performansı üzerinde önemli bir etkiye neden oldu.

Günümüzde DRI1 tamamen modası geçmiş olarak kabul edilmektedir ve kullanılmamalıdır.

DRI2

Artan popülaritesi nedeniyle pencere yöneticileri birleştirme sevmek Compiz, Doğrudan İşleme Altyapısının yeniden tasarlanması gerekiyordu, böylece X istemcileri doğrudan işleme yaparken "ekran dışı piksel haritalarına" yönlendirmeyi de destekleyebilirdi. Sıradan X istemcileri, X Sunucusu tarafından bir işleme hedefi olarak sağlanan ayrı bir piksel haritasına yeniden yönlendirmeye saygı duydu - sözde ekran dışı piksel haritası -, ancak DRI istemcileri, oluşturma işlemini doğrudan paylaşılan arka tamponda yapmaya devam ederek, birleştirme pencere yöneticisini etkin bir şekilde atladı.[11][13] Nihai çözüm, DRI'nin render arabelleklerini işleme şeklini değiştirmekti, bu da yeni bir işlem setiyle tamamen farklı bir DRI uzantısına ve ayrıca Doğrudan Oluşturma Yöneticisi.[3] Yeni uzantı "DRI2" olarak adlandırıldı, ancak daha sonraki bir sürüm olmasa da, orijinal DRI ile uyumlu olmayan farklı bir uzantı - aslında her ikisi de uzun süredir X Sunucusunda bir arada var oldu.

DRI2'de, tek bir paylaşılan (geri) arabellek yerine, her DRI istemcisi kendi özel özelliğine sahip olur arka tampon[11][12] - ilişkili oldukları derinlik ve şablon arabellekler— işlemek için pencere kullanan içerik donanım ivmesi. DRI istemcisi daha sonra takas yanlışla "ön tampon ",[12] Bu, birleştirme penceresi yöneticisi tarafından, değiştirilecek son ekran geri arabelleğini oluşturmak (oluşturmak) için kaynaklardan biri olarak kullanılır. VBLANK aralığı gerçek ön tampon ile.

Tüm bu yeni arabelleklerin üstesinden gelmek için, Direct Rendering Manager'ın yeni işlevler, özellikle bir grafik hafıza yöneticisi. DRI2 başlangıçta deneysel olarak geliştirildi TTM hafıza yöneticisi,[11][13] ama daha sonra kullanılmak üzere yeniden yazıldı GEM kesin DRM bellek yöneticisi olarak seçildikten sonra.[14] Yeni DRI2 dahili tampon yönetimi modeli, orijinal DRI uygulamasında bulunan iki büyük performans darboğazını da çözdü:

  • DRI2 istemcileri artık oluşturma için kullanırken DRM aygıtının tamamını kilitlemiyor, çünkü artık her istemci diğer işlemlerden bağımsız olarak ayrı bir işleme tamponu alıyor.[12]
  • DRI2 istemcileri, video belleğinde kendi arabelleklerini (dokular, köşe listeleri, ...) ayırabilir ve istedikleri kadar uzun süre saklayabilir, bu da videoyu önemli ölçüde azaltır bellek bant genişliği tüketim.

DRI2'de, bir pencere için özel ekran dışı tamponların (arka tampon, sahte ön tampon, derinlik tamponu, şablon tamponu, ...) tahsisi X Sunucusunun kendisi tarafından yapılır.[15][16] DRI istemcileri, aşağıdaki gibi işlemleri çağırarak pencereye işleme yapmak için bu arabellekleri alırlar. DRI2GetBuffers ve DRI2GetBuffersWithFormat DRI2 uzantısında mevcuttur.[3] DRI2 dahili olarak GEM adları - tarafından sağlanan bir tür genel tutamaç GEM API Bu, bir DRM cihazına erişen iki işlemin aynı arabelleğe başvurmasına izin verir - bu arabelleklere "başvurular" arasında geçiş yapmak için X11 protokolü.[16] X Sunucusunun, bir pencerenin oluşturma tamponlarının arabellek tahsisinden sorumlu olmasının nedeni, GLX uzantısı birden çok X istemcisinin yapmasına izin verir OpenGL aynı pencerede işbirliği içinde işleme.[15] Bu şekilde, X Sunucusu, tüm işleme süreci boyunca işleme arabelleklerinin tüm yaşam döngüsünü yönetir ve bunları ne zaman güvenli bir şekilde geri dönüştürebileceğini veya atabileceğini bilir. Bir pencere yeniden boyutlandırma gerçekleştirildiğinde, X Sunucusu aynı zamanda yeni pencere boyutuyla eşleşen yeni oluşturma arabelleklerini tahsis etmekten ve DRI istemcilerindeki değişikliği bir InvalidateBuffers olayını kullanarak pencereye iletmekten ve böylece GEM'i almaktan sorumludur. yeni tamponların isimleri.[15]

DRI2 uzantısı, DRI istemcileri için hangi DRM aygıtını ve sürücüsünü kullanmaları gerektiğini bulmak gibi diğer temel işlemleri sağlar (DRI2Connect) veya DRM cihazının işleme ve arabellek olanaklarını kullanabilmek için X Sunucusu tarafından doğrulanması (DRI2Authenticate).[3] Oluşturulan tamponların ekranda sunumu, DRI2CopyRegion ve DRI2SwapBuffers istekleri. DRI2CopyRegion sahte ön tampon ve gerçek ön tampon arasında bir kopya yapmak için kullanılabilir, ancak dikey boşluk aralığı ile herhangi bir senkronizasyon sağlamaz, bu nedenle yırtılma. DRI2SwapBuffersÖte yandan, destekleniyorsa ve her iki arabellek de aynı boyuttaysa veya bir kopyaya sahipse, arka ve ön arabellek arasında VBLANK ile senkronize bir takas gerçekleştirir (yıldırım ) aksi takdirde.[3][15]

DRI3

DRI2, orijinal DRI'ye göre önemli bir gelişme olsa da, yeni uzantı bazı yeni sorunları da beraberinde getirdi.[15][16] 2013 yılında, bu sorunları gidermek için DRI3 olarak bilinen Doğrudan İşleme Altyapısının üçüncü bir yinelemesi geliştirildi.[17]

DRI3'ün DRI2'ye kıyasla temel farklılıkları şunlardır:

  • DRI3 istemcileri, ayırmayı yapmak için X Sunucusuna güvenmek yerine kendi işleme arabelleklerini tahsis ederler - DRI2 tarafından desteklenen yöntem buydu.[15][16]
  • DRI3 eski güvensizlikten kurtulur GEM dayalı tampon paylaşım mekanizması GEM adları (global GEM handles) bir DRI istemcisi ile X Sunucusu arasında arabellek nesnelerini geçmek için daha güvenli ve çok yönlü bir PRIME DMA-BUF'ler, hangi kullanır dosya tanımlayıcıları yerine.[15][16]

İstemci tarafında ara bellek tahsisi GLX Birden fazla GLX uygulamasının aynı pencerede işbirliği içinde işlenmesinin artık mümkün olmadığı varsayımları. Artı tarafta, DRI istemcisinin yaşamları boyunca kendi tamponlarından sorumlu olması gerçeği birçok avantajı beraberinde getiriyor. Örneğin, DRI3 istemcisinin, oluşturma arabelleklerinin boyutunun her zaman pencerenin geçerli boyutuyla eşleşmesini sağlaması ve böylece istemci ile sunucu arasında pencere yeniden boyutlandırmasını engelleyen arabellek boyutlarının senkronizasyonunun olmamasından kaynaklanan yapıları ortadan kaldırması kolaydır. DRI2'de.[15][16][18] DRI3 istemcileri artık X Sunucusunun işleme arabelleklerini göndermesini beklerken fazladan gidiş-dönüşten tasarruf ettikleri için daha iyi bir performans da elde edilir.[16] DRI3 istemcileri ve özellikle birleştirici pencere yöneticileri, önceki çerçevelerin eski arabelleklerini tutma ve bunları bir pencerenin yalnızca hasarlı kısımlarını başka bir performans optimizasyonu olarak işlemek için temel olarak yeniden kullanma avantajından yararlanabilir.[15][16] DRI3 uzantısının, artık doğrudan DRI istemci sürücüsü ile DRM çekirdek sürücüsü arasında işlendiğinden, yeni belirli arabellek biçimlerini desteklemek için değiştirilmesine gerek yoktur.[15] Diğer yandan dosya tanımlayıcılarının kullanılması, çekirdeğin kullanılmayan herhangi bir GEM arabellek nesnesinin güvenli bir temizlemesini gerçekleştirmesine izin verir - buna referans olmadan.[15][16]

Teknik olarak, DRI3 iki farklı uzantıdan oluşur, "DRI3" uzantısı ve "Mevcut" uzantı.[17][19] DRI3 uzantısının temel amacı, DRI istemcileri ve X Sunucusu arasında doğrudan işlenmiş arabellekleri paylaşma mekanizmasını uygulamaktır.[18][19][20] DRI istemcileri, işleme hedefleri olarak GEM arabellekleri nesnelerini tahsis eder ve kullanır, X Sunucusu ise "pixmap" adı verilen bir X11 nesnesi türü kullanarak bu oluşturma arabelleklerini temsil eder. DRI3 iki işlem sağlar, DRI3PixmapFromBuffer ve DRI3BufferFromPixmap, biri bir GEM arabellek nesnesinden ("DRI istemci alanında") bir piksel eşlemesi ("X Sunucu alanında") oluşturmak, diğeri ise tersini yapmak ve bir X piksel eşleminden bir GEM arabellek nesnesi almak için.[18][19][20] Bu DRI3 işlemlerinde GEM tampon nesneleri, DMA-BUF GEM adları yerine dosya tanımlayıcıları. DRI3 ayrıca, senkronizasyon nesnelerini DRI istemcisi ile X Sunucusu arasında paylaştırmak için bir yol sağlayarak, paylaşılan arabelleğe hem serileştirilmiş bir erişim sağlar.[19] DRI2'den farklı olarak, ilk DRI3Açık İşlem - her DRI istemcisinin hangi DRM aygıtını kullanacağını bilmek istemesi gereken ilk işlem - aygıt düğümü dosya adı yerine aygıt düğümüne zaten açık olan bir dosya tanımlayıcısını döndürür ve gerekli kimlik doğrulama prosedürü önceden X Sunucusu tarafından gerçekleştirilmiştir.[18][19]

DRI3, oluşturulan arabellekleri ekranda göstermek için bir mekanizma sağlamaz, ancak başka bir uzantıya dayanır, Mevcut uzantısı, bunu yapmak için.[20] Mevcut bu şekilde adlandırılır çünkü ana görevi ekranda tamponları "sunmak", yani çerçeve tamponunun güncellemesini istemci uygulamaları tarafından teslim edilen işlenmiş tamponların içeriğini kullanarak yönetir.[19] Ekran güncellemelerinin uygun zamanda, normal olarak VBLANK aralığı gibi görüntü yapaylıklarından kaçınmak için yırtılma. Present ayrıca ekran güncellemelerinin VBLANK aralığına senkronizasyonunu da yönetir.[21] Ayrıca, X istemcisini olayları kullanarak her arabelleğin ekranda gerçekten gösterildiği an hakkında bilgilendirir, böylece müşteri oluşturma sürecini mevcut ekran yenileme hızıyla senkronize edebilir.

Present, herhangi bir X pixmap'i ekran güncellemesinin kaynağı olarak kabul eder.[21] Piksel eşlemleri standart X nesneleri olduğundan Present, yalnızca doğrudan işleme gerçekleştiren DRI3 istemcileri tarafından değil, aynı zamanda herhangi bir yöntemle bir piksel haritası üzerinde herhangi bir X istemcisi oluşturma tarafından da kullanılabilir.[18] Örneğin, çoğu mevcut olmayanGL dayalı GTK + ve Qt yapılan uygulamalar çift ​​tamponlu kullanarak pixmap oluşturma XRender. Present uzantısı, bu uygulamalar tarafından verimli ve yırtılmayan ekran güncellemeleri elde etmek için de kullanılabilir. Present'ın DRI3'ün bir parçası olmak yerine ayrı bir bağımsız uzantı olarak geliştirilmesinin nedeni budur.[18]

GL X olmayan istemcilerin VBLANK ile senkronize olmasına izin vermenin yanı sıra, Present başka avantajlar da getiriyor. DRI3 grafik performansı daha iyidir çünkü Present, arabellek değiştirmede DRI2'den daha verimlidir.[19] DRI2 ile kullanılamayan bir dizi OpenGL uzantısı artık Present tarafından sağlanan yeni özelliklere göre destekleniyor.[19]

Present, X istemcilerine iki ana işlem sağlar: bir piksel haritasının bir kısmını veya tamamını kullanarak bir pencerenin bir bölgesini güncelleyin (PresentPixmap) ve müşterinin bilgilendirilmek istediği belirli bir pencere ile ilgili sunum olaylarının türünü ayarlayın (PresentSelectInput).[19][21] Bir pencerenin bir X istemcisini bilgilendirebileceği üç sunum olayı vardır: devam eden bir sunum işlemi - normal olarak bir aramadan PresentPixmap- tamamlandı (PresentCompleteNotify), bir piksel haritası tarafından kullanıldığında PresentPixmap işlem yeniden kullanılmaya hazır (PresentIdleNotify) ve pencere yapılandırması (çoğunlukla pencere boyutu) değiştiğinde (PresentConfigureNotify).[19][21] Bir PresentPixmap işlem doğrudan bir kopyalama gerçekleştirir (yıldırım ) ön tampona veya takas DRI2'de olduğu gibi X istemcisinin açık bir seçimi yerine, ön arabelleğe sahip tüm arka arabelleğin tamamı, Present uzantı uygulamasının dahili bir detayıdır.

Benimseme

Aşağıdakiler de dahil olmak üzere birkaç açık kaynak DRI sürücüsü yazılmıştır. ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 üzerinden Voodoo5, Matrox G200'den G400'e, SiS 300 serisi, Intel i810 ile i965 arası, S3 Savage, ÜZERİNDEN UniChrome grafik yonga setleri ve Nouveau için Nvidia. Bazı grafik satıcıları kapalı kaynak DRI sürücüleri yazmıştır. ATI ve Kyro.

DRI'nin çeşitli sürümleri, diğerlerinin yanı sıra, çeşitli işletim sistemleri tarafından uygulanmıştır. Linux çekirdeği, FreeBSD, NetBSD, OpenBSD, ve OpenSolaris.

Tarih

Proje, Precision Insight'tan Jens Owen ve Kevin E. Martin tarafından başlatıldı (finanse eden Silikon Grafikler ve Kırmızı şapka ).[1][22] İlk olarak, XFree86 4.0[1][23] ve şimdi X.Org Sunucusu. Şu anda tarafından korunmaktadır özgür yazılım topluluğu.

DRI2 üzerine çalışmalar, 2007 X Developers 'Summit'te Kristian Høgsberg önerisi.[24][25] Høgsberg, yeni DRI2 uzantısını ve Mesa ve GLX.[26] Mart 2008'de DRI2 çoğunlukla yapıldı,[27][28][29] ama başaramadı X.Org Sunucusu sürüm 1.5[14] ve Şubat 2009'dan itibaren 1.6 sürümüne kadar beklemek zorunda kaldı.[30] DRI2 uzantısı resmi olarak Ekim 2009 X11R7.5 sürümüne dahil edildi.[31] DRI2 protokolünün (2.0) ilk halka açık sürümü Nisan 2009'da duyuruldu.[32] O zamandan beri, Temmuz 2012'den itibaren en son sürüm 2.8 olan çeşitli revizyonlar yapıldı.[4]

DRI2'nin çeşitli sınırlamaları nedeniyle, DRI-Next adlı yeni bir uzantı, 2012 X.Org Geliştirici Konferansı'nda Keith Packard ve Eric Anholt tarafından önerildi.[15] Uzantı, DRI3000 olarak yeniden önerildi Linux.conf.au 2013.[16][17] DRI3 ve Present uzantıları 2013'te geliştirildi ve Aralık 2013'ten itibaren X.Org Server 1.15 sürümüyle birleştirildi.[33][34] DRI3 protokolünün (1.0) ilk ve tek sürümü Kasım 2013'te yayınlandı.[5]

Ayrıca bakınız

Referanslar

  1. ^ a b c Owen, Jens. "DRI proje geçmişi". DRI projesi wiki. Alındı 16 Nisan 2016.
  2. ^ a b c Mesa DRI Lisansı / Telif Hakkı Bilgileri - Mesa 3D Grafik Kitaplığı
  3. ^ a b c d e f Høgsberg, Kristian (4 Eylül 2008). "DRI2 Uzantısı - Sürüm 2.0". X.Org. Alındı 29 Mayıs 2016.
  4. ^ a b Airlie, Dave (11 Temmuz 2012). "[DUYURU] dri2proto 2.8". xorg-duyuru (Mail listesi).
  5. ^ a b c Packard, Keith (1 Kasım 2013). "[DUYURU] dri3proto 1.0". xorg-duyuru (Mail listesi).
  6. ^ a b "Mesa 3D ve Direct Rendering Infrastructure wiki". Alındı 15 Temmuz 2014.
  7. ^ "Framebuffer Konsolları için DRI". Alındı 4 Ocak 2019.
  8. ^ Martin, Kevin E .; Faith, Rickard E .; Owen, Jens; Akin, Allen (11 Mayıs 1999). "Doğrudan İşleme Altyapısı, Düşük Seviye Tasarım Dokümanı". Alındı 18 Mayıs 2016.
  9. ^ Owen, Jens; Martin, Kevin (11 Mayıs 1999). "Doğrudan Oluşturmayı desteklemek için DRI Uzantısı - Protokol Belirtimi". Alındı 18 Mayıs 2016.
  10. ^ Faith, Rickard E. (11 Mayıs 1999). "Doğrudan Oluşturma Yöneticisi: Doğrudan İşleme Altyapısı için Çekirdek Desteği". Alındı 18 Mayıs 2016.
  11. ^ a b c d e f Packard, Keith (21 Temmuz 2008). "X çıktı durumu temmuz 2008". Alındı 26 Mayıs 2016.
  12. ^ a b c d e f g Packard, Keith (24 Nisan 2009). "Intel Sürücü Odağını Keskinleştirme". Alındı 26 Mayıs 2016.
  13. ^ a b Høgsberg, Kristian (8 Ağustos 2007). "Yönlendirilmiş doğrudan oluşturma". Alındı 25 Mayıs 2016.
  14. ^ a b Høgsberg, Kristian (4 Ağustos 2008). "DRI2'yi sunucu 1.5'ten yedekleme". xorg (Mail listesi).
  15. ^ a b c d e f g h ben j k l Packard, Keith (28 Eylül 2012). "DRI.Next hakkında düşünceler". Alındı 26 Mayıs 2016.
  16. ^ a b c d e f g h ben j Willis, Nathan (11 Şubat 2013). "LCA: X-Men konuşur". LWN.net. Alındı 26 Mayıs 2016.
  17. ^ a b c Packard, Keith (19 Şubat 2013). "DRI3000 - Daha da İyi Doğrudan İşleme". Alındı 26 Mayıs 2016.
  18. ^ a b c d e f Packard, Keith (4 Haziran 2013). "DRI3 Uzantısının Tamamlanması". Alındı 31 Mayıs 2016.
  19. ^ a b c d e f g h ben j Edge, Jake (9 Ekim 2013). "DRI3 ve Mevcut". LWN.net. Alındı 26 Mayıs 2016.
  20. ^ a b c Packard, Keith (4 Haziran 2013). "DRI3 Uzantısı - Sürüm 1.0". Alındı 30 Mayıs 2016.
  21. ^ a b c d Packard, Keith (6 Haziran 2013). "Mevcut Uzantı - Sürüm 1.0". Alındı 1 Haziran 2016.
  22. ^ Owen, Jens; Martin, Kevin E. (15 Eylül 1998). "3B için Multipipe Direct Rendering Architecture". Alındı 16 Nisan 2016.
  23. ^ "XFree86 4.0 için Sürüm Notları". XFree86 Projesi. 7 Mart 2000. Alındı 16 Nisan 2016.
  24. ^ "X Developers 'Summit 2007 - Notlar". X.Org. Alındı 7 Mart 2016.
  25. ^ Høgsberg, Kristian (3 Ekim 2007). "DRI2 Tasarım Wiki Sayfası". xorg (Mail listesi).
  26. ^ Høgsberg, Kristian (4 Şubat 2008). "DRI2 çalışmasını birleştirme planları". xorg (Mail listesi).
  27. ^ Høgsberg, Kristian (15 Şubat 2008). "DRI2 uygulandı". xorg (Mail listesi).
  28. ^ Høgsberg, Kristian (31 Mart 2008). "DRI2 doğrudan işleme". xorg (Mail listesi).
  29. ^ Høgsberg, Kristian (31 Mart 2008). "DRI2 Doğrudan Oluşturma". Alındı 20 Nisan 2016.
  30. ^ "Sunucu 1.6 dalı". X.org. Alındı 7 Şubat 2015.
  31. ^ "X11R7.5 için Sürüm Notları". X.Org. Alındı 20 Nisan 2016.
  32. ^ Høgsberg, Kristian (20 Nisan 2009). "[DUYURU] dri2proto 2.0". xorg-duyuru (Mail listesi).
  33. ^ Packard, Keith. "[DUYURU] xorg-server 1.14.99.901". X.org. Alındı 9 Şubat 2015.
  34. ^ Larabel, Michael. "X.Org Sunucusu 1.15 Sürümünün Birkaç Yeni Özelliği Var". Phoronix. Alındı 9 Şubat 2015.

Dış bağlantılar