Mengapa grafis vektor yang dipercepat perangkat keras tidak diluncurkan?

Saya sedang mengerjakan sebuah aplikasi yang melibatkan manipulasi real-time jalur vektor pada 60fps, dan saya sangat terkejut dengan betapa sedikitnya informasi yang ada pada subjek tersebut. Pada awalnya, saya mencoba menerapkan ide saya menggunakan CoreGraphics, tetapi itu tidak berfungsi dengan baik untuk tujuan saya . Saya kemudian menemukan bahwa ada standar Khronos untuk grafik vektor akselerasi perangkat keras yang disebut OpenVG , dan untungnya orang yang baik hati telah menulis semi-implementasi OpenGL ES yang disebut MonkVG .

Tetapi terlepas dari kenyataan bahwa OpenVG adalah API yang praktis sangat berguna, tampaknya lebih atau kurang ditinggalkan oleh Khronos. Menurut Wikipedia, sejak 2011, kelompok kerja "memutuskan untuk ... tidak melakukan pertemuan reguler untuk standardisasi lebih lanjut". Dokumentasi, yang terbaik yang dapat saya temukan, hanya terdiri dari satu kartu referensi. Dan terlebih lagi, hampir tidak ada contoh OpenVG di mana pun di internet. Saya dapat menemukan ratusan tutorial OpenGL dalam sekejap mata, tetapi OpenVG tampaknya sangat hilang.

Anda akan berpikir bahwa vektor yang dipercepat perangkat keras akan lebih penting dalam dunia saat ini dengan resolusi yang meningkat pesat, dan tampaknya banyak perusahaan menerapkan cara mereka sendiri dalam melakukan ini. Misalnya, Qt dan Flash memiliki skema untuk vektor akselerasi perangkat keras, dan banyak alat Adobe memiliki akselerasi perangkat keras sebagai opsi. Tapi sepertinya roda itu diciptakan kembali ketika standar sudah ada!

Apakah ada sesuatu yang saya lewatkan tentang OpenVG yang membuatnya tidak cocok untuk penggunaan di dunia nyata? Atau apakah standar itu tidak tepat waktu dan sekarang standarnya tidak jelas? Apakah Anda pikir ada ruang untuk API standar untuk grafik vektor akselerasi perangkat keras di masa depan, atau akankah lebih mudah menggunakan teknik berbasis raster tradisional? Atau vektor hanya dalam perjalanan keluar, sebelum mereka pernah masuk?

pembaruan: Lihat bawah balasan

Jawaban ini datang agak terlambat, tetapi saya berharap untuk menyinari orang lain (terutama sekarang komite standar C ++ ingin memasukkan Kairo ke dalam std):

Alasan tidak ada yang benar-benar peduli tentang "grafik vektor dipercepat" adalah karena cara kerja GPU. GPU bekerja menggunakan paralelisasi besar dan kemampuan SIMD untuk mewarnai setiap piksel. AMD biasanya bekerja dalam blok 64x64 8x8 piksel sementara kartu NVIDIA biasanya bekerja dalam 32x32 4x4 piksel [Lihat pembaruan di bagian bawah]

Bahkan jika mereka membuat segitiga 3D, GPU bekerja pada seluruh paha depan yang dicakup oleh segitiga ini. Jadi, jika segitiga tidak mencakup semua 8x8 piksel dalam blok (atau 4x4 dalam kasus nvidia) GPU akan menghitung warna piksel yang terbuka dan kemudian membuang hasilnya. Dengan kata lain, kekuatan pemrosesan untuk piksel yang terbongkar terbuang sia-sia. Meskipun ini tampak boros, ini bekerja sangat baik untuk rendering segitiga 3D besar ketika dipasangkan dengan sejumlah besar inti GPU (info lebih rinci di sini: Mengoptimalkan rasterizer dasar ).

Jadi, ketika kita melihat kembali rasterisasi berbasis vektor, Anda akan melihat bahwa ketika menggambar garis, bahkan jika tebal, ada ruang kosong besar. Banyak kekuatan pemrosesan yang terbuang, dan yang lebih penting bandwidth (yang merupakan penyebab utama konsumsi daya, dan sering hambatan) Jadi, kecuali Anda menggambar garis horizontal atau vertikal dengan beberapa ketebalan 8, dan itu sempurna sejalan dengan Batas 8 pixel, banyak daya pemrosesan dan bandwidth akan terbuang sia-sia.

Jumlah "pemborosan" dapat dikurangi dengan menghitung hull to render (seperti NV_path_rendering), tetapi GPU masih dibatasi hingga 8x8 / 4x4 blok (juga mungkin skala tolok ukur GPU NVIDIA lebih baik dengan resolusi yang lebih tinggi, piksel_covered / piksel_wasted rasio jauh lebih rendah).

Inilah sebabnya mengapa banyak orang bahkan tidak peduli tentang "percepatan vektor hw". GPU sama sekali tidak cocok untuk tugas itu.

