Vulkan API'sine Kısa Bir Bakış

Peki, bu yeni Vulkan API'sinin ne önemi var ve neden umursayalım ki?

Yüzlerce veya daha az kelimeyle Vulkan API'sini burada bulabilirsiniz: Bu, 3D grafikler ve bilgi işlem uygulamaları için düşük maliyetli, metale yakın bir API'dir. Vulkan, temel olarak OpenGL'nin devamıdır. Başlangıçta “yeni nesil OpenGL girişimi” olarak adlandırılıyordu ve AMD'nin Mantle API'sinden birkaç parça ve parça içeriyor. Vulkan'ın diğer GPU API'lerine göre sayısız avantaj sağlaması, üstün platformlar arası destek, çok iş parçacıklı işlemciler için daha iyi destek, daha düşük CPU yükü ve bir tutam işletim sistemi agnostisizmi sağlaması bekleniyor. Ayrıca sürücü geliştirmeyi kolaylaştırmalı ve çeşitli dillerde yazılmış gölgelendiricilerin kullanımı da dahil olmak üzere sürücülerin önceden derlenmesine izin vermelidir.

Bu 93 kelimedir, yani ilgilenmiyorsanız sonraki 3.500'ü atlayabilirsiniz. Öte yandan, önümüzdeki yıllarda bizimle olacak grafik API'si hakkında daha fazla bilgi edinmek istiyorsanız, temel bilgilerle başlayacağım.

Vulkan API Nasıl Oluştu?

Vulkan, ilk olarak Mart 2015'te Khronos Group tarafından, 2015'in sonlarına doğru geçici bir lansman tarihi ile duyuruldu. Khronos'a aşina değilseniz, on beş yıl önce dünyanın en büyük isimlerinden bazıları tarafından kurulmuş, kar amacı gütmeyen bir endüstri konsorsiyumu. ATI (şimdi AMD'nin bir parçası), Nvidia, Intel, Silicon Graphics, Discrete ve Sun Microsystems dahil olmak üzere grafik endüstrisi. Khronos'u duymamış olsanız bile, muhtemelen OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES gibi bazı standartlarını duymuşsunuzdur. StreamInput, COLLADA ve glTF.

Şimdiye kadar muhtemelen "Ah, bu adamlar" diye düşünüyorsunuzdur, böylece girişin geri kalanını atlayabilir ve API'nin kendisine odaklanabilirim.

Selefinin veya öncüllerinin aksine, Vulkan sıfırdan cep telefonlarından tabletlere, oyun konsollarına ve üst düzey masaüstü bilgisayarlara kadar çeşitli platformlarda çalışacak şekilde tasarlanmıştır. API'nin temel tasarımı katmanlıdır veya modüler mi demeliyiz, bu nedenle performansı etkilemeden kod doğrulama, hata ayıklama ve profil oluşturma için ortak, ancak genişletilebilir bir mimarinin oluşturulmasını sağlar. Krhonos, katmanlı yaklaşımın çok daha fazla esneklik sağlayacağını, satıcılar arası GPU araçlarında güçlü yenilikleri katalize edeceğini ve sofistike oyun motorlarının talep ettiği daha doğrudan GPU kontrolünü sağlayacağını iddia ediyor.

Şimdi, birçok teknoloji meraklısının "esnek", "genişletilebilir" ve "modüler" gibi pazarlama terimleri hakkında çekinceleri olduğunu anlıyorum ama bu sefer gerçek McCoy ile uğraşıyoruz. Aslında, Vulkan'ın arkasındaki temel fikir bu: Akıllı telefonlarda oyun oynayan çocuklardan iş istasyonlarında binalar ve oyunlar tasarlayan ebeveynlerine kadar kitleler için bir API olarak tasarlandı.

Teoride Vulkan, paralel bilgi işlem donanımında, on milyarlarca GPU çekirdeğini kontrol etmek için, küçük giyilebilir cihazlarda ve oyuncak uçaklarda, 3D yazıcılarda, arabalarda, VR kitinde ve içinde uyumlu bir GPU bulunan hemen hemen her şeyde kullanılabilir.

