Neden donanım hızlandırmalı vektör grafikleri çıkartılmıyor?

60fps'de vektör yollarının gerçek zamanlı manipülasyonunu içeren bir uygulama üzerinde çalışıyorum ve konuyla ilgili ne kadar az bilgi bulunduğuna çok şaşırdım. İlk başta, fikirimi CoreGraphics kullanarak uygulamaya çalıştım, ancak bu amaçlarım için yeterince performans göstermedi . Daha sonra OpenVG adlı donanım hızlandırmalı vektör grafikleri için bir Khronos standardı olduğunu ve neyse ki MonkVG adında bir OpenGL ES yarı uygulaması yazdığını gördüm .

Ancak OpenVG'nin pratik olarak faydalı bir API olmasına rağmen, Khronos tarafından aşağı yukarı terkedilmiş gibi görünüyor. Wikipedia’ya göre, 2011’den bu yana, çalışma grubu “daha ​​ileri standardizasyon için düzenli toplantılar yapmamaya karar verdi”. Bulabildiğim en iyi dokümantasyon sadece bir referans kartından oluşuyor. Dahası, internette herhangi bir yerde OpenVG örnekleri neredeyse hiç yok. Yüzlerce OpenGL dersini göz açıp kapayıncaya kadar bulabilirim, ancak OpenVG göze çarpıyor gibi görünüyor.

Donanım hızlandırmalı vektörlerin günümüzün hızla artan kararlar dünyasında daha önemli olacağını düşünürdünüz ve pek çok şirketin bunu gerçekleştirmenin kendi yollarını uyguladığı görülüyor. Örneğin, Qt ve Flash donanım hızlandırmalı vektörler için şemalara sahiptir ve birçok Adobe'nin aracı bir seçenek olarak donanım hızlandırmaya sahiptir. Fakat bir standart zaten mevcut olduğunda çarkın yeniden keşfedilmesi gibi görünüyor!

OpenVG hakkında kaçırdığım bir şey var mı onu gerçek dünya kullanımı için uygun değil mi? Yoksa sadece standardın zamanında yakalayamadığı ve şimdi belirsizlikten mahrum mu kaldığı? Gelecekte donanım hızlandırmalı vektör grafikleri için standardize edilmiş bir API'ye yer var mı yoksa geleneksel raster tabanlı teknikleri kullanmak daha mı kolay? Yoksa vektörler, daha önce hiç çıkmadan önce dışarı çıkıyorlar mı?

güncelleme: Cevabın altına bakın

Bu cevap çok geç geliyor, ancak başkalarına ışık tutmayı umuyorum (özellikle şu anda C ++ standart komitesi Kahire'yi std'ye dahil etmek istiyor):

Hiç kimsenin "hızlandırılmış vektör grafikleri" ile gerçekten ilgilenmemesinin nedeni, GPU'ların çalışma şeklidir. GPU'lar, her pikseli renklendirmek için büyük paralelleştirme ve SIMD özellikleri kullanarak çalışır. AMD tipik olarak 64x64 8x8 piksel bloklarda çalışır, NVIDIA kartlar ise genellikle 32x32 4x4 piksel çalışır.

3D üçgeni oluştursalar bile, GPU bu üçgenin kapsadığı dörtlü yerlerde çalışır. Bu nedenle, bir üçgen bloktaki tüm 8x8 pikselleri kapsamıyorsa (veya nvidia durumunda 4x4) GPU, ele geçen piksellerin rengini hesaplar ve sonucu atar. Başka bir deyişle, ele geçen piksellerin işlem gücü israf edilir. Bu israf gibi gözükse de, çok sayıda GPU çekirdeği ile eşleştirildiğinde büyük 3D üçgenler oluşturmak için inanılmaz derecede iyi çalışıyor (burada daha ayrıntılı bilgi: temel rasterleştiriciyi optimize etme ).

Bu yüzden, vektörel rasterleştirmeye tekrar baktığımızda, çizgiler çizerken, kalın olsalar bile, büyük bir boşluk olduğunu fark edeceksiniz. İşlem gücünün bir sürü boşa ve Yani, (büyük güç tüketimine neden ve genellikle bir tıkanıklık) daha da önemlisi bant genişliği sen 8 bir kalınlık katına sahip bir yatay veya dikey çizgi çekiyorlar, sürece ve mükemmel için hizalar 8 piksel sınırı, çok fazla işlem gücü ve bant genişliği boşa harcanacak.

Oluşturulacak gövdeyi hesaplayarak "atık" miktarı azaltılabilir (NV_path_rendering'in yaptığı gibi), ancak GPU hala 8x8 / 4x4 bloklarla sınırlandırılmıştır (muhtemelen NVIDIA'nın GPU ölçütleri daha yüksek çözünürlüklerle daha iyi ölçeklenir, pikseller / geri kazanılmış oran / piksel_wasted oranı) çok daha düşük).

Bu yüzden birçok insan "vektör hızlanma ivmesini" önemsemiyor bile. GPU'lar görev için uygun değil.