NV_path_rendering lebih merupakan pengecualian daripada norma, dan mereka telah memperkenalkan trik baru menggunakan buffer stensil; yang mendukung kompresi dan secara signifikan dapat mengurangi penggunaan bandwidth.

Meskipun demikian, saya tetap skeptis terhadap NV_path_rendering, dan dengan sedikit googling menunjukkan bahwa Qt ketika menggunakan OpenGL (alias cara yang disarankan) secara signifikan lebih cepat daripada NV_path_rendering NVIDIA: NV Path rendering Dengan kata lain, slide NVIDIA "secara tidak sengaja" membandingkan versi XRender dari XRender. Qt. Ups.

Alih-alih berargumen bahwa "semua gambar vektor dengan akselerasi hw lebih cepat", pengembang Qt lebih jujur ​​mengakui gambar vektor akselerasi HW tidak selalu lebih baik (lihat bagaimana cara kerja rendering mereka menjelaskan: Qt Graphics and Performance - OpenGL )

Dan kami belum menyentuh bagian dari grafik vektor "penyuntingan langsung", yang membutuhkan pembuatan strip segitiga dengan cepat. Saat mengedit svgs kompleks, ini sebenarnya bisa menambah overhead serius.

Apakah lebih baik atau tidak, itu sangat tergantung pada aplikasi; mengenai pertanyaan awal Anda "mengapa itu tidak lepas landas", saya harap sekarang dijawab: ada banyak kelemahan dan kendala untuk dipertimbangkan, sering membuat banyak orang skeptis dan bahkan mungkin membiasakan mereka untuk tidak menerapkannya .

pembaruan: Saya telah menunjukkan bahwa jumlahnya benar-benar tidak masuk akal, karena GPU yang disebutkan tidak dirasterisasi dalam blok 64x64 & 32x32 melainkan 8x8 = 64 dan 4x4 = 16. Ini cukup banyak membatalkan kesimpulan posting. Saya akan segera memperbarui posting ini nanti dengan informasi terkini.

Saya tidak berpikir itu benar bahwa tidak ada yang benar-benar peduli tentang "grafik vektor dipercepat" seperti yang tertulis dalam jawaban ini .

Nvidia agaknya peduli. Selain Kilgard yang adalah orang teknis utama di NV_path_rendering (selanjutnya NVpr untuk menyelamatkan jari saya), presiden Khronos, Neil Trevett, yang juga seorang VP di Nvidia, telah mempromosikan NVpr sebanyak yang dia bisa dalam beberapa tahun terakhir; lihat ceramahnya1 , talk2 atau talk3 . Dan itu tampaknya terbayar sedikit. Pada saat penulisan ini, NVpr sekarang digunakan di Google Skia (yang pada gilirannya digunakan di Google Chrome) dan secara mandiri [Skia] dalam versi beta dari Adobe Illustrator CC (beta), menurut slide Kilgard di GTC14 ; ada juga beberapa video pembicaraan yang diberikan di sana: Kilgard dan Adobe. Dev Kairo (yang bekerja untuk Intel) juga tampaknya tertarik pada NVpr. Pengembang Mozilla / Firefox juga bereksperimen dengan NVpr dan mereka benar-benar peduli tentang GPU vektor grafis dipercepat secara umum seperti yang ditunjukkan oleh talk show FOSDEM14 ini .

Microsoft juga peduli sedikit karena mereka menciptakan Direct2D , yang digunakan cukup luas [jika Anda percaya Mozilla dev dari pembicaraan tersebut].

Sekarang untuk sampai ke titik pertanyaan awal: memang ada beberapa alasan teknis mengapa menggunakan GPU untuk rendering jalur tidak mudah. Jika Anda ingin membaca tentang bagaimana render jalur berbeda dari geometri vertex 3D standar-rawa dan apa yang membuat akselerasi render jalur Path non-sepele, maka Kilgard memiliki posting seperti-FAQ yang sangat bagus , yang sayangnya terkubur di suatu tempat di forum OpenGL.

Untuk detail lebih lanjut tentang bagaimana Direct2D, NVpr dan pekerjaan seperti itu, Anda bisa membaca makalah Kilgard's Siggraph 2012 , yang tentu saja berfokus pada NVpr, tetapi juga melakukan pekerjaan yang baik dengan survei pendekatan sebelumnya. Cukuplah untuk mengatakan bahwa peretasan cepat tidak berfungsi dengan baik ... (seperti yang tertulis dalam teks pertanyaan PSE.) Ada perbedaan kinerja yang signifikan antara pendekatan-pendekatan ini sebagaimana dibahas dalam makalah itu dan ditunjukkan dalam beberapa demo awal Kilgard, misalnya di video ini . Saya juga harus mencatat bahwa dokumen ekstensi resmi NVpr merinci beberapa penyempurnaan kinerja selama bertahun-tahun.