Daha fazla ayrıntı için, PDF'deki resmi Vulkan genel bakışına bir göz atmanızı öneririm.

AMD Manto DNA'sı

Metale yakın yaklaşım ürkütücü bir şekilde tanıdık geliyorsa, AMD'nin GPU duyurularını son iki yıldır takip ediyor olabilirsiniz. AMD, 2013'te Mantle API'sini duyurduğunda endüstri gözlemcilerini şaşırttı ve API'nin fişini çekmeye karar verdiğinde, Mart 2015'te Mantle 1.0'ı genel bir SDK olarak yayınlamayacağını açıklayarak onları bir kez daha şaşırttı. Özetle, Mantle bazı durumlarda, özellikle CPU cephesinde, işleme ek yükünü azaltacağı için önemli performans ve verimlilik iyileştirmeleri sağlama sözü verdi. Oyuncular, biraz daha yavaş işlemcilere sahip özel bilgisayarları bir araya getirip birinci sınıf grafik kartlarına daha fazla para yatırabildiklerinden, kulağa iyi bir fikir gibi geldi. AMD için de kulağa çok uygun geldi çünkü şirket, hala iyi GPU ürünlerine sahip olmasına rağmen, yıllardır rekabetçi bir üst düzey CPU'ya sahip değildi.

Ağlayan AMD hayranları, kurtarıcılarının ölümünün yasını tutmak için toplanırken Mantle mucizevi bir şekilde dirildi. İyi haber, AMD'nin Görsel ve Algısal Bilgi İşlem Başkan Yardımcısı Raja Koduri tarafından kaleme alınan bir blog yazısı şeklinde geldi. Tesadüfen, dini temaya uygun olarak, Koduri bir keresinde AMD'nin 2013'teki Hawaii lansman etkinliği sırasında bir binek üzerinde vaaz verdi, ama ben konuyu dağıtıyorum.

Şaka bir yana, Koduri'nin ekibi iyi bir iş çıkardı. Mantle yeni bir endüstri standardı olmasa da Vulkan için bir temel haline geldi. En büyük fark, Vulkan'ın AMD GCN donanımıyla sınırlı kalmamasıdır; farklı satıcılardan çok daha fazla GPU üzerinde çalışacak. Muhtemelen bununla nereye gittiğimi görebilirsiniz; farklı GPU mimarileri, işletim sistemleri vb. için özel API'lere sahip olmaktansa, farklı işletim sistemleri ve donanım platformlarında çalışan tek bir düşük maliyetli grafik API'sine sahip olmak biraz daha iyidir.

Vulkan API, Mantle pastasının iyi bir kısmını alır ve işletim sistemi, donanım, ırk veya din ne olursa olsun herkesle paylaşır.

Oh, ve bir şey daha var: Mantle sonunda Microsoft ve Khronos'u DirectX ve OpenGL şişkinliği ve verimsizliği hakkında bir şeyler yapmaya zorladı. Arkadan nazik, dostane bir tekmeydi ya da bir Toptaler arkadaşının tabiriyle “badonkadonk”.

Vulkan, OpenGL ile Nasıl Karşılaştırılır?

Açıkçası, Vulkan ve OpenGL arasındaki temel farkları özetlemem gerekiyor. Khronos, yeni API ile ne kadar sürücü şişkinliğinin ortadan kaldırılabileceğini gösteren basit bir örnekle geldi.

Vulkan, uygulamaların metale yaklaşmasını sağlar, böylece çok fazla bellek ve hata yönetimi ihtiyacının yanı sıra çok sayıda gölgeleme dili kaynağı ihtiyacını ortadan kaldırır. Sürücüler daha hafif, daha yalın ve daha kötü olacak. Vulkan, yalnızca SPIR-V ara diline güvenecek ve mobil, masaüstü ve konsol pazarları için birleşik bir API'ye sahip olduğundan, geliştiricilerden daha hassas ve sevgi dolu bir ilgi görmelidir.