NV_path_rendering normdan daha fazla istisnadır ve şablon tamponunu kullanmanın yeni hilesini ortaya koymuşlardır; sıkıştırmayı destekler ve bant genişliği kullanımını önemli ölçüde azaltabilir.

Yine de, NV_path_rendering konusunda şüpheci olmaya devam ediyorum ve biraz googling ile OpenGL (yani önerilen şekilde) kullanırken Qt'nin NVIDIA'nın NV_path_rendering'inden önemli ölçüde daha hızlı olduğunu gösteriyor: NV Yolu oluşturma Başka bir deyişle, NVIDIA'nın slaytlarının "yanlışlıkla" olduğunu Qt. Hata.

Qt geliştiricileri, "Hw hızlandırmalı çizim vektörleri her şeyin daha hızlı olduğunu" iddia etmek yerine, QW hızlandırılmış vektör çizimlerinin her zaman daha iyi olmadığını kabul etmenin daha dürüst olduğunu belirtiyor (görüntülemelerinin nasıl çalıştığını görün: Qt Graphics ve Performance - OpenGL )

Ve anında canlı şerit oluşturma işlemini gerektiren "canlı düzenleme" vektör grafikleri kısmına dokunmadık. Karmaşık svgs'leri düzenlerken, bu aslında ciddi bir ek yük ekleyebilir.

Daha iyi olsun veya olmasın, uygulamalara büyük ölçüde bağlıdır; Asıl sorunuza "neden bulamadıysa", umarım şimdi cevaplanmıştır: çoğu insanı şüpheci kılan ve dikkate almayan birçok dezavantaj ve kısıtlama vardır .

güncelleme: Bahsedilen GPU'lar 64x64 ve 32x32 bloklarda rasterleşmediği için rakamların tamamen temelde olduğuna dikkat çektim, çünkü 8x8 = 64 ve 4x4 = 16. Bu durum yazının sonuçlarını geçersiz kılıyor. Yakında bu yayını daha güncel bilgilerle güncelleyeceğim.

Bu cevabın yazıldığı gibi kimsenin "hızlandırılmış vektör grafikleri" umurunda olmadığının gerçekten doğru olduğunu sanmıyorum .

Nvidia birazcık önemsiyor gibi görünüyor. NV_path_rendering'in başındaki teknik adam olan Kilgard'ın (bundan böyle NVPr'nin parmaklarımı kurtarması) yanı sıra, Nvidia'da VP olan Khronos başkanı Neil Trevett, son birkaç yıl içinde NVPr'yi destekleyebildi; Onun bkz talk1 , talk2 veya talk3 . Ve bu biraz ödedi gibi görünüyor. Bu yazının zamanı olarak NVpr, Google’ın Skia’sında (sırayla Google Chrome’da kullanılıyor) ve bağımsız olarak [Skia’dan] Adobe Illustrator CC’nin beta sürümünde, Kilgard’ın GTC14’teki slaytlarına göre ; Orada verilen görüşmelerin bazı videoları da var: Kilgard ve Adobe. (Intel için çalışır) A Kahire dev de ilgi görünüyor NVpr içinde. Mozilla / Firefox devs de NVpr ile deneyler yaptı ve aslında bu FOSDEM14 konuşmasının gösterdiği gibi GPU ile hızlandırılmış vektör grafiklerini önemsiyorlar .

Microsoft ayrıca, biraz daha önemsiyor çünkü Direct2D'yi yarattılar , çünkü Mozilla'nın yukarıda bahsedilen konuşmadan geldiğini düşünüyorsanız].

Şimdi asıl soruya gelmek için: GPU'ların yol oluşturma için kullanılmasının kolay olmamalarının bazı teknik nedenleri var. Yol görüntülemenin bataklık standardı 3D köşe geometrisinden nasıl farklılaştığını ve GPU yolun hızlanmasını önemsiz kılan şeyin ne olduğunu öğrenmek isterseniz, o zaman Kilgard'ın maalesef OpenGL forumunda bir yere gömülmüş olan çok iyi bir SSS benzeri yazı var .

Direct2D, NVpr ve bunun nasıl çalıştığı hakkında daha fazla ayrıntı için , elbette NVpr'a odaklanan Kilgard'ın Siggraph 2012 belgesini okuyabilirsiniz, ancak daha önceki yaklaşımları araştırmak için iyi bir iş çıkardınız. Hızlı kesmelerin çok iyi çalışmadığını söylemek yeterli ... (PSE sorusunun metninde belirtildiği gibi). Bu yaklaşımda, bu makalede tartışılan ve Kilgard'ın ilk gösterilerinden bazılarında gösterilen, örneğin bu video . Ayrıca, resmi NVpr uzatma belgesinin yıllar boyunca çeşitli performans ayarlamaları detaylandırdığını da unutmam gerekir .