Hanya karena NVpr tidak begitu hebat di Linux pada tahun 2011 (dalam implementasi pertama yang dirilis), seperti yang dikatakan oleh posting blog 2011 dari Qt's Zack Rusin, itu tidak berarti bahwa akselerasi GPU dari vektor / jalur tidak ada harapan seperti jawaban Mr. Goldberg tampaknya telah disimpulkan dari itu. Kilgard sebenarnya telah menjawab di akhir posting blog itu dengan driver yang diperbarui menunjukkan peningkatan 2x-4x atas kode Qt yang lebih cepat dan Rusin tidak mengatakan apa-apa setelah itu.

Valve Corp juga peduli tentang rendering vektor berakselerasi GPU, tetapi dengan cara yang lebih terbatas, terkait dengan rendering font / glyph. Mereka memiliki implementasi font besar yang bagus dan cepat dengan menggunakan bidang jarak yang ditandatangani GPU (SDF) yang diperlihatkan di Siggraph 2007 , yang digunakan dalam gim mereka seperti TF; ada demonstrasi video dari teknik yang diposting di YouTube (tapi saya tidak yakin siapa yang membuatnya).

Pendekatan SDF telah melihat beberapa penyempurnaan oleh salah satu pengembang Cairo & pango dalam bentuk GLyphy ; penulisnya memberikan ceramah di linux.conf.au 2014. Versi terlalu lama-tidak-menonton adalah bahwa ia melakukan pendekatan busur-spline dari kurva Bezier untuk membuat perhitungan SDF lebih mudah ditelusur dalam ruang vektor (daripada di raster) (Valve melakukan yang terakhir). Tetapi bahkan dengan pendekatan arc-spline, perhitungannya masih lambat; katanya versi pertamanya berjalan pada 3 fps. Jadi dia sekarang melakukan pemusnahan berbasis grid untuk hal-hal yang "terlalu jauh", yang terlihat seperti bentuk LOD (level detail) tetapi di ruang SDF. Dengan optimasi ini, demo-nya berjalan pada 60 fps (dan itu mungkin terbatas Vsync). Namun shadernya sangat kompleks dan mendorong batas perangkat keras dan driver. Dia mengatakan sesuatu di sepanjang baris: "untuk setiap kombinasi driver / OS kami harus mengubah sesuatu". Dia juga menemukan bug signifikan dalam kompiler shader, beberapa di antaranya kemudian diperbaiki oleh devs masing-masing. Jadi kedengarannya seperti pengembangan judul game AAA ...

Pada taktik lain, tampaknya Microsoft telah menugaskan / menetapkan sedikit perangkat keras GPU baru untuk meningkatkan implementasi Direct2D mereka, perangkat keras yang digunakan oleh Windows 8, jika tersedia . Ini disebut target-independent rasterization ( TIR ), sebuah nama yang agak menyesatkan mengenai apa yang sebenarnya dilakukan oleh barang-barang itu, yang dijabarkan dalam aplikasi paten Microsoft . AMD mengklaim bahwa TIR meningkatkan kinerja dalam grafik vektor 2D hingga 500% . Dan ada sedikit "perang kata-kata" antara mereka dan Nvidia karena Kepler GPU tidak memilikinya, sedangkan GPU AMD berbasis GCN memilikinya. Nvidia telah mengkonfirmasibahwa ini memang sedikit perangkat keras baru, bukan hanya sesuatu yang dapat disediakan oleh pembaruan driver. Posting blog Sinofsky memiliki beberapa detail lagi, termasuk beberapa tolok ukur TIR yang sebenarnya. Saya hanya mengutip bit ide umum:

untuk meningkatkan kinerja saat merender geometri tidak teratur (misalnya batas geografis pada peta), kami menggunakan fitur perangkat keras grafis baru yang disebut Target Independent Rasterization, atau TIR.

TIR memungkinkan Direct2D untuk menghabiskan lebih sedikit siklus CPU pada tessellation, sehingga dapat memberikan instruksi menggambar ke GPU lebih cepat dan efisien, tanpa mengorbankan kualitas visual. TIR tersedia dalam perangkat keras GPU baru yang dirancang untuk Windows 8 yang mendukung DirectX 11.1.

Di bawah ini adalah bagan yang menunjukkan peningkatan kinerja untuk rendering geometri anti-alias dari berbagai file SVG pada DirectX 11.1 GPU yang mendukung TIR: [chart snipped]

Kami bekerja erat dengan mitra perangkat keras grafis kami [baca AMD] untuk merancang TIR. Peningkatan dramatis dimungkinkan karena kemitraan itu. Perangkat keras DirectX 11.1 sudah tersedia di pasaran saat ini dan kami bekerja sama dengan mitra kami untuk memastikan lebih banyak produk yang mampu TIR tersedia secara luas.

Saya kira ini adalah salah satu hal menyenangkan yang ditambahkan Win 8 yang sebagian besar hilang ke dunia dalam kegagalan Metro UI ...

Mungkin karena manfaatnya tidak melebihi biaya.