Ama bekleyin, bu oyun geliştiricilere daha fazla iş yüklemiyor mu? Elbette, donanımı daha verimli kullanabilecekler, peki ya kendi çalışma saatleri? Katmanlı ekosistem yaklaşımının mücadeleye girdiği yer burasıdır.

Geliştiriciler, Vulkan ekosisteminin üç farklı seviyesini veya katmanını seçebilecekler.

• Maksimum esneklik ve kontrol için doğrudan Vulkan'ı kullanın.
• Geliştirmeyi hızlandırmak için Vulkan kitaplıklarını ve katmanlarını kullanın.
• Vulkan'ı, yeni API üzerinden tamamen optimize edilmiş kullanıma hazır oyun motorları aracılığıyla kullanın.

İlk seçenek açıkça herkes için olmayacak, ancak bazı güzel kıyaslama yazılımları için yapabileceğinden şüpheleniyorum. Khronos, birçok yardımcı program ve katman açık kaynakta olacağından ve OpenGL'den geçişi kolaylaştıracağından, ikinci seçeneğin "yenilik için zengin bir alan" olmasını bekliyor. Bir yayıncının ince ayar yapılması ve güncellenmesi gereken bazı OpenGL başlıkları varsa, bunu kullanacaklardır.

Son seçenek, belki de en cazip olanıdır, çünkü ağır kaldırma, Unity, Oxide, Blizzard, Epic, EA, Valve ve diğerleri gibi endüstri ağır ağırlıkları tarafından yapılmıştır.

İşte hızlı bir OpenGL - Vulkan tablosu:

Dürüst olmak gerekirse, ikisini karşılaştırmanın bile adil olduğunu düşünmüyorum. Vulkan bir Mantle türevidir, OpenGL ise 20 yıllık bagajı olan bir mastodondur. Vulkan'ın bir sürü eski eşyayı atması gerekiyor; bütün mesele bu. Vulkan'ın SPIR-V ara dili aracılığıyla test ve uygulamayı kolaylaştırması, sürücüleri daha yalın hale getirmesi ve gölgelendirici program taşınabilirliğini geliştirmesi bekleniyor.

Bu bizi bir sonraki soruya getiriyor. Vulkan, geliştiriciler için gerçekten ne anlama geliyor?

SPIR-V'nin Dil Ekosistemini Dönüştürmesi Bekleniyor

Peki SPIR-V nerede devreye giriyor ve eski güzel GLSL'ye ne oluyor?

GSLS şimdilik hayatta kalacak ve Vulkan tarafından desteklenen ilk gölgeleme dili olacak. Bir GLSL'den SPIR-V'ye tercüman ağır kaldırma işini yapacak ve işte!, SPIR-V'yi aç Vulkan çalışma zamanını beslemeye hazır hale getireceksiniz. Oyun geliştiricileri, muhtemelen açık kaynaklı derleyici ön uçlarına dayanarak SPIR-V ve Vulkan arka uçlarını kullanabilecekler. GLSL'ye ek olarak Vulkan, OpenCL C çekirdeklerini destekleyebilir ve C++ desteği ekleme çalışmaları devam etmektedir. Gelecekteki alana özgü diller, çerçeveler ve araçlar başka bir seçenektir. Khronos, yeni deneysel diller geliştirme olasılığından bile bahseder.

Geliştiriciler ne yapmayı seçerse seçsin, tüm yollar SPIR-V aracılığıyla Vulkan'a ve ardından çok sayıda farklı cihaza çıkar.

SPIR-V'nin taşınabilirliği üç şekilde geliştirmesi bekleniyor:

• Paylaşılan araçlar
• Tek bir ISV için tek araç seti
• Basitlik

Her donanım platformunun üst düzey bir dil çevirmeni içermesine gerek olmayacağından, geliştiriciler bunlardan daha azıyla ilgilenecektir.

