Ikhtisar Singkat Vulkan API

Jadi, apa masalahnya dengan Vulkan API baru ini, dan mengapa kita harus peduli?

Inilah Vulkan API dalam seratus kata atau kurang: Ini adalah API low-overhead, dekat-ke-logam untuk grafik 3D dan aplikasi komputasi. Vulkan pada dasarnya adalah tindak lanjut dari OpenGL. Ini awalnya disebut sebagai "inisiatif OpenGL generasi berikutnya," dan ini mencakup beberapa bagian dari Mantle API AMD. Vulkan seharusnya memberikan banyak keuntungan dibandingkan API GPU lainnya, memungkinkan dukungan lintas platform yang unggul, dukungan yang lebih baik untuk prosesor multithreaded, beban CPU yang lebih rendah, dan sedikit agnostisisme OS. Ini juga harus membuat pengembangan driver lebih mudah, dan memungkinkan pra-kompilasi driver, termasuk penggunaan shader yang ditulis dalam berbagai bahasa.

Itu adalah 93 kata, jadi jika Anda tidak tertarik, Anda dapat melewatkan 3.500 kata berikutnya. Sebaliknya, jika Anda ingin tahu lebih banyak tentang API grafis mendatang yang akan bersama kami selama bertahun-tahun yang akan datang, saya akan mulai dari dasar-dasarnya.

Bagaimana Vulkan API Muncul

Vulkan awalnya diumumkan oleh Khronos Group pada Maret 2015, dengan tanggal peluncuran tentatif ditetapkan untuk akhir 2015. Jika Anda tidak akrab dengan Khronos, ini adalah konsorsium industri nirlaba yang didirikan lima belas tahun yang lalu oleh beberapa nama terbesar di dunia. industri grafis, termasuk ATI (sekarang menjadi bagian dari AMD), Nvidia, Intel, Silicon Graphics, Discrete, dan Sun Microsystems. Bahkan jika Anda belum pernah mendengar tentang Khronos, Anda mungkin pernah mendengar beberapa standar mereka, seperti: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA, dan glTF.

Sekarang, Anda mungkin berpikir "Ah, itu orang-orang itu," jadi saya bisa melewatkan sisa intro dan fokus pada API itu sendiri.

Tidak seperti pendahulunya, atau pendahulunya, Vulkan dirancang dari bawah ke atas untuk berjalan di berbagai platform, mulai dari ponsel dan tablet, hingga konsol game dan desktop kelas atas. Desain yang mendasari API berlapis, atau harus kita katakan modular, sehingga memungkinkan pembuatan arsitektur umum, namun dapat diperluas untuk validasi kode, debugging, dan pembuatan profil, tanpa memengaruhi kinerja. Krhonos mengklaim pendekatan berlapis akan memberikan lebih banyak fleksibilitas, mengkatalisasi inovasi yang kuat dalam alat GPU lintas-vendor, dan memberikan lebih banyak kontrol GPU langsung yang diminta oleh mesin game yang canggih.

Sekarang, saya mengerti bahwa banyak teknofil memiliki keraguan tentang istilah pemasaran seperti "fleksibel", "dapat diperluas", dan "modular", tetapi kali ini kita berurusan dengan McCoy yang sebenarnya. Faktanya, itulah ide dasar di balik Vulkan: Ini dibayangkan sebagai API untuk massa, dari game anak-anak di smartphone, hingga orang tua mereka merancang bangunan dan game di workstation.

Secara teori, Vulkan dapat digunakan dalam perangkat keras komputasi paralel, untuk mengontrol puluhan miliar inti GPU, dalam perangkat kecil yang dapat dikenakan dan mainan drone, dalam printer 3D, mobil, kit VR, dan hampir semua hal lain dengan GPU yang kompatibel di dalamnya.

Untuk detail lebih lanjut, saya sarankan Anda melihat ikhtisar resmi Vulkan dalam PDF.

DNA Mantel AMD

