İş parçacığı güvenliği neden Grafik API'leri için bu kadar önemli?

Hem Vulkan hem de DirectX 12'nin iş parçacığı güvenli bir şekilde kullanılabileceği iddia ediliyor. İnsanlar bu konuda heyecanlı görünüyor.

Neden bu kadar büyük bir özellik olarak kabul edilir? "Gerçek" işlem, yine de ayrı bir işlem biriminde bellek köprüsü üzerine atılır.

Ayrıca eğer çok büyükse, neden güvenli bir API API iş parçacığı çıkana kadar olmasın?

Asıl kazanç, CPU görevlerini grafik API'ye erişmedeki tüm zor sorunları çözmek zorunda kalmadan birden fazla iş parçacığına bölmenin daha kolay olacağı olacaktır. Normalde, ya içeriği güncelleştirmek zorunda kalırsınız (ki bu, performansın kötü performans göstermesine neden olabilir) veya bir sıra sağlayın ve tek bir iş parçacığında grafik api çağırın. Herhangi bir performansın bu şekilde kazanıldığını sanmıyorum, çünkü GPU gerçekten onları sırayla işler, ancak geliştirici işini çok daha kolaylaştırır.

Muhtemelen şu ana kadar yapılmamasının nedeni, directx ve opengl'in çok okuyucunun gerçekten belirgin olmadığı bir zamanda yaratılmış olmalarıdır. Ayrıca Khronos kurulu API'yi değiştirmede çok muhafazakar. Vulkan hakkındaki görüşleri, OpenGL'nin yanında bir arada bulunacağını, çünkü her ikisi de farklı amaçlara hizmet ediyor. Tüketiciler giderek daha fazla işlemciye eriştikçe, muhtemelen yakın zamana dek paralizmin önemi bu kadar önemli değildi.

EDIT: Birden fazla CPU'da çalışma yapmaktan hiçbir performans elde edilemez demek istemiyorum, çağrıları daha hızlı yapmak için dokuları / gölgeleri oluşturmak için çağrıları birden fazla konuya bölmek kullanışlı değil. Aksine, daha fazla işlemcinin meşgul olması ve gpu'nun gerçekleştirilmesi gereken şeylerle meşgul kalması nedeniyle performans elde edilir.

İşlemcide GPU için bir çerçeve oluşturmak için gereken çok iş var ve bu işin iyi bir kısmı grafik sürücüsünün içinde. DX12 / Vulkan'dan önce, bu grafik sürücüsü çalışması, API tasarımında esas olarak tek işlenmeye zorlandı.

Umut, DX12 / Vulkan'ın bu kısıtlamayı kaldırması, sürücünün bir çerçeve içinde birden fazla CPU iş parçacığına paralel olarak çalışmasını sağlamasıdır. Bu, çok çekirdekli işlemcilerin daha verimli kullanılmasını sağlayacak ve oyun motorlarının işlemciye bağlı olmadan daha karmaşık sahneleri zorlamasını sağlayacak. Umut budur - pratikte gerçekleşip gerçekleşmeyeceği önümüzdeki birkaç yıl boyunca görmek için bekleyeceğimiz bir şeydir.

Bir bitin ayrıntılandırılması: Bir oyun motoru oluşturucusunun çıktısı, bir kareyi oluşturma işlemlerinin sırasını tanımlayan DX / GL API çağrılarının akışıdır. Bununla birlikte, API çağrılarının akışı ile GPU donanımının harcadığı gerçek ikili komut tamponları arasında büyük bir mesafe vardır. Sürücünün, konuşması için, API çağrılarını GPU'nun makine diline çevirmesi gerekir. Bu önemsiz bir işlem değildir; API kavramlarının düşük seviye donanım gerçeklerine çevrilmesi, GPU’nun hiçbir zaman geçersiz bir duruma getirilmediğinden emin olmak için doğrulama, bellek tahsisleri ve verilerden kaçınmak, durum değişikliklerini izlemek için düzeltmek için düşük seviye komutları vb. Tüm bunların sorumluluğu grafik sürücüsü.