Bireysel bir ISV, tek bir araç seti kullanarak SPIR-V oluşturabilir, böylece üst düzey dilin taşınabilirlik sorunlarını ortadan kaldırabilir.

SPIR-V, tipik bir üst düzey dilden daha basittir, uygulama ve işlemeyi kolaylaştırır.

Vulkan'ın nasıl uygulandığına bağlı olarak performans çeşitli şekillerde geliştirilecektir:

• Artık derleyici ön ucu yok, birçok işlem çevrimdışı yapılabilir
• Optimizasyon geçişleri daha hızlı sonuçlanabilir, optimizasyonlar çevrimdışı olarak yürütülür
• Birden çok kaynak gölgelendirici, aynı ara dil talimat akışına indirgenir

Khronos herhangi bir performans rakamı belirtmiyor ve "kilometrenin kesinlikle değişeceğini" belirtiyor. Her şey Vulkan'ın nasıl kullanıldığına bağlı olacaktır. Cesur ayrıntıları kontrol etmek istiyorsanız, SPIR-V teknik incelemesini kontrol ettiğinizden emin olun.

Geliştirici Perspektifinden Vulkan Umut Veriyor

Vulkan ve SPIR-V'yi geliştirici topluluğunda popüler hale getirecek bir dizi özelliği özetledim ve Khronos da bu noktayı aktarmaya hevesli. Aynı araçları ve becerileri birden fazla platform için geliştirme olasılığı, özellikle şimdi çeşitli platformlar arasındaki performans farkının kapanmasıyla ilgi çekici görünüyor.

Tabii ki, PC'ler için büyük bütçeli bir AAA oyunu geliştirmek, yığınla nakit ve insan kaynağı gerektiren son derece karmaşık ve zaman alıcı bir süreç olmaya devam edecek, ancak en yeni Intel ve AMD işlemcilerde kullanılan mobil platformlar ve entegre GPU'lar zaten çok şey sağlıyor. Sıradan oyuncular için GPU performansı. Ayrıca, küçük, bağımsız geliştiriciler veya serbest çalışanlar, büyük yayıncılar tarafından üretilen AAA oyunlarından ziyade platformlar arası gündelik oyunlar üzerinde çalışmaya daha yatkındır.

Khronos, SPIR-V'nin mümkün kıldığı aşağıdaki avantajları özetlemektedir:

• Geliştiriciler, satıcılar arası taşınabilirlik sorunlarını ortadan kaldırmak için aynı ön uç derleyiciyi birden çok platformda kullanabilir
• Sürücünün yalnızca SPIR-V'yi işlemesi gerektiğinden çalışma zamanı gölgelendirici/çekirdek derleme süresi kısalacak
• Geliştiricilerin gölgelendirici/çekirdek kaynak kodunu dağıtması gerekmez, bu nedenle ek bir IP koruması seviyesinden yararlanırlar.
• Ön uç derleyicileri dahil etmeye gerek olmadığından sürücüler daha basit ve daha güvenilirdir
• Geliştiriciler daha iyi bir bellek ayırma resmine sahiptir ve buna göre bellek ayırma yaklaşımlarını değiştirebilirler.

Bunun kulağa hoş geldiğine eminim siz de katılacaksınız, ancak daha gidilecek çok yol var.

Vulkan: Çalışıyor, Ama Devam Eden Bir Çalışma

Dediğim gibi, Vulkan hala devam eden bir çalışma ve yıl sonuna kadar tüm özelliklere sahip olmalıyız. Ancak, şimdiye kadar gördüklerimize göre, yeni API, mevcut nesil donanımlarla bile çok fazla performansın kilidini açabilir.

Şimdiye kadar gördüğüm en iyi Vulkan örneği, önde gelen mobil GPU donanımlarından biri olan Imagination Technologies'den geliyor. Imagination Technologies GPU IP, tüm iOS aygıtlarında, diğer çok sayıda ARM tabanlı Çip Üzerinde Sistem tasarımıyla ve hatta bazı düşük voltajlı Intel x86 yongalarında kullanılır.