Jika pendekatan close-to-metal terdengar sangat familiar, Anda mungkin telah mengikuti pengumuman GPU AMD selama dua tahun terakhir atau lebih. AMD mengejutkan pengamat industri ketika mengumumkan Mantle API pada tahun 2013, dan sekali lagi mengejutkan mereka ketika memutuskan untuk menghentikan API, mengumumkan pada Maret 2015 bahwa mereka tidak akan merilis Mantle 1.0 sebagai SDK publik. Singkatnya, Mantle berjanji untuk memberikan peningkatan kinerja dan efisiensi yang signifikan dalam beberapa situasi, terutama di bagian depan CPU karena akan mengurangi overhead pemrosesan. Kedengarannya seperti ide yang bagus, karena gamer dapat menggabungkan PC kustom dengan prosesor yang agak lambat dan menginvestasikan lebih banyak uang untuk kartu grafis kelas atas. Kedengarannya sangat nyaman untuk AMD juga, karena perusahaan belum memiliki CPU kelas atas yang kompetitif selama bertahun-tahun, meskipun masih memiliki produk GPU yang bagus.

Saat para fanboy AMD yang menangis berkumpul untuk berduka atas meninggalnya penyelamat mereka, Mantle secara ajaib dibangkitkan. Kabar baik datang dalam bentuk posting blog, yang ditulis oleh AMD VP Visual and Perceptual Computing, Raja Koduri. Secara kebetulan, sesuai dengan tema religi, pada suatu kesempatan Koduri mengadakan khotbah di atas gunung, saat acara peluncuran AMD Hawaii tahun 2013, tapi saya ngelantur.

Sambil bercanda, tim Koduri melakukan pekerjaan dengan baik. Sementara Mantle tidak menjadi standar industri baru, itu menjadi dasar bagi Vulkan. Perbedaan terbesar adalah bahwa Vulkan tidak akan terbatas pada perangkat keras AMD GCN; itu akan bekerja pada lebih banyak GPU dari vendor yang berbeda. Anda mungkin dapat melihat ke mana saya akan pergi dengan ini; sedikit lebih baik untuk memiliki satu API grafis low-overhead yang bekerja pada sistem operasi dan platform perangkat keras yang berbeda daripada memiliki API berpemilik untuk arsitektur GPU, OS, dan sebagainya yang berbeda.

Vulkan API hanya mengambil sebagian besar kue Mantle dan membagikannya kepada semua orang, terlepas dari OS, perangkat keras, ras, atau agama.

Oh, dan ada satu hal lagi: Mantle akhirnya memaksa Microsoft dan Khronos akhirnya melakukan sesuatu tentang pengasapan dan inefisiensi DirectX dan OpenGL. Itu adalah tendangan yang lembut dan ramah di bagian belakang, atau "badonkadonk," seperti yang dikatakan oleh sesama Toptaler.

Bagaimana Vulkan Dibandingkan Dengan OpenGL?

Jelas, saya perlu menguraikan perbedaan mendasar antara Vulkan dan OpenGL. Khronos datang dengan ilustrasi sederhana, yang menunjukkan seberapa banyak driver bloat dapat dihilangkan dengan API baru.

Vulkan memungkinkan aplikasi untuk lebih dekat dengan logam, sehingga menghilangkan kebutuhan akan banyak memori dan manajemen kesalahan, serta banyak sumber bahasa bayangan. Pengemudi akan lebih ringan, lebih ramping dan lebih kejam. Vulkan hanya akan mengandalkan bahasa perantara SPIR-V, dan karena memiliki API terpadu untuk pasar seluler, desktop, dan konsol, Vulkan juga harus mendapatkan perhatian yang lebih lembut dan penuh kasih dari pengembang.

Tapi tunggu, bukankah ini hanya memberikan lebih banyak pekerjaan kepada pengembang game? Tentu, mereka akan dapat menggunakan perangkat keras dengan lebih efisien, tetapi bagaimana dengan jam kerja mereka sendiri? Di sinilah pendekatan ekosistem berlapis memasuki keributan.

Pengembang akan dapat memilih tiga tingkat yang berbeda, atau tingkatan, dari ekosistem Vulkan.

• Gunakan Vulkan secara langsung untuk fleksibilitas dan kontrol maksimum.
• Gunakan pustaka dan lapisan Vulkan untuk mempercepat pengembangan.
• Gunakan Vulkan melalui mesin game siap pakai yang dioptimalkan sepenuhnya melalui API baru.

Opsi pertama jelas tidak untuk semua orang, tetapi saya menduga itu akan menjadi perangkat lunak pembandingan yang bagus. Khronos mengharapkan opsi kedua menjadi "area yang kaya untuk inovasi" karena banyak utilitas dan lapisan akan berada di sumber terbuka, dan akan memudahkan transisi dari OpenGL. Jika penerbit memiliki beberapa judul OpenGL yang perlu diubah dan diperbarui, inilah yang akan mereka gunakan.

