Rendering Berbasis Sparse Strip untuk Mewujudkan Grafik 2D Berkinerja Tinggi di CPU [pdf]

• Mengusulkan pendekatan yang memanfaatkan struktur sparse strip untuk meningkatkan efisiensi dalam rendering grafik 2D berbasis CPU
• Penelitian yang berfokus pada struktur data dan metode pemrosesan untuk mewujudkan rendering berkinerja tinggi di CPU alih-alih GPU
• Melalui representasi data sparse, penggunaan memori dikurangi dan kecepatan rendering tetap tinggi bahkan pada adegan yang kompleks
• Desain yang meningkatkan efisiensi pemrosesan paralel dan pemanfaatan cache dibanding metode rendering CPU konvensional
• Penelitian yang menunjukkan kemungkinan mewujudkan grafik 2D berkualitas tinggi hanya dengan CPU

---

Gambaran penelitian

• Makalah ini menargetkan rendering grafik 2D berkinerja tinggi di CPU dan mengeksplorasi cara untuk mengurangi ketergantungan pada GPU
• Konsep intinya adalah struktur data sparse strip, yang menyimpan hanya bagian yang diperlukan secara efisien alih-alih data kontinu pada tingkat piksel
• Melalui struktur ini, dicapai pengurangan biaya akses memori dan peningkatan kecepatan rendering

Struktur sparse strip

• Strip merepresentasikan rentang piksel berurutan dalam gambar 2D, dan dalam bentuk sparse hanya bagian yang diperlukan yang disimpan
• Metode ini sangat efisien terutama pada gambar dengan banyak ruang kosong atau grafik vektor yang kompleks
• Dibanding rendering berbasis buffer penuh yang ada, pendekatan ini memberikan penghematan penggunaan memori dan peningkatan efisiensi cache

Kinerja dan implementasi

• Memaksimalkan kinerja pemrosesan paralel dengan memanfaatkan instruksi SIMD dan multithreading pada CPU
• Hasil eksperimen menunjukkan bahwa adegan yang sama dapat diproses tanpa GPU dengan kinerja pada tingkat rendering real-time
• Implementasi ditulis berbasis C++ dan diuji pada berbagai resolusi serta tingkat kompleksitas adegan

Kemungkinan penerapan

• Dapat dimanfaatkan di lingkungan yang berpusat pada CPU seperti rendering UI, mesin grafik vektor, dan pipeline 2D pada game engine
• Juga dapat mendukung pemrosesan grafik 2D berkinerja tinggi pada sistem embedded atau lingkungan server yang GPU-nya terbatas

Kesimpulan

• Pendekatan berbasis sparse strip membuktikan peredaan bottleneck pada rendering CPU dan peningkatan efisiensi memori
• Menunjukkan potensi sebagai model alternatif terhadap struktur pemrosesan grafik yang bergantung pada GPU
• Untuk angka tambahan atau data perbandingan, perlu merujuk ke isi PDF asli

[GN⁺]

Komentar Hacker News

• Struktur struct Strip yang didefinisikan dalam makalah tampak berukuran 64 bit (8 byte), tetapi di teks tertulis bahwa satu strip berukuran 64 byte
  Jika dihitung, ukurannya sebenarnya terlihat sekitar 259×8 + 7296 ≈ 9KB. Sepertinya ada kesalahan satuan

  • Saya penulisnya. Benar, itu kesalahan karena tertukar antara bit dan byte. Terima kasih sudah menunjukkannya
  • Saya belum sempat menelusuri seluruh kodenya, tetapi di makalah ada bagian terkait multithreading
    Bisa jadi hanya salah ketik, tetapi mungkin juga setiap strip dialokasikan per cache line (64 byte).
    Jika begitu, false sharing bisa dihindari, jadi mungkin renderernya memang sengaja dibuat seperti itu
  • Saya juga berpikir begitu. Di paragraf itu, penggunaan memori tampaknya dinilai terlalu tinggi.
    Makalah ini terutama berfokus pada perbandingan waktu eksekusi, bukan perbandingan kebutuhan penyimpanan

• Blaze: Parallel Rasterization on CPU juga layak dilihat

  • Terima kasih atas infonya. Saya belum tahu proyek ini, tetapi angka benchmark-nya cukup mengesankan
  • Demonya benar-benar sangat cepat

• Proyek ini menarik. Jika melihat bagian 3.9, output-nya berbentuk bitmap, jadi pada akhirnya gambar tampaknya tetap harus disalin ke GPU
  Karena Skia sedang beralih ke WebGPU, dan WebGPU mendukung compute shader, 2D graphics tampaknya makin menjadi masalah yang sudah terpecahkan dari sisi portabilitas dan performa
  Namun, masih ada kasus di mana renderer CPU tetap berguna — misalnya di lingkungan web, shader harus dikompilasi saat runtime ketika halaman dimuat
  Secara teori, mungkin saja memakai renderer CPU seperti JS JIT di awal lalu beralih ketika shader GPU sudah siap
  Keuntungan lainnya adalah ukuran biner yang kecil. WebGPU (berbasis dawn) cukup besar
  Tautan referensi

  • Benar, output-nya adalah bitmap sehingga harus diunggah ke GPU.
    Di proyek yang lebih besar juga ada versi bernama Vello Hybrid, yang mengerjakan operasi geometri di CPU dan pixel painting di GPU
    Ide memakai renderer CPU selama kompilasi shader juga sempat dipertimbangkan, tetapi belum diimplementasikan
  • Renderer CPU sangat berguna khususnya untuk test runner. Jika output-nya berupa gambar atau screenshot, tidak perlu menyalin ke GPU
    Justru jika dirender di GPU, gambar itu harus disalin lagi, jadi kurang efisien
  • Pada arsitektur memori terpadu (misalnya Apple Silicon), tidak perlu menyalin ke GPU. Memori yang dipakai sama, jadi biayanya nyaris tidak ada

• Baru-baru ini saya menulis kode untuk merender lintasan N-body presisi tinggi dengan jutaan vertex,
  dan saya penasaran apakah representasi RLE yang diusulkan dalam makalah ini akan bekerja baik jika diimplementasikan di GPU sambil tetap mempertahankan kesederhanaannya
  Video demo

• Menarik. Saya ingin melihat performa single-core dari renderer-renderer yang dibandingkan.
  Itu tampaknya akan menunjukkan efisiensi kodenya. Renderer yang populer mungkin lebih lambat, tetapi memakai CPU lebih sedikit

  • Di makalah ada bagian perbandingan performa single-core
    Selain itu, hasilnya juga bisa dilihat di benchmark resmi Blend2D atau
    vello_chart yang saya buat dengan tambahan beberapa renderer

• Apakah salah satu pembimbingnya, Raph Levien, adalah penulis pustaka Libart yang dulu itu?

• Agak di luar topik, tetapi saya penasaran sejak kapan pratinjau PDF di GitHub mulai memuat hanya sebagian halaman
  Rasanya lebih baik seperti dulu, memuat seluruh PDF sekaligus lalu membiarkan browser yang merendernya

• Saya penasaran apakah ada benchmark untuk memverifikasi correctness renderer

  • Cornell box awalnya dibuat untuk tujuan seperti ini
    Caranya dengan mengukur radiosity dari adegan nyata lalu membandingkannya dengan hasil simulasi
    Dalam rendering real-time, kadang pembandingnya adalah renderer offline seperti Arnold atau Octane
    Wiki Cornell box
  • Itu tergantung pada apa yang dimaksud dengan “correctness”
    Tidak ada renderer yang mereproduksi dunia nyata secara sempurna; semuanya menerima trade-off sampai tingkat tertentu