NVpr’in 2011’de Linux’ta çok iyi olmadığı için (ilk yayımlanan uygulamasında), Qt’un Zack Rusin’in 2011 blog yazısında olduğu gibi, vektörlerin / yolların GPU hızlandırmasının Bay Goldberg'in cevabı gibi umutsuz olduğu anlamına gelmez ondan çıkarılmış gibi görünüyor. Aslında Kilgard, bu blog yazısının sonuna, Qt'un hızlı kodu üzerinde 2x-4x iyileşme gösteren güncellenmiş sürücülerle cevap verdi ve Rusin bundan sonra bir şey söylemedi.

Valve Corp. ayrıca GPU ile hızlandırılmış vektör işlemeyi umursar, ancak daha sınırlı bir şekilde font / glif işlemesi ile ilgilidir. TF gibi oyunlarında kullanılan Siggraph 2007'de sunulan GPU ile hızlandırılmış işaretli mesafe alanlarını (SDF) kullanarak büyük ve hızlı bir yazı tipi düzleştirme uygulaması yaptılar; YouTube’da yayınlanan tekniğin bir video gösterimi var (ancak bunu kimin yaptığından emin değilim).

SDF yaklaşımı, Kahire ve pango dev'lerinden biri tarafından GLyphy biçiminde bazı iyileştirmeler gördü ; yazarı linux.conf.au 2014'te bir konuşma yaptı. Çok uzun zamandır izlemeyen versiyon, SDF hesaplamasını vektörde (rasterden ziyade) uzayda daha izlenebilir hale getirmek için Bezier eğrilerine yaylı bir yaklaşım yapmasıdır (Valf ikincisini yapmıştır). Fakat ark-spline yaklaşımı ile bile hesaplama hala yavaştı; ilk versiyonunun 3 fps'de çalıştığını söyledi. Bu yüzden şu anda LOD (ayrıntı düzeyi) biçiminde olan ancak SDF alanında görünen “çok uzakta” ​​olan şeyler için bazı ızgara tabanlı işlemler yapıyor. Bu optimizasyon ile demoları 60 fps'de çalıştı (ve muhtemelen Vsync sınırlıydı). Ancak gölgelendiricileri inanılmaz derecede karmaşıktır ve donanım ve sürücülerin sınırlarını zorlar. “Her sürücü / işletim sistemi kombinasyonu için bir şeyleri değiştirmek zorunda kaldık” satırları boyunca bir şeyler söyledi. Ayrıca, gölgelendirici derleyicilerde önemli hatalar buldu. bazıları daha sonra kendi aygıtlarına göre düzeltildi. Bu yüzden AAA oyun başlıkları geliştirme gibi geliyor ...

Başka bir yapışmada, Microsoft'un Direct2D uygulamasını geliştirmek için , eğer varsa Windows 8 tarafından kullanılan bir donanımla biraz yeni GPU donanımını devreye soktuğunu / belirttiği anlaşılmaktadır . Buna, Microsoft’un patent başvurusunda yazılan, gerçekte ne gibi göründüğü konusunda biraz yanıltıcı olan bir isim olan hedeften bağımsız rasterleştirme ( TIR ) adı verilir . AMD, TIR'in 2B vektör grafiklerdeki performansı% 500 artırdığını iddia etti . Ve biraz vardı "söz düellosuna" AMD'nin GCN tabanlı GPU'lar yapmak oysa Kepler GPU, bunu yok çünkü onları ve Nvidia arasında. Nvidia onayladıBunun gerçekten de yeni bir donanım olduğu, sadece bir sürücü güncellemesinin sağlayabileceği bir şey değil. Sinofsky'nin blog yazısı , TIR'ın gerçek kriterleri de dahil olmak üzere birkaç ayrıntıya daha sahip. Sadece genel fikir bitlerinden alıntı yapıyorum:

düzensiz geometri oluştururken performansı arttırmak için (örneğin, bir haritadaki coğrafi sınırlar), Hedef Bağımsız Rasterleştirme veya TIR adı verilen yeni bir grafik donanım özelliği kullanıyoruz.

TIR, Direct2D'nin mozaikleme işleminde daha az CPU döngüsü harcamasını sağlar, böylece görsel kaliteden ödün vermeden GPU'ya çizim talimatlarını daha hızlı ve verimli bir şekilde verebilir. TIR, DirectX 11.1'i destekleyen Windows 8 için tasarlanmış yeni GPU donanımında mevcuttur.

Aşağıda, DirectX 11.1 GPU'sundaki TIR'yi destekleyen çeşitli SVG dosyalarından kenar yumuşatma geometrisi oluşturmak için performans iyileştirmesini gösteren bir grafik bulunmaktadır: [chart snipped]

TIR tasarımı için grafik donanım ortaklarımızla [AMD okuyarak] yakın bir şekilde çalıştık. Bu ortaklık nedeniyle dramatik gelişmeler sağlandı. DirectX 11.1 donanımı bugün piyasada ve TIR özellikli ürünlerin daha geniş bir şekilde kullanılabilmesini sağlamak için ortaklarımızla birlikte çalışıyoruz.

Galiba bu, Win 8'in Metro UI fiyaskolarında dünyaya en çok kaybedilen şeylerden biriydi ...

Muhtemelen, faydaları maliyetlerden daha ağır basmadığındandır.