Opsi terakhir mungkin yang paling menggiurkan karena angkat berat telah dilakukan oleh industri kelas berat seperti Unity, Oxide, Blizzard, Epic, EA, Valve dan lain-lain.

Berikut adalah tabel cepat OpenGL vs. Vulkan:

Sejujurnya, saya tidak berpikir adil untuk membandingkan keduanya. Vulkan adalah turunan Mantle, sedangkan OpenGL adalah mastodon dengan bagasi senilai 20 tahun. Vulkan seharusnya membuang banyak barang warisan; itulah intinya. Vulkan seharusnya merampingkan pengujian dan implementasi, membuat driver lebih ramping, dan meningkatkan portabilitas program shader melalui bahasa perantara SPIR-V.

Ini membawa kita ke pertanyaan berikutnya. Apa sebenarnya arti Vulkan bagi pengembang?

SPIR-V Diharapkan Mengubah Ekosistem Bahasa

Jadi di mana SPIR-V berperan, dan apa yang terjadi pada GLSL lama yang bagus?

GSLS akan tetap hidup untuk saat ini, dan ini akan menjadi bahasa shading pertama yang didukung oleh Vulkan. Penerjemah GLSL ke SPIR-V akan melakukan pekerjaan berat, dan voila!, Anda akan menyiapkan SPIR-V untuk memberi makan runtime Vulkan yang lapar. Pengembang game akan dapat menggunakan back-end SPIR-V dan Vulkan, mungkin mengandalkan front-end compiler open-source. Selain GLSL, Vulkan dapat mendukung kernel OpenCL C, sementara pekerjaan menambahkan dukungan untuk C++ sedang berlangsung. Bahasa, kerangka kerja, dan alat khusus domain masa depan adalah opsi lain. Khronos bahkan menyebutkan kemungkinan mengembangkan bahasa eksperimental baru.

Apa pun yang dipilih pengembang untuk dilakukan, semua jalan mengarah ke Vulkan, melalui SPIR-V, dan kemudian ke banyak perangkat yang berbeda.

SPIR-V seharusnya meningkatkan portabilitas dalam tiga cara:

• Alat bersama
• Satu set alat untuk satu ISV
• Kesederhanaan

Karena tidak ada kebutuhan untuk setiap platform perangkat keras untuk menampilkan penerjemah bahasa tingkat tinggi, pengembang akan menangani lebih sedikit dari mereka.

ISV individu dapat menghasilkan SPIR-V menggunakan satu set alat, sehingga menghilangkan masalah portabilitas bahasa tingkat tinggi.

SPIR-V lebih sederhana daripada bahasa tingkat tinggi biasa, membuat implementasi dan pemrosesan lebih mudah.

Performa akan ditingkatkan dalam beberapa cara, tergantung pada bagaimana Vulkan diterapkan:

• Tidak ada lagi kompiler front-end, banyak pemrosesan dapat dilakukan secara offline
• Pass pengoptimalan dapat diselesaikan lebih cepat, pengoptimalan dijalankan secara offline
• Beberapa shader sumber direduksi menjadi aliran instruksi bahasa perantara yang sama

Khronos tidak merinci angka kinerja apa pun dan mencatat bahwa "jarak tempuh pasti akan bervariasi." Itu semua akan tergantung pada bagaimana Vulkan digunakan. Jika Anda ingin memeriksa detail yang sulit, pastikan untuk memeriksa kertas putih SPIR-V.

Vulkan Tampak Menjanjikan Dari Perspektif Pengembang

Saya telah menguraikan sejumlah fitur yang seharusnya membuat Vulkan dan SPIR-V populer di komunitas pengembang, dan Khronos juga ingin menyampaikan hal ini. Prospek menggunakan alat dan keterampilan yang sama untuk dikembangkan untuk berbagai platform tampak menarik, terutama sekarang karena kesenjangan kinerja antara berbagai platform semakin dekat.

Tentu saja, mengembangkan game AAA beranggaran besar untuk PC akan tetap menjadi proses yang sangat kompleks dan memakan waktu, melibatkan banyak uang dan sumber daya manusia, tetapi platform seluler dan GPU terintegrasi yang digunakan dalam prosesor Intel dan AMD terbaru telah memberikan banyak manfaat. Performa GPU untuk gamer kasual. Selain itu, pengembang kecil independen, atau pekerja lepas, lebih cenderung bekerja pada game kasual lintas platform daripada judul AAA yang dibuat oleh penerbit besar.