Geçen hafta Imagination, Vulkan'ın mümkün kıldığı performans kazanımlarını detaylandıran bir blog yazısı yayınladı. Donanım seçimi biraz sıra dışıydı: PowerVR G6430 GPU ile nadiren kullanılan Intel dört çekirdekli işlemciye dayanan bir Google Nexus Player. Cihaz, PowerVR GPU'lar için en son Vulkan API sürücüsü ile test edilmiş, referans çalıştırma ise OpenGL ES 3.0 üzerinde gerçekleştirilmiştir. Performans farkı şaşırtıcı olmaktan başka bir şey değildi.

Sahne, 13.000 ila 300 köşe arasında değişen farklı ayrıntı seviyelerine sahip toplam 400.000 nesne içerir. Geniş çekim, bitkiler üzerinde bir miktar alfa ve cüceler ve bitkiler için yaklaşık on farklı doku olan tahmini bir milyon üçgeni gösteriyor. Her nesne türü farklı bir gölgelendirici kullanır ve cüceler örneklenmez, her çizim çağrısı farklı malzemelerle tamamen farklı bir nesne olabilir, ancak sonuç benzer olacaktır.

Yine de büyük bir uyarı var: Bu, gerçek hayatta bekleyebileceğiniz türden bir performans artışı değil. Imagination Technologies ekibi, Vulkan'ın üstünlüğünü vurgulamak, sınırlarını zorlamak için abartılı bir senaryo kullandı ve bu özel senaryoda sınır, Vulkan'a karşı OpenGL ES'nin lehine. Ayrıca, bu testin GPU'ya bağlı olduğunu unutmayın, ancak yine de Vulkan'ın üstün CPU kullanımının iyi bir örneğidir.

Vulkan CPU Kullanımını Nasıl Azaltır?

Daha önce sahip olduğumuz OpenGL vs. Vulkan tablosunu veya daha spesifik olmak gerekirse, döşemeli oluşturma bitini hatırlıyor musunuz? Muhtemelen hayır, işte burada, kısaca: Imagination, Vulkan'ı toplu çağrıları karolara çekmek ve bir kerede bir karo oluşturmak için kullandı. Çerçevenin oluşturulduğu anda döşemenin nerede olduğuna bağlı olarak, görüntüye girebilir veya görüş dışında kalabilir, ayrıntı düzeyini değiştirebilir vb. OpenGL ES'de, tüm çizim çağrıları dinamiktir, görüş alanında olana göre her çerçeve ile gönderilirler. Halihazırda yürütülmüş olan çizim çağrıları önbelleğe alınamaz.

Sonuç olarak, OpenGL ES, sürücünün durumunu değiştirmek ve doğrulamak için çekirdek moduna birçok çağrıya ihtiyaç duyar. Vulkan, CPU yükünü azaltmak ve işleme döngüsü sırasında doğrulama veya derleme ihtiyacını ortadan kaldırmak için önceden oluşturulmuş komutlara (komut arabellekleri) dayandığı için yapmaz. Imagination ekibi, komut arabelleklerini yeniden kullanma yeteneğini "bazı durumlarda yararlı" ve birçok oyun ve uygulamada "büyük ölçüde" kullanmanın mümkün olduğunu açıkladı.

İkinci oyun değiştirici, Vulkan'ın tüm CPU çekirdeklerinin gücünden yararlanmasını sağlayan paralel arabellek üretimidir . OpenGL ES, çok çekirdekli mobil çiplerin ortaya çıkmasından önce tasarlandı, ancak son üç yılda endüstri, Apple'ın A-serisi SoC'leri ve Denver tabanlı Nvidia Tegra ile iki, dört, sekiz ve on CPU çekirdeğine geçti. tek dikkate değer istisnalar olarak çipler. Daha önceki blog yazılarımdan birinde, ek bilgi için kontrol edebilmeniz için Android'i Optimize Etme derleyicisini kapsayan mobil SoC trendlerinden bahsettim.