DX11 / GL4 ve önceki API’lerde, bu çalışma genellikle tek bir sürücü iş parçacığı tarafından yapılır. Birden fazla iş parçacığından (örneğin, DX11 ertelenmiş komut listelerini kullanarak yapabileceğiniz) API'yi çağırsanız bile, sürücü iş parçacığının daha sonra gözden geçirilmesi için bir kuyruğa bazı işler ekler. Bunun büyük bir nedeni, daha önce bahsettiğim devlet takibi. Donanım düzeyinde GPU yapılandırma ayrıntılarının birçoğu, mevcut grafik boru hattı durumu hakkında bilgi gerektirdiğinden, komut listesini paralel olarak işlenebilecek parçalara bölmenin iyi bir yolu yoktur - her bir parça tam olarak hangi durumda başlayacağını bilmek zorunda kalır Bununla birlikte, önceki öbek henüz işlenmemiş olsa bile.

Bu DX12 / Vulkan'da değişen en büyük şeylerden biri. Bir kere, onlar bir nesnesine neredeyse tüm grafik boru hattı durumunu dahil ve bir komut listesi oluşturmaya başlamak zaman diğeri için (DX12 en az) Eğer gerekir başlangıç boru hattı durumunu sağlamak; durum bir komut listesinden diğerine devralınmaz. Prensip olarak, bu sürücünün, derlemeye başlamadan önce önceki komut listeleri hakkında hiçbir şey bilmemesini sağlar ve sırayla uygulamanın, paralelleştirilebilir parçalara dönüştürülmesi, ardından da derlenmiş komut listeleri üretmesi; bir araya toplanmış ve en az telaş ile GPU'ya gönderildi.

Tabii ki, yeni API'lerde birçok başka değişiklik var, ancak çoklu okumalar söz konusu olduğunda, bu en önemli kısım.

Modern GPU'lar genellikle CPU'dan tamamen doğrusal bir komut akışını işleyen tek bir ön bölüme sahiptir. Bunun doğal bir donanım tasarımı olup olmadığı veya GPU için tek bir CPU çekirdeği üreten komutların olduğu günlerden çıkıp gelmediği tartışılabilir. Ancak şimdilik gerçek. Dolayısıyla, durumsal komutların tek bir doğrusal akışını oluşturursanız, elbette bu akımı CPU üzerindeki tek bir iş parçacığında doğrusal olarak üretmek mantıklı olur! Sağ?

Eh, modern GPU'lar genellikle aynı anda birçok farklı şeyle çalışabilecek çok esnek birleşik bir arka uca sahiptir. Genel olarak konuşursak, GPU köşeleri ve pikseller üzerinde oldukça ince bir ayrıntı derecesinde çalışır. Bir çizimde 1024 tepe noktası ve iki farklı çizimde 512 + 512 tepe noktası işleyen bir GPU arasında çok fazla bir fark yoktur.

Bu, daha az iş yapmanın oldukça doğal bir yoludur: GPU'ya çok sayıda köşeyi tek bir beraberlik çağrısında atmak yerine, modelinizi bölümlere ayırmak, bu bölümlere ucuz kaba mal almak ve bu bölümleri geçerse her bir parçayı ayrı ayrı göndermek ayrılma testi. Bunu doğru ayrıntıda yaparsanız iyi bir hız kazanmalısınız!

Maalesef, şu anki grafik API gerçekte, çizim çağrıları CPU'da oldukça pahalıdır. Neden: basitleştirilmiş bir açıklama: GPU’daki durum değişiklikleri doğrudan grafik API çağrılarına karşılık gelmeyebilir, bu yüzden birçok grafik API çağrısı yalnızca sürücünün içinde bir durum belirledi ve bu yeni duruma bağlı olacak çağrı son çekilişten bu yana değişmiş olarak işaretlenmiş durum, onu GPU'nun komut akışına yazar, sonra gerçekte çekilişi başlatır. Tüm bunlar GPU ön uç birimi için yalın ve ortalama bir komut akışı elde etmek amacıyla yapılan çalışmadır.

Bunun kaynadığı şey , tamamen sürücünün ek yükü tarafından uygulanan aramaları çekmek için bir bütçeniz olduğu . (Bugünlerde bir 60 FPS başlığı için kare başına yaklaşık 5.000 ile kaçabileceğinizi duydum.) Bu komut akışını paralel boyutlarda oluşturarak bunu büyük oranda artırabilirsiniz.

Başka sebepler de var (örneğin, VR gecikme süresi iyileştirmeleri için asenkron timewarp), ancak bu grafik bağlantılı oyunlar ve diğer düşük ağırlıklı yazılımlar için (3D modelleme paketleri gibi) büyük bir sorun.