Menambahkan ke daftar dari banyak fitur menarik di Linux 5.19 adalah API impor/ekspor pagar DMA-BUF baru untuk meningkatkan penggunaan sinkronisasi eksplisit pada desktop Linux untuk membantu Vulkan dan memungkinkan lebih banyak desktop Linux untuk bergerak di masa mendatang ke sinkronisasi yang lebih eksplisit model.
Mantan pengembang driver grafis Intel Vulkan Jason Ekstrand yang bergabung dengan Collabora awal tahun ini untuk terus mengerjakan tumpukan grafis Linux hulu telah banyak bekerja selama beberapa bulan terakhir untuk meningkatkan model sinkronisasi eksplisit untuk Linux setelah bertahun-tahun Linux desktop yang difokuskan pada sinkronisasi implisit.
Dalam entri blog, Ekstrand merangkum panjang lebar masalah sinkronisasi implisit/eksplisit bagi mereka yang tertarik dengan semua detail teknis tentang tantangan yang ada, bagaimana Vulkan dan API grafik/komputasi modern memaksa sinkronisasi eksplisit, dan antarmuka baru yang hadir di Linux 5.19 untuk membantu menggerakkan Linux ke arah yang benar.
Beberapa komentar kunci Jason meliputi:
Jadi, bagaimana kita menyatukan sinkronisasi implisit dan eksplisit? Biarkan ruang pengguna mengekstrak dan mengatur pagar itu sendiri, tentu saja! API baru, yang seharusnya ada di Linux 5.19, menambahkan dua ioctl baru pada deskriptor file dma-buf yang memungkinkan ruang pengguna untuk mengekstrak dan menyisipkan pagar secara langsung. Di ruang pengguna, pagar dma ini diwakili oleh file sinkronisasi. File sinkronisasi membungkus pagar dma yang mengubahnya menjadi deskriptor file yang dapat diteruskan oleh ruang pengguna dan menunggu melalui poll(). Ioctl pertama mengekstrak semua pagar dari objek reservasi dma-buf dan mengembalikannya ke ruang pengguna sebagai file sinkronisasi tunggal. Dibutuhkan parameter flags yang memungkinkan Anda menentukan apakah Anda berharap untuk membaca data di dma-buf, menulisnya, atau keduanya. Jika Anda menentukan hanya-baca, file sinkronisasi yang dikembalikan hanya akan berisi pagar tulis tetapi jika Anda menentukan tulis atau baca-tulis, file sinkronisasi yang dikembalikan akan menunggu di semua pagar sinkronisasi implisit yang saat ini ada di objek reservasi. Ioctl kedua memungkinkan userspace untuk menambahkan file sinkronisasi ke objek reservasi. Ini juga membutuhkan tanda baca/tulis untuk memungkinkan Anda mengontrol apakah pagar yang baru ditambahkan dianggap sebagai pagar tulis atau hanya pagar baca.
…
Solusi ini memungkinkan kami meluncurkan dukungan sinkronisasi eksplisit yang lebih baik kepada pengguna dengan mulus. Driver Vulkan bekerja dengan mulus dengan compositor yang hanya memahami sinkronisasi implisit dan, jika compositor Wayland mendapatkan dukungan sinkronisasi eksplisit yang memadai, kami dapat melakukan transisi ke sana setelah compositor siap. Kami dapat mendorong ini dari sisi Wayland terlebih dahulu dan meluncurkan dukungan sinkronisasi eksplisit ke sekelompok compositor Wayland dan mengatakan Anda memerlukan compositor Wayland baru jika Anda ingin mendapatkan pengalaman Vulkan secepat mungkin. Namun, itu akan menjadi lebih banyak pekerjaan. Itu akan melibatkan banyak protokol, menambahkan dukungan file sinkronisasi ke KMS, dan menyentuh setiap penyusun Wayland yang secara kolektif kita pedulikan. Juga akan jauh lebih sulit untuk mendapatkan transisi 100% ke sinkronisasi eksplisit karena Anda hanya dapat menggunakan sinkronisasi eksplisit tanpa mengulur waktu jika setiap komponen di seluruh jalur tampilan mendukungnya. Kemungkinan, jika kita mengambil jalan itu, beberapa konfigurasi akan terjebak dengan solusi hacky lama selamanya dan kita tidak akan pernah bisa menghapus kode itu dari Mesa.