Bir benzetme deneyelim: Vulkan içten yanmalı bir motor olsaydı, gücünün bir kısmını depolar ve yeniden kullanırdı, tıpkı bir turboşarj ve ara soğutucu (komut tamponları) gibi, dört, altı, verimlilik kaybı olmadan sekiz hatta on silindir (paralel tampon üretimi). Vulkan'ı OpenGL ES ile karşılaştırmak, büyükbabanızın Triumph Trophy'sindeki yeni, küçültülmüş bir turbo motoru eski, tek silindirli bir motorla karşılaştırmaya benziyor.

En azından büyükbabam iyi bir rockçıydı, mod değil.

Sonuç, çoğu senaryoda CPU'ya bağlı olan OpenGL ES'nin aksine, mevcut tüm donanımı iyi bir şekilde kullanabilen çok daha verimli bir ortamdır. Bu, Vulkan'ın CPU'yu daha düşük saatlerde tutarken benzer performans seviyeleri sunabileceği ve böylece güç tüketimini ve kısıtlamayı azaltabileceği anlamına gelir.

Potansiyel Vulkan API Dezavantajları (Spoiler Uyarısı: O Kadar Çok Yok)

Nitelik seçici değilim; Vulkan API'nin artılarını ve eksilerini listelemenin de önemli olduğunu düşünüyorum. Neyse ki, birkaç küçük ve potansiyel olarak bir veya iki büyük olandan başka çok fazla eksi yok. Vulkan'ın dilimlenmiş ekmekten sonraki en iyi şey olduğunu düşünüyorsanız ve bir sonraki projenizde denemeye hevesliyseniz, şu noktalardan birkaçını düşünmek isteyebilirsiniz:

• Belirli senaryolarda kod karmaşıklığı eklendi
• Market zamanı
• Endüstri desteği seviyesi
• Vulkan, bazı platformlarda (masaüstlerinde) o kadar alakalı veya etkili olmayabilir.
• Geliştiricileri bazı platformlarda Vulkan'ı kullanmaya ikna etmek
• Eski donanımlarla sınırlı uyumluluk

Bir geliştirici bu gönderide özetlenen bazı düzgün özelliklerden bazılarını uygulamak isterse, oldukça fazla çalışma gerektirecektir. Her birinin kod halinde uygulanması gerekecek, ancak iyi haber şu ki sektör liderleri yeni sürücü güncellemeleriyle süreci kolaylaştıracak.

Vulkan'ın eski uygulamalarda ve oyunlarda uygulanması gibi, pazara sunma süresi de başka bir endişe kaynağıdır. Vulkan hala teknik bir ön izleme; İlk spesifikasyonların ve uygulamaların 2015'in sonunda olması bekleniyor, bu nedenle gerçekçi olmak gerekirse, muhtemelen 2016 ortasından önce pek çok gerçek dünya uygulaması görmeyeceğiz.

Sanayi desteği bir sorun olmamalı; Ne de olsa bu bir Khronos standardıdır, ancak biraz zaman alabilir. Bu gönderiyi mobil segmente odaklamamın sebeplerinden biri de bu; Mobil yazılım ve donanım daha hızlı gelişiyor ve Vulkan'ın masaüstü platformlarında bir etki yarattığını görmemiz birkaç çeyrek daha alabilir. Endüstri böyle işliyor, masaüstü nişinde endişelenecek çok daha fazla şey var: profesyonel uygulamalar için destek, her yırtık çerçevenin üzerinde maymun gibi görünen dirgen kullanan oyuncu orduları vb. Ancak Vulkan'ın AMD'nin Mantle'ından türetilmiş olması cesaret verici.

Vulkan, özellikle çok çekirdekli mobil SoC'lerde, CPU'ya bağlı bir ortamda harikalar yaratabilirken, masaüstü platformlarında bu performans kazanımları sınırlı olacaktır. Masaüstü bilgisayarlar, çok çekirdekli işlemcileri daha yüksek düzeyde verimlilikle yönetir ve grafiksel olarak zorlu uygulamaların çoğu GPU'ya bağlıdır.