Khronos menguraikan keuntungan-keuntungan berikut yang dimungkinkan oleh SPIR-V:

• Pengembang dapat menggunakan kompiler front-end yang sama di berbagai platform untuk menghilangkan masalah portabilitas lintas-vendor
• Waktu kompilasi shader/kernel runtime akan berkurang karena driver hanya perlu memproses SPIR-V
• Pengembang tidak harus mendistribusikan kode sumber shader/kernel, sehingga mereka menikmati tingkat perlindungan IP tambahan
• Driver lebih sederhana dan lebih andal karena tidak perlu menyertakan kompiler front-end
• Pengembang memiliki gambaran alokasi memori yang lebih baik dan dapat menyesuaikan pendekatan alokasi memori mereka

Saya yakin Anda akan setuju bahwa ini terdengar bagus, tetapi perjalanan masih panjang.

Vulkan: Berhasil, Tapi Sedang Berproses

Seperti yang saya katakan, Vulkan masih dalam proses, dan kami akan memiliki spesifikasi lengkapnya pada akhir tahun. Namun, dari apa yang telah kita lihat sejauh ini, API baru dapat membuka banyak kinerja bahkan dengan perangkat keras generasi saat ini.

Ilustrasi terbaik Vulkan yang pernah saya lihat sejauh ini berasal dari Imagination Technologies, salah satu perangkat GPU seluler terkemuka di luar sana. Teknologi Imajinasi IP GPU digunakan di semua gadget iOS, bersama dengan banyak desain System-on-Chip berbasis ARM lainnya, dan bahkan di beberapa chip Intel x86 bertegangan rendah.

Minggu lalu Imajinasi menerbitkan posting blog yang merinci peningkatan kinerja yang dimungkinkan oleh Vulkan. Pilihan perangkat kerasnya agak tidak biasa: Google Nexus Player, berdasarkan prosesor quad-core Intel yang jarang digunakan dengan GPU PowerVR G6430. Perangkat diuji dengan driver Vulkan API terbaru untuk GPU PowerVR, sementara referensi dijalankan pada OpenGL ES 3.0. Kesenjangan kinerja sangat mengejutkan.

Adegan mencakup total 400.000 objek, dengan tingkat detail yang berbeda, mulai dari 13.000 hingga 300 simpul. Tembakan lebar menunjukkan sekitar satu juta segitiga, beberapa alfa pada tanaman dan sekitar sepuluh tekstur berbeda untuk gnome dan tanaman. Setiap jenis objek menggunakan shader yang berbeda dan gnome tidak di-instance, setiap draw call bisa menjadi objek yang sama sekali berbeda, dengan bahan yang berbeda, tetapi hasil akhirnya akan serupa.

Namun, ada peringatan besar: Ini bukan jenis peningkatan kinerja yang dapat Anda harapkan dalam kehidupan nyata. Tim Imagination Technologies menggunakan skenario yang dilebih-lebihkan untuk menyoroti keunggulan Vulkan, mendorongnya hingga batasnya, dan dalam skenario khusus ini batasnya mendukung Vulkan vs. OpenGL ES. Juga, perlu diingat bahwa tes ini terikat GPU , tetapi ini masih merupakan ilustrasi yang baik tentang pemanfaatan CPU superior Vulkan.

Bagaimana Vulkan Mengurangi Utilisasi CPU?

Ingat tabel OpenGL vs. Vulkan yang kita miliki sebelumnya, atau lebih spesifiknya, bit rendering ubin ? Mungkin tidak, jadi ini dia, singkatnya: Imajinasi menggunakan Vulkan untuk mengelompokkan panggilan ke ubin dan membuat ubin sekaligus. Tergantung di mana ubin berada pada saat bingkai dirender, ubin bisa masuk atau keluar dari tampilan, mengubah tingkat detailnya, dan seterusnya. Di OpenGL ES, semua panggilan undian bersifat dinamis, dikirimkan dengan setiap bingkai, sesuai dengan apa yang ada di bidang pandang. Panggilan draw yang telah dieksekusi tidak dapat di-cache.

