- WDDM memindahkan manajemen GPU ke Dxgkrnl dan miniport, menjauh dari Win32k.
- ReactOS sekarang mulai driver Tampilan WDDM dan negosiasi mode melalui VidPn dan CDD.
- Tumpukan XDDM yang solid tetap menjadi keharusan untuk bergerak maju dalam WDDM dan DWM.
- ReactOS 0.4.15 meningkatkan driver, LiveUSB, kinerja dan bergerak menuju amd64.
ReactOS telah dikembangkan begitu lama sehingga banyak kontributor saat ini bahkan belum lahir ketika dimulai, tetapi tujuannya tetap tidak berubah: memberikan pengalaman ABI yang kompatibel dengan Windows mampu menjalankan perangkat lunak dan driver yang dirancang untuk sistem Microsoft. Dalam beberapa tahun terakhir, salah satu bidang paling ambisius dari proyek ini adalah mengejar dukungan untuk perangkat keras.
Proses tersebut telah menghasilkan tujuan utama: semakin mendekati arsitektur driver grafis Windows modern. Kita berbicara tentang WDDM, model yang menggantikan XDDM sejak era Vista. Dalam ekosistem ReactOS, Menjelajahi WDDM berarti memahami bagaimana manajemen GPU telah berubah, bagian mana dari sistem yang direstrukturisasi dan mengapa tidak cukup hanya dengan “mengaktifkan” driver untuk membuat semuanya berfungsi seperti di Windows.
Apa itu WDDM dan mengapa itu membuat perbedaan
WDDM, Model Driver Tampilan Windows, memperkenalkan perombakan besar-besaran pada tumpukan grafis: memindahkan kontrol GPU dari komponen seperti Win32k ke inti khusus (Dxgkrnl.sys) yang berkomunikasi dengan miniport pabrikan. Setiap revisi (1.0, 1.1, 1.2, dan yang lebih baru) mendefinisikan antarmuka apa saja yang ditawarkan sistem dan bagaimana implementasinya, sebuah konsep yang berbeda dari level fitur Direct3D yang terdapat di DxDiag.
Arsitektur yang lebih modular dan menuntut ini melampaui apa yang ditawarkan XDDM. Dalam WDDM, Dxgkrnl bertindak sebagai pengatur, dan driver vendor memfasilitasi titik masuk dan kontrak yang jelas. Pemisahan ini memungkinkan peningkatan seperti memori video tervirtualisasi, penjadwal GPU, dan, secara umum, stabilitas yang lebih baik dengan memindahkan sebagian logika ke mode pengguna.
Selama bertahun-tahun, dokumentasi praktis untuk pengembangan driver video mendalam masih langka untuk kedua arsitektur tersebut, yang menghambat kemajuan. Dengan semakin matangnya driver GPU terbuka, komunitas telah mendapatkan referensi nyata untuk memahami bagaimana OpenGL ICD berperilaku, dukungan Vulkan, dan transisi model.
Apa yang terjadi dengan XDDM? Kompatibilitas, sisa-sisa, dan titik kritisnya
Sejak Windows 8, sistem memerlukan driver GPU menjadi WDDM; namun, XDDM tidak hilang sepenuhnyaWindows Vista dan 7 memungkinkan driver XDDM dimuat tanpa masalah, dan masih terdapat mekanisme lama yang kompatibel dengan WDDM. Modul yang memuat OpenGL ICD, misalnya, hampir tidak berubah antar versi.
Komunikasi di WDDM ke miniport lebih langsung. Win32k mempertahankan lompatan syscall yang Dxgkrnl diisi dengan antarmuka yang sesuai, mengurangi keterlibatan subsistem lama dalam logika GPU. Faktanya, ketika sistem di-boot, rutinitas tertentu diamati menghubungkan WDDM ke dunia Win32k lama tanpa arsitektur antarmuka.
Ada dua driver tampilan yang perlu Anda ketahui secara detail: TSDDD.dll dan CDD.dll. Yang pertama, TSDDD, Dimuat secara manual di sesi 0 dan ini adalah driver XDDM yang sangat mendasar yang hampir tidak menulis ke memori kosong. Dalam keluarga NT5.x (sebagai basis untuk ReactOS), inisialisasi video yang gagal sering kali mengakibatkan pemeriksaan bug untuk kegagalan video; di Vista dan yang lebih baru, situasi "nyata" ini tidak lagi terjadi berkat komponen kedua.
CDD.dll adalah yang menarik. Meskipun berfungsi sebagai driver XDDM, ia mengeluarkan IOCTL untuk berkomunikasi dengan WDDM. Itulah satu-satunya cara Dxgkrnl dan Win32k berkomunikasi secara bermakna selama operasi grafis modern. Selama inisialisasi, Win32k meminta adaptor, tetapi responsnya ditimpa oleh cdd.dll, memastikan jembatan ke WDDM. Poin penting: setelah WDDM diaktifkan, driver XDDM tidak dapat dijalankan secara paralel.
OpenGL ICD, Vulkan dan hubungannya dengan sistem
ICD OpenGL dimuat menggunakan modul tradisional, dan alirannya tidak terlalu bervariasi antara Vista, 7, 8, dan yang lebih baru, yang memfasilitasi pengujian silang menggunakan ICD dari berbagai generasi. Vulkan berperilaku serupa: sistem mendelegasikan interaksi dengan GPU ke lapisan-lapisan ini, tetapi dalam WDDM, miniport dan Dxgkrnl menetapkan "kontrak" perangkat keras yang sebenarnya.
Struktur hibrida ini menjelaskan mengapa kita masih melihat sisa-sisa XDDM yang hidup berdampingan dengan WDDM dalam komponen sistem. Jembatan CDD.dll memungkinkan Win32k untuk terus menjalankan peran klasiknya tanpa menghalangi jalur modern, sementara Dxgkrnl dan miniport mengambil alih tugas penting dalam mengelola GPU.
Mengkompilasi driver WDDM untuk pengujian pada ReactOS
Untuk memulai driver WDDM Anda memerlukan bagian tambahan: displib.lib dari WDK, yang mengekspos titik masuk untuk menginisialisasi driver dan “membangunkan” Dxgkrnl tanpa mengikatnya. Alurnya khusus: API inisialisasi dipanggil, struktur data diteruskan ke Dxgkrnl, dan kemudian Dxgkrnl mengembalikan kontrol dengan memanggil panggilan balik boot dari miniport penyedia.
Panggilan balik tersebut menyediakan antarmuka untuk sisa komunikasi dengan Dxgkrnl. Pada titik ini, Win32k tidak terlihat apa-apa di awal miniport, yang merupakan perbedaan mendasar dari dunia XDDM. Adaptasi ini mudah diimplementasikan di ReactOS, membuka peluang untuk mengimpor dan mengompilasi driver WDDM yang juga tetap berfungsi di Windows.
WDDM di ReactOS: Fokus pada layar terlebih dahulu
API D3DKMT digunakan untuk akselerasi DirectX dan OpenGL, jadi untuk percobaan pertama di ReactOS kami memilih Fokus pada dasar-dasar: mendapatkan keluaran videoDi sinilah dunia VidPn (Jaringan Presentasi Video) dan dukungan perangkat keras terkait dalam Dxgkrnl berperan.
Sejak Windows 8 ada yang disebut KMDOD, varian miniport WDDM yang mereka membuang akselerasi 3DMereka lebih mudah dipahami dan digunakan: mereka memungkinkan Anda mengelola mode video, monitor, dan lintasan tanpa bergantung pada perencana dan subsistem Dxgkrnl rumit lainnya.
Untuk ReactOS, percobaannya adalah membangun Dxgkrnl minimal yang akan menanyakan mode yang tersedia melalui VidPn, menyerahkannya ke CDD, dan mengaktifkan CDD saat Dxgkrnl siap. Hasilnya: sistem mulai berbicara dengan driver WDDM pertamanya sekarang menampilkan gambar dalam kondisi nyata.
Keberhasilan pertama: BasicDisplay.sys dan driver vendor
Saat memuat BasicDisplay.sys ke dalam ReactOS, kesimpulannya ternyata positif: WDDM ternyata lebih toleran dari yang diharapkan.Bahkan memungkinkan untuk meluncurkan driver vendor hanya untuk bagian tampilan, tanpa mengharuskan mereka mendukung akselerasi 3D.
Dalam pengujian selanjutnya, keluaran video muncul dengan lebih banyak driver, termasuk driver untuk Nvidia dari era Windows 7, yang memungkinkan ReactOS Pindahkan monitor modern ke resolusi dan frekuensi aslinyaKendalanya bukan pada Win32k, tetapi pada dukungan perangkat keras yang sebenarnya, yang masih terus diperluas.
Mengapa XDDM masih penting dalam perjalanan menuju WDDM
Meskipun tujuan utamanya adalah WDDM, ReactOS mengharuskan tumpukan XDDM-nya berada dalam kondisi yang sangat baik. Alasannya adalah komponen seperti CDD.dll dan DWM itu sendiri Mereka bergantung pada kinerja dunia lama yang baik untuk menjembatani kesenjangan antara yang lama dan yang baru. Faktanya, DWM menghadirkan tuntutan yang belum sepenuhnya dapat dipenuhi oleh implementasi Win32k saat ini di ReactOS, meskipun ada kemajuan yang berkelanjutan.
Dukungan untuk GPU AMD di bawah XDDM juga telah dipercepat, sebuah langkah penting untuk menstabilkan bidang sebelum membuka jalan menuju driver WDDM yang lebih kompleksJalur yang dipilih bersifat bertahap: pertama layar dan mode, lalu lebih banyak potongan puzzle.
Perbedaan utama antara XDDM dan WDDM
Salah satu perubahan paling menonjol dalam perpindahan dari XDDM ke WDDM adalah penanganan kesalahan. Dengan WDDM, sebagian besar logika driver dipindahkan ke mode pengguna, yang berarti Kecelakaan pengemudi tidak harus melumpuhkan sistem. Lengkap. Selain itu, penjadwal GPU dan memori virtual memungkinkan alokasi sumber daya yang lebih detail.
Dalam XDDM, Win32k memiliki bobot yang jauh lebih besar dan komunikasi dengan perangkat keras lebih kaku. Dalam WDDM, Dxgkrnl memaksakan kontrak yang jelas pada pelabuhan mini, dan Win32k tetap menjadi jembatan ke subsistem windowing. Hal ini memungkinkan kapabilitas baru seperti DWM, pengomposisian, dan presentasi yang lebih andal.
- Perencanaan dan isolasi kerja GPU versus pendekatan monolitik XDDM.
- Memori video virtual dan pengelolaan sumber daya bersama yang lebih baik.
- Peningkatan stabilitas saat memigrasikan logika driver ke mode pengguna.
- Integrasi dengan DWM dan rute presentasi modern.
Keterbatasan saat ini dan pekerjaan yang sedang berlangsung
Meskipun dukungan driver tampilan WDDM dalam ReactOS sudah menjadi kenyataan dalam pengujian, kompatibilitas perangkat keras terus menentukan kecepatannya. Perangkat nyata memerlukan dukungan yang sangat spesifik, dan setiap lompatan memerlukan perluasan subsistem: dari plug and play hingga manajemen memori dan pengawas.
Saat startup, komunikasi juga diamati antara pengawas, Win32k dan Dxgkrnl untuk mempersiapkan pengiriman API D3DKMT dalam Dxgkrnl; ini adalah langkah inisialisasi khusus, tetapi menambahkan persyaratan tambahan dalam hal mereproduksi perilaku Windows dengan tepat.
Status proyek, komunitas, dan ajakan kolaborasi
Dorongan baru-baru ini menuju WDDM telah disertai dengan peningkatan aktivitas di seputar perangkat keras. Ada artikel teknis yang merinci proses dan Sumbangan dapat diberikan melalui donasi, GitHub, atau penjangkauan.Ini adalah front yang besar dan jarak jauh: setiap miniport dan setiap rute presentasi menambah nuansa.
Perlu diingat, secara sepintas, sifat proyek: ReactOS tidak Linux ni Unix. Untuk sebuah analisis perbandingan, ditulis dari awal agar kompatibel secara biner dengan Windows, yang memungkinkannya menjalankan perangkat lunak dan driver Windows secara asli tanpa menggunakan lapisan kompatibilitas seperti Wine/Proton, meskipun proyek tersebut juga berkolaborasi dengan ekosistem FOSS tersebut untuk meningkatkan hasil.
Berita praktis: ReactOS 0.4.15 dan peningkatan sistem
Selain WDDM, versi 0.4.15 telah membawa sejumlah perubahan yang bagus: pengemudi baru penyimpanan yang meningkatkan stabilitas dan kompatibilitas dengan unit USB, serta driver jaringan yang diperbarui. Font, shell desktop, API Windows, tema, dan kotak dialog juga telah disempurnakan.
Peningkatan telah dilakukan pada cache dan manajemen memori yang memengaruhi kinerja. Selain itu, Menambahkan dukungan untuk LiveUSB Setelah modifikasi mendalam pada manajer Plug and Play kernel, yang membuka pintu bagi lebih banyak driver pihak ketiga, antarmuka grafis telah menerima sedikit penyesuaian agar lebih mudah digunakan dibandingkan dengan penginstal USETUP berbasis teks.
Di bagian audio, sekarang dimungkinkan untuk memulai dengan tumpukan suara Windows, meskipun masih ada bagian-bagian kasar yang perlu dihaluskanPerlu dicatat juga bahwa 0.4.15 adalah rilis pertama yang mendukung arsitektur 64-bit (amd64) hingga desktop, meskipun belum ada citra 64-bit resmi karena WOW64 masih dalam tahap pengembangan.
Perbaikan bug telah dilakukan secara intensif: ikon desktop yang salah ditetapkan Masalah yang telah diatasi meliputi peningkatan ikon bilah tugas dan dukungan berkas ZIP bawaan. Semua ini bertujuan untuk meningkatkan pengalaman pengguna dasar sekaligus meningkatkan kompatibilitas perangkat keras.
Unduh, instalasi, dan persyaratan minimum
Citra ReactOS 0.4.15 tersedia di SourceForge. Hal ini dimungkinkan uji pada mesin virtual (disarankan untuk pemula) atau instal pada perangkat keras nyata dengan drive USB yang dibuat dengan utilitas seperti Rufus, seperti yang Anda lakukan dengan Windows standar.
Persyaratannya sederhana: CPU x86 (Pentium atau lebih baru), RAM 64 MB, setidaknya 450 MB ruang disk pada partisi FAT16/FAT32 dan sekitar 2 GB tambahan Jika Anda berencana untuk menginstal perangkat lunak atau permainan, minimum ini memungkinkan komputer dari dekade terakhir atau bahkan lebih lama untuk menjalankan sistem dalam skenario pengujian.
Rekomendasi penggunaan dan harapan yang realistis
Saat ini, ReactOS masih dalam tahap percobaan. Tidak disarankan sebagai sistem operasi utama jika Anda membutuhkan fitur modern dan kompatibilitas penuh dengan aplikasi terbaru. Untuk menjalankan perangkat lunak yang lebih baru, Wine/Proton di Linux tetap menjadi pilihan yang sangat stabil dengan ekosistem dukungan yang luas.
Namun, keunikan ReactOS menjadikannya Satu-satunya sistem terbuka yang menjalankan biner Windows tanpa middleware apa pun Bergaya emulator. Pendekatan ini membuatnya menarik untuk laboratorium, kompatibilitas mundur, analisis, dan lingkungan terkontrol di mana perilaku aplikasi dan driver perlu dipelajari.
Konteks komunitas dan pesan umum
Di forum dan ruang sosial, sering terlihat pengingat seperti: ReactOS adalah sistem PC yang dapat menjalankan program dan driver WindowsTerkadang, penghitung anggota dan pengguna daring juga ditampilkan, indikator sederhana vitalitas komunitas yang, tanpa nilai teknis, menunjukkan meningkatnya minat terhadap proyek.
Narasi media baru-baru ini bahkan menunjukkan kebetulan temporal antara berakhirnya dukungan untuk beberapa versi Windows dan Kemajuan ReactOS menuju WDDMLebih dari sekadar ironi, ini merupakan tanda bahwa komunitas menyelaraskan prioritas untuk tetap relevan dengan perangkat keras dan driver terkini.
Pada akhirnya, semua upaya ini mengarah pada satu titik: membangun landasan yang kokoh Di sinilah WDDM dapat membangun dirinya sendiri tanpa meninggalkan warisan XDDM yang masih berfungsi sebagai perekat antar dunia. Dengan CDD.dll sebagai jembatan, Dxgkrnl sebagai otak, dan miniport yang lebih dipahami berkat driver terbuka, jalannya sudah diaspal, meskipun masih ada yang perlu ditempuh.
Melihat semua hal di atas, dukungan WDDM di ReactOS berubah dari janji yang samar menjadi serangkaian tonggak nyata: Menampilkan driver yang memulai, mode yang bernegosiasi dengan baik, dan monitor yang bekerja pada resolusi penuhKompatibilitas perangkat keras perlu ditingkatkan, bagian seperti WOW64 perlu dirampungkan, dan Win32k serta DWM perlu terus disempurnakan, tetapi arahnya sudah jelas dan komunitas sudah mendorong ke arah itu.
Penulis yang bersemangat tentang dunia byte dan teknologi secara umum. Saya suka berbagi ilmu melalui tulisan, dan itulah yang akan saya lakukan di blog ini, menunjukkan kepada Anda semua hal paling menarik tentang gadget, perangkat lunak, perangkat keras, tren teknologi, dan banyak lagi. Tujuan saya adalah membantu Anda menavigasi dunia digital dengan cara yang sederhana dan menghibur.