Bulmacanın tüm parçaları yerine oturana kadar, bazı geliştiriciler dalmaya ve Vulkan'la uğraşmaya isteksiz olabilir. Pek çok insanın deney yapmak için zamanı yoktur ve sadece kesinlikle gerekli olduğunda yeni beceriler öğrenirler. Bu erken aşamada Vulkan'ı kullanmak için mevcut mobil oyunlarda ince ayar yapmak için çok para harcamak ve adam-saat harcamak pek çok geliştirici ve yayıncı için bir seçenek olmayacak.

Eski donanımlarla uyumluluk başka bir endişe kaynağı olabilir. Vulkan, yeni sürücülerle birlikte OpenGL ES 3.1 veya OpenGL 4.1 donanımına ihtiyaç duyacaktır. Örneğin, Imagination Technologies'in PowerVR serisi 6 GPU'ları bunu destekleyebilir, ancak seri 5 destekleyemez. Qualcomm'un Adreno 400 serisi OpenGL ES 3.1'i destekler, ancak 300 serisi desteklemez. ARM'nin Mali T600- ve T700-serisi OpenGL ES 3.1'i destekler, ancak eski T400-serisi tasarımlarında destek yoktur. Neyse ki, Vulkan alakalı hale geldiğinde, desteklenmeyen GPU'lara sahip çoğu cihaz resmin dışında kalacak. Bunlara iPhone 5/5C, dördüncü nesil iPad ve bazı 5000 serisi Exynos çiplerine dayalı Samsung cihazları dahildir. Adreno 300 serisi GPU'lar Snapdragon 410, Snapdragon 600, Snapdragon 800 ve 801 gibi nispeten yeni ve üretken tasarımlarda kullanıldığı için Qualcomm tabanlı cihazlar o kadar şanslı olmayabilir. Ancak, çoğunun zamanla gideceğinden şüpheleniyorum. Vulkan gerçekten alakalı hale geliyor.

Uzun Yaşa ve Oluştur

Vulkan'ın oyunun kurallarını değiştirip değiştirmeyeceğini söylemek için henüz çok erken ama bence çok fazla potansiyele sahip olduğunu kabul edeceksiniz. Bunun çok önemli olacağını düşünüyorum ve bu varsayımı GPU endüstrisini kapsayan on yıllık deneyime dayandırıyorum. Ancak zaman alacak ve Vulkan'ın masaüstü ortamını değiştirmeye başlamadan önce varlığını mobilde hissettireceğinden şüpheleniyorum.

Aynı zamanda, Vulkan için optimize edilmiş sürücüler, oyun motorları ve oyunlarla birlikte oynamak için yeni donanımlar alacağız ve sadece küçük donanım ince ayarlarından bahsetmiyorum. Mobil SoC geliştirme birkaç nedenden dolayı durdu, şimdi girmeyeceğim, ancak 14/16nm FinFET düğümleri daha fazla üretici tarafından kullanılabilir hale geldiğinden ve ana akım donanımlar için ekonomik olarak uygun hale geldiğinden, 2016 endüstri için büyük bir yıl olacak. amiral gemisi çipleri.

Geliştiriciler, oynamak için çok daha güçlü ve verimli donanıma sahip olacak ve yeni bir düşük maliyetli grafik API'si pastanın üzerindeki krema olacak. Donanım satıcılarının ekran çözünürlüğünü bir pazarlama hilesi olarak kullanmayı bırakacağını içtenlikle umuyorum, çünkü anlamsız yüksek çözünürlükler görsel kalite için hiçbir şey yapmaz, ancak yine de güç harcar. Ne yazık ki, ortalama bir tüketici bunu anlamadığından ve kutuda daha büyük rakamlar görmek istediğinden, bunun yakın zamanda olmayacağından şüpheleniyorum. Bu garip konuyu yaklaşan gönderilerimden birinde incelemeyi planlıyorum, bu yüzden rahatsızsanız, bizi izlemeye devam edin ve yorum bölümünden çekinmeyin.