Grafik API'lerini çok sık soyutladığımı nasıl bilebilirim?

23

Birden fazla grafik API'sini destekleyen bir oluşturucu oluştururken, genellikle kodunuzu OpenGL, Vulkan, D3D11 vb. Gibi bazı grafik API'leriyle bağlı bir tür düşük seviye kitaplığında soyutlamak istersiniz;

Birbirlerinden çok farklı çalışırlar, bu yüzden iyi bir genel API yapmak zorunlu hale gelir; Tipik olarak, desteklemek istediğiniz her API için temel işlevselliği uygulayan bir "arka uç" ve programcı tarafından programlarda çizim yapmak için kullanılan bir "ön uç" kullanmak istediğinizi okudum. ekran.

Çok sıkı bir soyutlama yapıp yapmadığımı nasıl bilebilirim?

graphics-programming

— Gabriele Vierti
kaynak

5

+ Vulkan veya D3D11 ambalajınızın her zaman OpenGL kullanmaktan daha hızlı olduğundan% 100 emin misiniz?

— Mooing Duck

@Mooing Duck doğru kullanılırsa, evet.

— Gabriele Vierti

4

Bundan ciddi olarak şüphelenirdim. Vulkan'daki kazanımların çoğu çok düşük seviyeli olmaktan ve çok tuhaf, özel bir şekilde şeyler yapmaktan geliyor. OpenGL veya D3D'de de aynısını sorunsuzca yapabilecek kadar jenerik olan bir şey neredeyse kesinlikle yapamaz. OpenGL ile aynı şeyleri tekrar uygulamak (birçok Vulkan öğreticisinin yaptığı gibi, ironik bir şekilde), çalışmanın 20 katı ile aynı performansın% 99,99'unu oluşturur.

— Damon,

@Damon bu doğru, ancak daha yeni API'ler modern gpus üzerinde çalışmak üzere özel olarak tasarlanmış (ve OpenGL gibi uyarlanmamış ); Vulkan bahsederken şunları yapabilirsiniz hemen hemen bilâkis siz "Gömülü Sistemler" sürümünü kullanmanız gerekir OpenGL, kadar her desteklenen platformda aynı API kullanmak. Daha az işlemci yükü ve fantezi özellikleri dışında fazla bir şeyimiz yok, ancak gelecekte OGL veya D3D11 yerine Vk veya D3D12 kullanarak daha hızlı çalışabilecek bazı şaşırtıcı tekniklere sahip olabiliriz

— Gabriele Vierti

44

Her şeyden önce, birden fazla grafik API'sini desteklemenin gerçekten değip değmeyeceğini düşünün. Sadece OpenGL'i kullanmak çoğu platformu kapsayacak ve grafiksel olarak en iddialı projeler dışında herkes için "yeterince iyi" olacaktır. Birden fazla render arka ucunu uygulamak ve test etmek için birkaç bin kişiyi batırmayı başarabilen çok büyük bir oyun stüdyosu için çalışmadığınız sürece ve gerçekten göstermek istediğiniz DirectX veya Vulcan'a özgü bazı özellikler olmadıkça , genellikle uğraşmaya değmez . Özellikle başkasının yarattığı bir soyutlama katmanını (3. parti bir kütüphane veya oyun motoru) kullanarak çok fazla iş tasarrufu yapabileceğinizi düşünün.

Ancak, seçeneklerinizi zaten değerlendirdiğinizi ve kendi kararınızı vermenin hem uygun hem de zamanının değerli olduğu sonucuna vardığınızı varsayalım.

Öyleyse, soyutlama katmanınızın yazılım mimarisinin ana hakimi, ön uç programcılarınızdır.

Uygulamak istedikleri oyun sistemlerini herhangi bir düşük seviye detayı merak etmeden uygulayabiliyorlar mı?
Birden fazla grafik API'si olduğunu tamamen görmezden gelebilirler mi?
Ön kodlardan herhangi birini değiştirmeden başka bir oluşturma arka ucu eklemek teorik olarak mümkün olabilir mi?

Eğer öyleyse, başardın.

— Philipp
kaynak

2

Ek bir öneri: hedefin, mermi noktalarındaki hedeflere minimum çaba ile ulaşmak - sadece hedefe ulaşmak ve daha fazla ileri gitmek değil mi? Aksi halde, bunlardan her biri (kendim de dahil olmak üzere) genellikle ne zaman yalnız yeterince iyi ayrılacağını bilmeyen tipik geliştirici için bir tavşan deliğine dönüşebilir. :) Ayrıca başarıyı değerlendirmenin tek güvenilir yolu, API'yi gerçek kullanıcılar ile yinelemeli olarak geliştirmek ve test etmektir ; doğru tahmin etmek imkansızdır ve aşırı mühendislik için bir tavşan deliği senaryosuna yol açar.