Akibatnya, OpenGL ES membutuhkan banyak panggilan ke mode kernel untuk mengubah status driver dan memvalidasinya. Vulkan tidak melakukannya karena bergantung pada perintah yang dibuat sebelumnya (buffer perintah) untuk mengurangi overhead CPU dan menghilangkan kebutuhan untuk memvalidasi atau mengkompilasi selama loop render. Tim Imajinasi menggambarkan kemampuan untuk menggunakan kembali buffer perintah sebagai "berguna dalam beberapa keadaan," dan mungkin untuk menggunakan "sebagian besar" di banyak game dan aplikasi.

Pengubah permainan kedua adalah generasi buffer paralel , yang memungkinkan Vulkan memanfaatkan kekuatan semua inti CPU. OpenGL ES dirancang sebelum munculnya chip seluler multi-inti, tetapi selama tiga tahun terakhir, industri telah berkembang dari dua, hingga empat, menjadi delapan dan sepuluh inti CPU, dengan SoC seri-A Apple dan Nvidia Tegra yang berbasis di Denver. chip sebagai satu-satunya pengecualian. Saya berbicara tentang tren SoC seluler di salah satu bagian blog saya sebelumnya, yang mencakup kompiler Optimizing Android yang akan datang, sehingga Anda dapat memeriksanya untuk info tambahan.

Mari kita coba analogi: Jika Vulkan adalah mesin pembakaran internal, itu akan menyimpan dan menggunakan kembali sebagian dari kekuatannya, dengan cara yang sama seperti turbocharger dan intercooler (buffer perintah), dan akan dapat menggunakan empat, enam, delapan atau bahkan sepuluh silinder tanpa kehilangan efisiensi (pembuatan buffer paralel). Membandingkan Vulkan dengan OpenGL ES terdengar seperti membandingkan mesin turbo baru yang dirampingkan dengan mesin tua, satu silinder di Trofi Kemenangan kakek Anda.

Yah, setidaknya kakek adalah rocker yang tepat, bukan mod.

Hasil akhirnya adalah lingkungan yang jauh lebih efisien, mampu menempatkan semua perangkat keras yang tersedia untuk digunakan dengan baik, tidak seperti OpenGL ES, yang terikat CPU di sebagian besar skenario. Ini berarti Vulkan dapat memberikan tingkat kinerja yang sama sambil menjaga CPU pada jam yang lebih rendah, sehingga mengurangi konsumsi daya dan pelambatan.

Potensi Kerugian Vulkan API (Peringatan Spoiler: Tidak Banyak)

Saya tidak rewel; Saya merasa penting juga untuk membuat daftar pro dan kontra dari Vulkan API . Untungnya, tidak banyak kontra selain beberapa yang kecil dan, berpotensi, satu atau dua yang besar. Jika menurut Anda Vulkan adalah yang terbaik sejak irisan roti, dan Anda ingin mencobanya di proyek berikutnya, Anda mungkin ingin mempertimbangkan beberapa poin berikut:

• Menambahkan kompleksitas kode dalam skenario tertentu
• Waktu-ke-Pasar
• Tingkat dukungan industri
• Vulkan mungkin tidak relevan atau efektif di beberapa platform (desktop)
• Meyakinkan pengembang untuk menggunakan Vulkan di beberapa platform
• Kompatibilitas terbatas dengan perangkat keras lama

Jika pengembang ingin menerapkan beberapa fitur rapi yang diuraikan dalam posting ini, itu akan melibatkan cukup banyak pekerjaan. Masing-masing harus diimplementasikan dalam kode, tetapi kabar baiknya adalah bahwa para pemimpin industri akan membuat prosesnya lebih mudah dengan pembaruan driver baru.

Time-to-market adalah masalah lain, seperti implementasi Vulkan di aplikasi dan game yang lebih lama. Vulkan masih merupakan pratinjau teknis; spesifikasi awal dan implementasi diharapkan pada akhir 2015, jadi, secara realistis, kita mungkin tidak akan melihat banyak aplikasi dunia nyata sebelum pertengahan 2016.

Dukungan industri seharusnya tidak menjadi masalah; Bagaimanapun, ini adalah standar Khronos, tetapi mungkin perlu beberapa saat. Itulah salah satu alasan saya memfokuskan postingan ini pada segmen seluler; Perangkat lunak dan perangkat keras seluler berkembang lebih cepat, dan mungkin perlu beberapa kuartal lagi sebelum kami melihat Vulkan berdampak pada platform desktop. Begitulah cara kerja industri ini, ada lebih banyak hal yang perlu dikhawatirkan di ceruk desktop: dukungan untuk aplikasi profesional, gerombolan gamer yang menggunakan garpu rumput mengejar setiap bingkai yang sobek, dan seterusnya. Namun, fakta bahwa Vulkan berasal dari Mantle AMD sangat menggembirakan.