— bob

5

Gerçekten, eğer birden fazla grafik kütüphanesini gerçekten desteklemek zorundaysanız , ihtiyacınız olan her şeyi yapan neredeyse kesinlikle kullanıma hazır bir tane var, o zaman bile gerçekten kendinize ait bir şey yapmamalısınız. (Tabii ki, istisnalar da var, ancak "bir soyutlamanın ne kadar sıkı yapmam gerektiğini" soracak kadar deneyimsizseniz, muhtemelen bunu yapmanızı gerektiren bir proje üzerinde çalışmıyorsunuzdur)

— Fon Monica'nın

Ben bir grafik dev değilim, ancak veri tabanları ve işletim sistemleri geçmişinden uyumluluk çerçevelerine bakarak, kendi genel çerçevenizi yapmanın neredeyse kesinlikle değmeyeceğini de eklerim . Çerçeve neredeyse kesinlikle uyumluluk için performanstan fedakarlık etmek zorunda kalacak, bu da muhtemelen bu özel özelliklerle zaten pek bir şey yapamayacağınız anlamına geliyor. Mevcut çerçeveler, daha geniş kullanım nedeniyle bu sorunları daha iyi ele almak için neredeyse kesindir. Şimdi, büyük bir bütçeniz varsa, tarif edersiniz ve özel bir çerçeve (örneğin, bir oyun veya dizi için) oluşturmak isterseniz , bu daha yapılabilir olabilir.

— jpmc26

6

API'nin "sarmalayıcı" bölümünden gerçekte neye ihtiyacınız olduğunu belirleyerek başlayın. Genel olarak çok, çok basit: temel kaynaklara (arabellek, gölgelendirici, doku, boru hattı durumu) ve bazı arama çağrıları göndererek bir çerçeve oluşturmak için bu kaynakları kullanmanın bir yoluna ihtiyacınız var.

Herhangi bir yüksek seviyeli mantık tutmaya çalışın dışına API sarıcı kısmı. API'nin bu bölümünde zeki bir sahne temizleme tekniği uygularsanız, artık tüm arka uç uygulamalarında bu mantığı çoğaltmak için hazırsınız. Bu çok fazla çaba, bu yüzden basit olsun. Sahne yönetimi , sargının kendisinin bir parçası olmak yerine sargısını kullanan API'nin daha üst bir bölümünün parçası olmalıdır .

Destekleyeceğiniz hedefleri seçin ve onları anlayın. "Her şey" için uygun sarmalayıcılar yazmak zor ve muhtemelen gerekmeyecek (belki de Philipp'in cevabında da belirtildiği gibi tek bir sarmalayıcı yazmanıza gerek yok ). Zaten saracağınız API'ları bilmiyorsanız, iyi bir sarmalayıcı yazmak neredeyse imkansızdır.

API'nizin durumunu düzenli olarak değerlendirin. Genel olarak, altta bulunan sarılmış API'lerden daha küçük bir yüzey alanına sahip olmalıdır; Kendinizi her D3D yapısı veya her OpenGL işlev çağrısı için bire bir sarıcı türleri oluştururken bulursanız, muhtemelen yoldan sapmış olursunuz.

Daha önce ne işe yaradığına bir bak. Sokol ve BGFX, sizin için yararlı olabilecek ve özellikle kolay anlaşılması kolay olan agnostiklik düzeyleri sağlayan API'lerdir.

— alay etmek
kaynak

3

Göz önünde bulundurmanız gereken henüz bahsetmediğiniz bir diğer nokta, performans hedeflerinizin ne olduğudır. Amacınız, ucuz bir donanım platformundan iyi performans getirecek bir grafik kütüphanesine sahip olmak, ancak aynı zamanda çok daha güçlü ancak farklı bir API kullanan çeşitli platformlarda da kullanılabilecek bir grafik kitaplığına sahip olmaksa, API'nizin etrafını tasarlamak mantıklı gelebilir. Performansın önemli olduğu platformda yerel olarak kullanılan soyutlamalar. Bu, daha güçlü platformlarda% 50'lik bir hız bozulmasına neden olsa bile, performansın en önemli olduğu platformda% 20'lik bir hız artışına izin veriyorsa buna değer olabilir.

— SuperCat
kaynak