Meskipun Vulkan dapat melakukan keajaiban dalam pengaturan yang terikat CPU, terutama dengan SoC seluler multi-core, peningkatan kinerja ini akan terbatas pada platform desktop. Desktop menangani prosesor multi-inti dengan tingkat efisiensi yang lebih tinggi, dan sebagian besar aplikasi yang menuntut grafis terikat dengan GPU.

Sampai semua bagian teka-teki jatuh pada tempatnya, beberapa pengembang mungkin enggan untuk mengambil risiko dan bermain-main dengan Vulkan. Banyak orang tidak punya waktu untuk bereksperimen, dan mereka mempelajari keterampilan baru hanya jika benar-benar diperlukan. Membakar banyak uang dan membuang-buang waktu untuk mengubah game seluler yang ada untuk menggunakan Vulkan pada tahap awal ini tidak akan menjadi pilihan bagi banyak pengembang dan penerbit.

Kompatibilitas dengan perangkat keras yang lebih tua bisa menjadi sumber perhatian lain. Vulkan akan membutuhkan perangkat keras OpenGL ES 3.1 atau OpenGL 4.1, disertai dengan driver baru. Misalnya, GPU PowerVR seri 6 dari Imagination Technologies dapat mendukungnya, tetapi seri 5 tidak. Seri Qualcomm Adreno 400 mendukung OpenGL ES 3.1, tetapi seri 300 tidak. Mali T600- dan T700-series ARM mendukung OpenGL ES 3.1, tetapi dukungannya kurang pada desain-desain T400-series yang lebih lama. Untungnya, pada saat Vulkan menjadi relevan, sebagian besar perangkat dengan GPU yang tidak didukung akan keluar dari gambar. Ini termasuk iPhone 5/5C, iPad generasi keempat, dan perangkat Samsung berdasarkan chip Exynos seri 5000 tertentu. Perangkat berbasis Qualcomm mungkin tidak seberuntung itu karena GPU Adreno 300-series digunakan pada desain yang relatif baru dan produktif seperti Snapdragon 410, Snapdragon 600, Snapdragon 800 dan 801. Namun, saya menduga sebagian besar dari mereka akan hilang pada waktunya. Vulkan menjadi benar-benar relevan.

Hidup Panjang Dan Render

Masih terlalu dini untuk mengatakan apakah Vulkan akan menjadi pengubah permainan atau tidak, tetapi saya pikir Anda akan setuju bahwa itu memiliki banyak potensi. Saya pikir ini akan menjadi masalah besar, dan saya mendasarkan asumsi itu pada pengalaman satu dekade yang mencakup industri GPU. Namun, ini akan memakan waktu, dan saya menduga Vulkan akan membuat kehadirannya terasa di ponsel sebelum mulai mengubah lanskap desktop.

Pada saat yang hampir bersamaan, driver, mesin game, dan game yang dioptimalkan Vulkan, kita akan mendapatkan perangkat keras baru untuk dimainkan, dan maksud saya bukan hanya tweak perangkat keras kecil. Pengembangan SoC Seluler terhenti karena sejumlah alasan yang tidak akan saya bahas sekarang, tetapi 2016 akan menjadi tahun yang besar bagi industri ini, karena node FinFET 14/16nm tersedia untuk lebih banyak produsen, dan menjadi layak secara ekonomi untuk perangkat keras arus utama daripada chip unggulan.

Pengembang akan memiliki perangkat keras yang jauh lebih kuat dan efisien untuk dimainkan, dan API grafis low-overhead baru akan menjadi pelengkap. Saya sangat berharap vendor perangkat keras akan berhenti menggunakan resolusi tampilan sebagai gimmick pemasaran, karena resolusi tinggi yang sia-sia tidak melakukan apa pun untuk kualitas visual tetapi masih membuang daya. Sayangnya, karena rata-rata konsumen tidak mendapatkan ini, dan ingin melihat angka yang lebih besar di kotak, saya menduga ini tidak akan terjadi dalam waktu dekat. Saya bermaksud untuk memeriksa masalah aneh ini di salah satu posting saya yang akan datang, jadi jika Anda terganggu olehnya, tetap disini dan jangan ragu untuk melampiaskannya di bagian komentar.