Berikut merupakan artikel yang membahas lebih jauh tentang DirectX11 (DX11).Selengkapnya semoga dapat menjawab beberapa pertanyaan yang muncul pada forum ini mengenai kompatibilitas DX 11 yang berbeda dengan DX sebelumnya (DX 11 backward kompatibel dengn DX 10) serta mengenai beda multi thread pada DX 10 dan DX11.
Mengenal DirectX 11 lebih jauh
Pembukaan
Kita senantiasa mengharapkan evolusi grafis 3d terus berlanjut hingga semakin mendekati kenyataan, baik pada sistem komputer high end maupun low end . Kemajuan dunia 3d didorong oleh berbagai faktor, diantaranya performa murni hardware dan kemajuan teknis yang brilian agar dapat menggambarkan apa yang kita lihat dengan lebih baik. Namun ada sisi lain dibalik hardware maupun peranan developer, yaitu API (Application Programming Interface) dari grafik itu sendiri. Berbeda dengan CPU, hardware grafis (GPU) tidak memiliki instruksi umum yang dapat dibangun guna menjembatani antara hardware itu sendiri dengan softwarenya. Demi mengerahkan potensi hardware kepada publik, diperlukan antar muka umum yang dapat bekerja tanpa memperdulikan GPU yang digunakan pada sebuah sistem komputer. Selanjutnya tergantung pada desainer hardware grafis untuk menangani kode yang dihasilkan oleh API dan menerjemahkannya menjadi sesuatu yang dapat didayagunakan oleh chip grafis mereka. Keberadaan API sangatlah penting karena menjadi satu- satunya titik hubung developer(software) dengan hardware tersebut. API tersebut menentukan seberapa besar keleluasaan yang diperoleh dalam mendayagunakan hardware dalam rangka membangun dunia grafis 3d performa tinggi secara realtime. Beberapa kunci pekerjaan yang dilakukan melalui API grafis adalah mengambil deskripsi dari objek 3D dalam dunia 3d, mengrimkan objek tersebut dan sumber daya lainnya menuju hardware, kemudian “mengatakan” kepada hardware tentang apa yang harus dilakukan terhadap objek tersebut. Terdapat sekumpulan Langkah demi langkah proses lanjutan yang umumnya sering kita sebut pipeline. Pipeline API grafis memiliki tingkatan- tingkatan dimana beberapa pekerjaan yang berbeda dilakukan. Berikut ini gambaran umum struktur sebuah pipeline grafis 3d : Pertama- tama data vertex (info mengenai posisi titik sudut sebuah segitiga) dibawa masuk dan diproses. Barulah kemudian bangun tersebut dapat dimanipulasi dan diproses ulang lebih jauh jika diperlukan. Setelah itu, objek 3d dipecah dari bangun 3d dengan memproyeksikannya ke dalam fragmen 2d yang disebut pixel(langkah ini dikenal dengan nama rasterisasi), kemudian pixel ini masing- masing diproses dengan mencari informasi tekstur serta mengunakan teknik pencahayaan dan seterusnya. Selesai diproses, pixel ditampilkan di layar. Dan demikian sekilas gambaran tentang cara kerja grafis 3d. Selama 12 tahun terakhir,kita telah menyaksikan pembuat hardware grafis 3d yang terus mendorong dua API yang dominan yaitu OPEN GL(OGL) dan DIRECT X(DX)Namun untuk saat ini kita akan terfokus pada Direct X, API grafis milik microsoft yang lebih sering dipergunakan dalam sebuah game engine dibandingkan openGL, sebagian besar dikarenakan DX bergerak jauh lebih cepat dan menciptakan serangkaian fitur serta
fleksibilitas yang menjadi standar baru baik pada hardware maupun software DX itu sendiri. Hal ini menjadikan tiap versi DX yang
hadir menarik untuk dibahas mengingat DX senantiasa menentukan kamampuan hardware di masa depan dan menyuguhkan tool
yang cukup teruji bagi para developer. Versi DX terbaru adalah cahaya bagi masa depan dunia grafis. Saat ini banyak tersedia dan
banyak dikembangkan game yang menggunakan DX 9 an 10, sementara DX 11 sendiri telah mengintip dari balik cakrawala.
Seperti biasa Microsoft akan menyesuaikan peluncuran DX 11 dengan peluncuran hardware yang mendukungnya. Seperti sebelumnya (DX 10 dengan cista), DX 11 akan dirilis bersama dengan windows 7 pada akhir tahun ini.
Kali ini Microsoft sedikit lebih agresif dengan jadwal peluncuran windows 7 untuk membayar penolakan terhadap vista, sehingga kelihatannya Microsoft tidak akan melakukan penundaan lagi. Terdapat jarak sedikitnya 4 tahun antara peluncuran DX 9 dengan DX 10. Bersamaan dengan keluarnya vista pada jan 2007, DX 10 hanya menjadi pilihan kedua dan dapat diduga penggantinya akan segera keluar. Transisi yang sangat cepat ini akan menguntungkan bagi pengadopsian DX 11 karena DX 10 sendiri masih belum terlalu merakyat, buktinya hingga kini banyak game yang masih menggunakan DX9 saja. Tetapi kita lihat terlebih dulu lebih dekat tentang bahasan kita kali ini sebelum melangkah lebih jauh.
MEMPERKENALKAN DX 11:
FITUR DAN PIPELINE.
Sedikit tentang DX 10.
Kita semua ingat betapa sangat memuakkannya vista. Diantara penyebab kurang didukungnya DX10 ada pada Vista itu sendiri, kurangnya dukungan driver, masalah waktu pemasaran dan rintangan lain yang membuat para developer menjauhi fitur- fitur baru nan keren yang dibawa DX10.
Temui DX11
Lebih keren dan lebih hot dari kakaknya. Banyak peningkatan yang tersembunyi berarti performa yang lebih tinggi bagi fitur yang ada namun tidak dipergunakan pada DX10. Perubahan besar pada pipeline menandai langkah revolusioner dalam bidang hardware grafis dan kemampuan software. Tesselation (yang terdiri atas hull shader, tesselator plus domain shader) dan Compute Shader me upakan perkembangan besar yang dapat lebih jauh membimbing para pengembang untuk menutup jarak antara dunia nyata dan maya. Fitur- fitur ini pada awalnya banyak mendapat tekanan, namun kunci dari pengadopsian (dan eksploitasi DX11) ada pada elemen-elemen yang lebih mendasar. Seiring dengan perubahan pipeline , kita bisa melihat banyak tweak dan peningkatan. DX 11 sebenarnya adalah “huruf besar” dari DX 10.1, artinya bahwa keseluruhan fitur DX 10.1 terangkum tanpa perubahan dalam DX 11. Dengan fakta sederhana ini maka hardware DX 11 akan mencakup seluruh perubahan yang diperlukan untuk menjadi DX 10.1 compliant (yang saat ini hanya dimiliki AMD dengan seri ATI radeon 3000 dan 4000). Sebagai tambahan atas peningkatan kecil ini, akan kita lihat lebih jauh perluasan berikut: Alih- alih perubahan pada pipeline mengijinkan developer untuk menulis banyak program guna menyelesaikan macam -macam task, perubahan yang lebih mendasar ini mengijinkan program- program tersebut menjadi lebih kompleks, berkualitas tinggi, dan mungkin berperforma lebih tinggi. Dibalik semua ini, Microsoft juga telah membantu pemrograman parallel sedikit lebih mudah bagi game developer.
Dari Evolusi Menuju Ekspansi dan Multi Threading
Update DX SDK bulan November adalah yang pertama mencakup beberapa fitur DX 11 untuk diujicoba oleh para developer. Memang hardware DX 11 masih belum tersedia , namun fitur tersebut akan berjalan pada setelan dan hardware DX 10 yang ada saat ini pada Win Vista dan Win 7 beta(ketika windows7 belum diluncurkan). Apabila digabungkan dengan fakta telah diselesaikannya spesifikasi Open CL oleh Khronos sebulan lalu, hal ini telah menandai dua perkembangan besar dalam membuka jalan menuju general purpose computing pada GPU. Harus diakui bahwa Open CL dan DX11 adalah batu loncatan bagi sejarah komputasi di masa depan, meski tentu saja DX 11 jauh lebih unggul dalam aplikasi 3d realtime, sedangkan open CL sendiri ditujukan untuk pemrograman data paralel secara umum (pada banyak CPU dan GPU) selain daripada grafis itu sendiri.
Masih banyak hal lain pada DX 11 selain dari compute shader itu sendiri. Hal lain yang paling menarik adalah pengenalan DX 11 akan membawa keuntungan bagi pemilik hardware DX 10 dan DX 10.1 saat ini, asalkan AMD dan NVIDIA senantiasa memberikan dukungan driver yang tepat. Banyak aspek baru pada DX 11 yang kelihatannya mengindikasikan adanya kesiapan untuk lebih cepat diadaptasi, khususnya apabila Win 7 yang sudah diluncurkan. Terdapat peningkatan pada HLSL(High Level Shader Language) yang akan jadi lebih menarik bagi developer, fakta bahwa DX 10.1 adalah huruf kecil bagi DX 11memiliki dampak transisi yang baik, dan perubahan- perubahan yang membuat pemrograman paralel lebih mudah akan sangat membantu para developer beradaptasi dengan API tersebut lebih cepat. Tidak akan ada lagi keluhan tentang sedikitnya user yang mengupgrade OSnya karena DX 11 akan tersedia pula untuk Vista, dan Win 7 akan menginspirasi gamer Win XP untuk mengupgrade OS-nya, yang artinya akan memperluas pasar para developer kelak.
Pada dasarnya DX 11 lah yang sebenarnya akan membawa fitur – fitur pada dx10 sembari membantu developer melakukan trransisi API lebih cepat dari sebelumnya, sedangkan DX 10 sendiri menjanjikan fitur- fitur yang akan membawa revolusi pada keindahan visual dan teknik rendering. Kita mungkin tidak akan melihat teknik yang sepenuhnya memanfaatkan fitur eksklusif pada DX 11 dalam waktu dekat ini, namun penyesuaian dengan API baru itu sendiri akan berjalan beriringan untuk mengilhami kemajuan pesat dalam grafis 3d realtime.
Dari DX 6 ke DX 9,Microsoft secara berkesinambungan mengubah API pemrograman mereka dari “kendaraan” berfungsi tetap untuk setelan keadaan dan pergerakan struktur data di sekitarnya menuju ke lingkungan yang lebih programmable yang mengijinkan pengendalian hardware grafis sepenuhnya . Langkah dari DX 9 menuju DX 10 merupakan kejutan akhir dari cara lama tersebut, membuka dan memperluas kemampuan pemrograman Dx 9 untuk menambahkan kedalaman dan fleksibilitas yang disediakan oleh hardware baru. Dengan transisi ke DX 10 Microsoft juga mema sakan sebuah pergeseran dalam model driver untuk meninggalkan sisasisa kejayaan dan mencoba meningkatkan stabilitas dan fleksibilitas pada saat menggunakan hardware DX 10. Tetapi berbeda dengan DX 11, Microsoft telah membangun DX 11 sebagai “huruf besar” dari DX 10/10.1 yang telah menyediakan beberapa kemungkinan yang bisa membuat penasaran daripada hanya sekedar merekonstruksi ulang DX 9 agar lebih mudah diprogram.
Di sisi lain, DX11 akan mampu berjalan pada level lebih rendah. Meskipun tentu saja keseluruhan fitur- fitur DX 11 tidak akan bisa diterapkan, namun ini berarti developer bisa tetap menyasar hardware DX 10 dan 11 tanpa memerlukan implementasi pemrograman yang terpisah karena memang keduanya sama tetapi DX11 lebih menyasar pada fungsioalitas. Kode yang berbeda memang diperlukan jika fitur yang digunakan hanya untuk DX 11 (seperti tesselator atau compute shader). Keunggulan untuk berjalan pada hardware dengan spesifikasi rendah akan menjadi sangat penting dalam menentukan seberapa cepat proses transisi dari DX 10 ke DX11 berlangsung. Berdasarkan kenyataan lambatnya pergerakan untuk meninggalkan DX 9 (baik pada developer maupun konsumen sendiri), keluarnya Win 7, dan lambatnya peralihan ke Win Vista, dapat kita simpulkan bahwa DX 10 tak lebih hanyalah sebuah API peralihan daripada sebuah pergeseran paradigma seperti yang digadang-
gadang Microsoft. Tentu saja Microsoft akan terus mendorong para developer untuk berpindah ke DX 11 dengan meyakinkan bahwa jalur cepat untuk menuju hal tersebut hanyalah dengan mulai menerapkan kode DX 10.1 sekarang juga. Karena DX 11 adalah “huruf besar” dari DX 10 hal ini bisa saja benar , namun usaha para developer akan lebih baik jika dipakai untuk menghabiskan sebagian besar waktunya pada jalur DX 9 berkualitas tinggi dengan sedikit pemakaian dx 10 sementara menyimpan pergeseran teknis utamanya yang hanya dimungkinkan dengan game- game Dx 10 untuk game yang menyasar rentang waktu dan hardware DX 11. Kita semua berharap pegeseran ke dx 11 secepatnya karena keunggulan- keungulan yang dibawa bahkan untuk hardware DX 10 itu sendiri. Keunggulan itu antara lain adalah multi threading. DX 11 menambahkan dukungan multi threading yang mengijinkan aplikasi untuk menciptakan resource atau menangani keadaan dan mengeluarkan perintah secara bersamaan hanya dengan beberapa threads saja. Hal ini tentunya tidak akan mempercepat subsystem grafis secara signifikan (terutama jika sistem sudah dibatasi oleh GPU), namun hal ini akan meningkatkan kemampuan thread yang luar biasa besar dari sebuah game dengan lebih mudah dan mengambil keuntungan dari semakin meningkatnya jumlah core CPU pada komputer desktop. Sistem dengan 8 atau 16 logika prosesor akan segera datang, kita membutuhkan developer yang mampu mendorong banyak thread yang saat ini mampu didayagunakan dengan baik pada sistem dengan 2 core. Saat ini keuntungan mengembangkan game secara signifikan yang dibantu dengan ketersediaan lebih dari 2 core sangatlah lemah. Sangatlah sulit untuk menyediakan cukup paralelisme pada sistem dengan 4 core atau lebih pada kebanyakan game. Namun menciptakan resource dengan kreasi paralel sederhana dan menampilkan daftarnya menggunakan banyak thread dapat membuka kesempatan untuk memparalelkan kode game yang hingga sekarang masih single thread. Daripada membuat sebuah thread untuk menangani seluruh perubahan keadaan DX dan melakukan draw call (dengan kata lain banyak thread yang tersinkronisasi dan bekerja dengan baik yang saling berbagi tanggung jawab) ,developer dapat menciptakan thread untuk menangani tipe atau grup dari suatu objek atau bagian sebuah world dengan lebih alami yang mampu membuka jalan ke masa depan dimana setiap objek atau entitas dapat ditangani oleh threadnya masing- masing (yang sangat diperlukan untuk memberikan keuntungan performa pada saat kita telah sampai pada masa ratusan logika core )
Kenyataan bahwa Microsoft telah merrencanakan dukungan multi-thread untuk Dx11 yang berjalan pada hardware Dx 10 adalah sebuah bonus besar. Salah satu halangan adalah AMD dan NVIDIA perlu untuk sedikit mengutak atik driver mereka untuk sistem DX 10 saat ini agar dapat bekerja sepenuhnya (yang sebenarnya akan bekerja namun tidak sebaik tanpa perubahan driver). Tentu saja kita berharap NVIDIA dan AMD (dengan perusahaan CPUnya) akan tertarik mewujudkan hal ini. Dan sekali lagi hal ini adalah insentif utama para game developer untuk menyasar DX 11 bahkan sebelum hardwarenya sendiri banyak tersedia. Jika saja Microsoft akan (dan mampu) mem-back port Dx 11 ke Win XP, tetap saja tidak ada alasan bagi para game developer untuk tetap mempertahankan kode mereka saat ini. Saat kita dengan hati terbuka menyambut baik ide untuk mempertahankan kebutuhan hardware minimum bagi OS baru, menghilangkan dukungan untuk OS lama adalah hal yang tidak akan didukung para gamer. Jika Win 7 menjadi Vista lain yang lebih mahal, kita akan tetap menggunakan Dx 9, khususnya untuk game casual dan mainstream yang biasanya memang agak tertinggal dalam hal teknologi(juga untuk konsol yang masih memakai hardware DX 9 untuk beberapa tahun ke depan).
LEBIH JAUH LAGI TENTANG DX 11
DAN ENGINE GAME MULTI THREADED
Dengan mengesampingkan fakta bahwa pemrograman multi threaded telah ada sepuluh tahun terakhir, kebanyakan programmer tidak terfokus pada pemrograman paralel hingga hadirnya CPU multi core seperti sekarang. Kebanyakan kode program ditulis single thread, oleh karena menambah performa melalui pemrograman paralel bisa teramat sulit dan tidak selalu terlihat apa kelebihannya dibandingkan sungle thread. Hukum Ahmdal tetap berlaku yaitu kecepatan dari paralelisasi dibatasi oleh prosentase kode yang wajib berurutan,bahkan bagi para programmer berpengalaman sekalipun.
Dalam pengembangan sebuah game, saat ini rendering merupakan salah satu task yang “wajib” untuk berurutan tersebut. DX 10
sendiri tidak disiapkan untuk secara tepat menangani banyak thread dan melimpahkannya ke GPU. Hal ini bukan berarti paralelisasi dari proses render tidak dapat dilakukan, bisa saja dilakukan namun akan sedikit mengorbankan kecepatan karena dibutuhkan teknik sinkronisasi atau manajemen thread yang harus diterapkan untuk senantiasa memastikan tidak ada bagian yang terlewat. Semua hal ini membatasi keunggulan dari proses paralelisasi dan menghalangi para programer untuk berusaha lebih keras lagi. Lagipula jauh lebih baik jika mengalokasikan lebih banyak tenaga untuk membenahi performa secara signifikan daripada untuk hal tersebut (sinkronisasi dan sebagainya).
Tidak menjadi masalah apa yang sudah dilakukan, beberapa hal dalam proses render tetap wajib untuk berurutan. Program, tekstur dan resource harus di load lebih dahulu;geometry ditangani sebelum pixel diproses; sementara calling program dieksekusi
bersamaan dengan sebuah state tertentu yang harus senantiasa aktif dan tidak berubah hingga selesai. Bahkan dalam sebuah mesin paralel yang luar biasa besar,keterurutan harus tetap dijaga meskipn bukan yang utama.
Microsoft telah membuat banyak game developer lebih mudah dalam mengelola kode game dan kode rendering dengan cara membuat banyak hal yang thread safe melalui sebuah perangkat interface tambahan yang dilengkapi banyak konteks serta membuat banyak sekali sinkronisasi yang mana telah melampaui tanggung jawab dari API atau driver grafis itu sendiri. Hal ini akan bekerja pula pada hardware DX 10 yang berjalan pada DX 11 dengan terpangkasnya sedikit performa serta kelebihan fitur- fitur DX 11 secara hardware. Namun kemampuan dasar untuk menulis kode secara berbeda akan menjadi investasi jauh ke depan bagi game dev agar lebih terbiasa dengan proses paralelisasi yang lebih baik. Sekarang kita lihat beberapa tools yang tersedia pada DX11
Tool pertama adalah free threaded asynchronous resource loading. Tool ini memampukan para programer untuk mengupload program, tekstur, keadaan objek dan keseluruhan resource pada cara yang lebih thread safe dan bersamaan dengan proses rendering jika diinginkan. Ini bukan berarti keseluruhan hal akan dijalankan bersamaan dengan proses rendering karena driver akan mengatur waktu pengiriman dan apa yang dikirimkan menuju GPU berdasarkan prioritas, ini artinya developer tidak perlu lagi berpikir tentang sinkronisasi atau memprioritaskan secara manual proses loading tiap resource yang ada. Banyak Thread dapat mulai meload resource apapun setiap saat dibutuhkan. Fakta bahwa hal ini dapat dilakukan bersamaan dengan proses render berarti akan terjadi peningkatan performa pada game yang melakukan data streaming untuk merender dunia yang sangat luas(GTA misalnya). Perangkat D3D sendiri akan dibagi menjadi tiga interface berbeda untuk memungkinkan hal seperti di atas terjadi, yaitu bagian Device, Immediate Context(IC), dan Deferred Context(DC). Penciptaan resource dilakukan melalui device. IC merupakan antar muka untuk setelan keadaan(state )perangkat, draw calls dan query. Sedangkan DC sendiri adalah antarmuka lain yang dipakai untuk banyak keadaan (state) dan banyak draw calls dalam satu program yang dapat pula digunakan untuk antar muka tiap thread (DC sendiri masuk dalam thread unsafe. Berbeda dengan IC dan device yang hanya bisa menangani satu keadaan dan satu draw calls saja. Keunggulan DX 11 dalam multi threaded sendiri berasal dari DC dan penciptaan resource bebas melalui perangkat yang tersedia tersebut. Banyak thread mengirimkan state(keadaan) dan draw calls menuju DC yang di dalamnya terdapat daftar tampilan (display list) yang pada akhirnya akan dieksekusi oleh IC. Game masih tetap membutuhkan sebuah thread untuk melakukan proses render, dan thread ini akan menggunakan IC untuk mengeksekusi state (keadaan) dan draw calls serta untuk “mengkonsumsi” daftar tampilan yang dihasilkan oleh DC. Dengan demikian, tujuan akhir dari state dan draw calls ada pada IC, namun sinkronisasi ditangani oleh API dan display driver sehingga thread parallel bisa jauh lebih berperan pada proses rendering. Beberapa batasan pada DC adalah
ketidakmampuan untuk melakukan query pada device dan ketidakmampuan membaca atau mendownload apapun dari GPU.
Hasil akhirnya adalah di masa depan semua hal akan lebih paralel friendly. Kita akan membutuhkan semua pertolongan yang ada pada saat mencoba mengambil keuntungan dengan paralelisme seiring dengan makin populernya dual dan quad core CPU seme tara 8 dan 16 core CPU sendiri sudah menanti dibalik pintu.
Tentang Compute Shader dan Open GL/OpenCL
Banyak developer terpesona dengan tambahan fleksibilitas yang ada pada Compute Shader (CS). Tambahan pada pipeline ters but menandakan adanya kemajuan dalam API yang lebih render sentris serta memampukan adanya lebih banyak logaritma general purpose. Kita akan temui tambahan fleksibilitas pada kedua operasi yang dapat diterapkan baik pada data maupun tipe data yang dapat dioperasikan. Pada tingkatan pipeline yang lain, ditemui adanya batasan- batasan yang sengaja dirancang untuk mempercepat eksekusi dalam kode general purpose. Meskipun kita bisa memaksakan logaritma general purpose ke dalam sebuah program pixel shader, tetap saja tidak ada kebebasan untuk menggunakan struktur data seperti percabangan, sharing data antar pixel (dan threadnya) sangat sulit dan mahal, dan kita harus lebih dahulu melalui urutan proses menggambar triangle dan solusi mapping.
Dalam DX 11 dan CS, developer memiliki pilihan untuk melewatkan struktur data melalui CS dan menjalankan lebih banyak logaritma general purpose pada CS juga. CS akan men-share satu set resource fisik (yaitu shader processor) seperti yang ada pada tingkatan pemrograman penuh dari pipeline DX 10 dan Dx11 Hardware untuk DX 11 perlu sedikit lebih fleksibel daripada apa yang ada saat ini untuk menjalankan kode CS. Hardware tersebut haruslah mendukung random reads and writes (pembacaan dan penulisan acak) serta irregular array (dibandingkan array 2d ukuran tetap ),mendukung multiple output, campur tangan langsung dengan thread individu maupun grup sesuai kebutuhan programer, ruang shared register 32 k, manajemen thread dalam grup, instruksi atomis, sinkronisasi konstruksi serta kemampuan untuk menampilkan operasi IO tak berurutan.
Pada saat yang sama CS juga akan kehilangan beberapa fitur, karena tiap- tiap thread tidak lagi diperlakukan sebagai sebuah pixel
maka asosiasi dengan bangun geometri otomatis hilang(kecuali dilewatkan dalam struktur data secara spesifik). Hal ini berarti juga perhitungan otomatis LOD(level of detail) trilinear tidak lagi otomatis(LOd harus ditentukan) meskipun program CS masih bisa menggunakan texture sampler. Sebagai tambahan, depth culling, anti aliasing, alpha blending dan operasi- operasi lain yang tidak berarti pada data secara umum tidak akan bisa dilakukan dalam program CS.
Tipe aplikasi baru yang dapat dilakukan oleh CS sebenarnya tidak terbatas, namun yang akan segera menarik perhatian berasal dari developer game sendiri yang akan menambahkan engine grafis mereka dengan berbagai teknik yang tidak dimungkinkan oleh pixel shader. Beberapa teknik diantaranya termasuk teknik A-Buffer yang memungkinkan adanya anti-aliasing kualitas tinggi dan transparansi independen, teknik penundaan shading yang lebih maju, efek post-processing yang lebih maju dan rumit, FFT(Fast Fourier Transform,yang kuliah Fisika Matematik pasti tahu susahnya!!) untuk operasi domain frekuensi dan tabel area penambahan. Di belakang aplikasi rendering tertentu, developer game dimungkinkan juga melakukan hal hal seperti IK(Inverse kinematik/ kinematika terbalik), physics, AI dan tugas- tugas tradisional CPU lainnya pada GPU. Dengan ketersediaan data ini pada GPU yang dibantu kalkulasi nya oleh CS berarti data akan tersedia lebih cepat untuk digunakan dalam proses rendering dan terdapat beberapa logaritma yang bisa lebih cepat pula dilakukan pada GPU. Bahkan terdapat juga pilihan untuk melakukan physics dan AI baik pada GPU maupun CPU apabila ditemukan logaritma yang dapat senantiasa memberikan hasil serupa pada kedua tipe prosesor (yang akan menggantikan daya komputasi dengan bandwidth). Kode PS dan CS akan bekerja dengan cara yang sangat berbeda tergantung dari logaritma yang dipakai meskipun berjalan pada hardware yang sama. Salah satu hal yang patut diperhatikan adalah data exposure dan histogram yang digunakan pada proses render HDR. Mengkalkulasi data tersebut pada PS memerlukan beberapa langkah dan trik untuk seluruh pixel, baik untuk mengurangi atau merata-ratakannya. Sharing data akan sedikit memperlambat beberapa hal, namun akan jauh lebih cepat bila dibandingkan menjalankan banyak pass(seperti kalkulasi data PS saat ini). Hal ini pula yang mampu menjadikan CS sebuah tingkatan ideal bagi ogaritma semacam ini. Sebagai informasi , OpenCL akan mampu pula untuk berbagi struktur data dengan OpenGL. Belum diketahui adanya developer yang membandingkan OCL dengan CSnya DX11, tetapi ada kemungkinan OCL juga akan kompatibel dengan CS-nya DX11 sama seperti OGL+OCL. Open CL lebih ditujukan untuk antar muka komputasi general purpose yang dipercepat GPU dan independen dari Microsoft dan DX dibandingkan CS -nya DX 11 yang lebih menitikberatkan pada grafis 3d. Dengan demikian open CL akan lebih banyak digunakan untuk bahasa komputasi GPU dalam banyak aplikasi general purpose. Lima tahun terakhir pemakaian Open GL menurun secara drastis. Seiring dengan adanya kombinasi OCL+OGL, pasar untuk OGL sendiri kelihatannya akan lebih terfokus pada aplikasi CAD/CAM dan aplikasi simulasi yang memerlukan visualisasi.
Apa itu Tesselator?
Chipset pada GPU radeon R6xx(HD 2000,3000) dan R7xx(HD4000) telah memiliki tesselator namun tidak akan semata- mata bisa langsung kompatibel dengan DX11 karena pada radeon penerapannya lebih tertutup sementara pada DX 11 memiliki setelan yang jauh lebih maju. DX11 menyertakan masukan dan keluaran yang dapat diprogram dari Tesselator(TS) melalui dua tingkatan pipeline yang disebut Hull Shader(HS) dan Domain Shader(DS), sementara tesselator itu sendiri tidak akan programable(baik pada hardware AMD atau DX11 kelak). Tesselator dapat memecah bangun(poligonal) yang sangat b sar dan sederhana(kurang detail) menjadi bagian- bagian yang lebih kecil dan membentuknya ulang menjadi bangun geometri yang lebih kompleks mendekati kenyataan. Misalnya TS bisa mengubah sebuah kubus menjadi bola dengan sedikit overhead dan kebutuhan ruang yang lebih kecil. Hal tersebut menunju kan keunggulan kualitas , performa dan kemampuan manaj men yang baik. HS sendiri akan membawa masuk patches dan mambawa data keluaran control points tentang cara konfigurasi TS. Patches sendiri adalah sebuah primitif(bangun sederhana seperti titik sudut dan pixel)yang menentukan bagian dari sebuah bangun datar yang akan diolah oleh TS. Sedangkan control points dipakai untuk menentukan parameter bentuk dari permukaan yang diinginkan (misalnya lenkungan/kurva). Mirip dengan pen tool pada photoshop yang menerapkan permukaan bangun (seperti kotak atau lingkaran) dan bukan garis. HS menggunakan control points (titik kendali)untuk menentukan setelan TS dan melewatkannya ke DS. Fungsi dari TS sendiri hanya melakukan teselasi,yaitu memecah patches yang diumpankan HS berdasarkan parameter yang diberikan
HS untuk tiap patch. Kemudian keluaran yang berupa aliran titik- titik akan menuju DS untuk diolah guna melengkapi ke eluruhan proses. Programmer sendiri hanya perlu menuliskan program HS untuk kode mereka dan tidak dibutuhkan pemr gr man untuk TS sama sekali. TS hanyalah sebuah blok berfungsi etap yang bertugas mengolah masukan berdasarkan para eter yang diberikan. DS mengambil titik- titik yang dihasilkan TS dan memanipulasinya untuk membentuk geometri yang tepat berdasarkan atas control points dan atau displacement maps( pemetaanpengambilalih/pengganti). DS mampu melakukan m nipulasi tentang bagaimana menggeser lebih jauh atau menganti teksur titik- titik yang baru saja dihasilkan berdasarkan control points dan tekstur yang ada dengan cara menjalankan program DS yang telah dirancang oleh developer sebelumnya. Setelah titik- titik diolah akan dihasilkan vertex(sebuah titik sudut).Vert ces( Titik sudut – titik sudut) ini dapat diproses lebih jauh oleh Geometry Shader (GS), yang dapat juga mengumpankannya kembali pada Vertex Shader(VS) dengan fungsional tas stream out.Kita mungkin akan melihat kebanyakan keluaran dari DS akan langsung menujuproses rasterisasi sehingga geometri yang terbentuk akan dipecah menjadi fragmen ruang layar untuk pemrosesan pixel shader. Demikian sedikit pengetahuan dasar tentang hal yang bisa dilakukan TS dan cara TS melakukannya. Namun bukankah GS yang ada pada DX 10 sekarang ini juga bisa menciptakan permukaan yang telah diteselasi dan memindahkan hasilnya juga ? Memang secara teori GS bisa saja melakukannya, namun tidak dalam prakteknya.
Tesselasi : Karena GS (Geometry Shader) Belum Cukup Cepat!
Kelihatannya Microsoft dan AMD lah yang paling bergairah ketika topik tentang DX 11 mencuat. AMD telah sejak lama me perkenalkan tesselasi, dan mungkin juga cukup masuk akal untuk menggunakannya pada konsol seperti XBOX360. M nambahkan hardware fungsi tetap untuk menangani task yang meningkatkan lebih banyak jumlah memori tersisa dengan lebih cepat akan memberikan banyak kelebihan di ruang tamu (men ingat konsol biasanya ada di bawah TV ruang tamu kita dan juga keterbatasan RAM yang dimiliki). Tapi pada komputer desktop TS masih belum terlalu menjual meskipun tidak ada yang akan bisa menghalangi kemajuan TS yang sedang berlangsung saat iniAtau apakah perkembangan yang terjadi saat ini memang te lalu pesat? Karena TS sendiri tidak lebih dari sebuah hardware berfungsi tetap yang tidak dapat diprogram(semacam ALU pada mikroprosesor generasi awal yang hanya bisa untuk melakukan operasi penambahan saja). Memang masukan dan keluaran dari TS bisa sedikit dimanipulasi melalui HS dan DS, namun inti dari TS sendiri tidaklah sefleksibel itu. Sedangkan GS sendiri adalah sebuah blok yang dapat diprogram dalam pipeline yang mampu melakukan tesselasi dan banyak hal lainnya, namun memang belum mempunyai cukup power untuk melakukan tesselasi yang bisa dikatakan “berguna”. Jadi sementara pemrograman dalam rendering pipe melangkah semakin maju, bisa dikatakan dalam hal ini (keberadaan TS) adalah sedikit melangkah ke belakang. Tapi Kenapa?
Ada pendapat yang menyebutkan bahwa hardware fungsi tetap dengan hardware yang dapat diprogram bagaikan performa lawan fleksibilitas/kegunaan. Pada mulanya, hardware berfungsi tetap dibutuhkan agar mendapat kan performa yang dibutu kan. Seiring berjalannya waktu, jelas bahwa menambahkan lebih banyak hardware berfungsi tetap pada chip grafis tidaklah bisa diterapkan. Transistor- transistor yang ditambahkan pada har ware tertentu menjadi tidak terpakai jika tidak dibuat program yang khusus mengambil keuntungan dari hardware tersebut oleh developer. Sehingga secara umum menciptakan seku pulan resource komputasi yang dapat dibagi pakai untuk banyak tugas berbeda menjadi pilihan yang jauh lebih menarik dalam arsitektur sebuah hardware. Namun hal ini bukan berarti hardware berfungsi tetap tidak memiliki tempat tersendiri.
Pada TS masalah yang timbul sama, yaitu transistor pada TS tidak akan berguna kecuali para developer sengaja menarik k untungan dari hardware tersebut. Namun kasus pada TS jadi berbeda jika ROI (Return On Investment: kenutungan yang anda petik dari apa yang anda tanam) pada transistor- transistor tersebut benar- benar dimanfaatkan sepenuhnya oleh para developer: jauh lebih mudah untuk mendapatkan performa tesselasi yang tinggi dari TS dibandingkan menaruh sekian resources pada GS agar GS dapat melakukan tesselasi yang setara dengan performa dari TS itu sendiri. Tetap saja hal ini bukan berarti akan ada kebangkitan blok berfungsi tetap pada hardware grafis kita; hanya saja kemajuan signifikan fitur ini ke depannya masih memerlukan pengorbanan programibilitas pada masa-masa awal pengadopsiannya. Kebanyakan task masih akan tersedia dalam cara pemrograman yang lebih fleksibel, dan kemungkinan di masa depan akan kita lihat lebih banyak fleksibilitas diperkenalkan dalam TS hingga suatu saat TS sepenuhnya dapat diprogram (atau digabungkan dengan versi baru dari GS) Untuk saat ini janganlah kerumitan teknis ini membuat anda mengira game dev tidak tertarik untuk menguliti keuntungan- keuntungan yang bisa didapatkan dari TS. Sebagai contoh, sekarang ini artist perlu menciptakan lebih banyak versi dari tiap objek untuk LOD yang berbeda- beda (mengurangi atau menambah kompleksitas objek yang bergerak menjauh atau mendekati pemain, misal saat ini bisa dilihat pada game FarCry2) dan simulasi geometri oleh pixel shader dengan m makaikan tekstur pada tiap- tiap LOD. Proses ini memerlukan kerja ekstra bagi programer maupun artist yang tidak sebanding dengan sedikitnya peningkatan performa yang didapatkan. Ada juga beberapa efek yang hanya bisa dilakukan dengan lebih banyak geometri. Tesselasi adalah cara hebat untuk mendapatkan lebih banyak detail, bayangan dan tepian yang halus pada geometri. Geometri tinggi berarti juga memampukan efek pergeseran mapping yang lebih keren. Pada saat ini geometri disimulasikan melalui tekstur yang disertai teknik seperti bump mapping atau parallax occlusion mapping. Bahkan dengan geometri yang lebih besar, akan diperlukan pula normal map yang lebih besar untuk logaritma lighting yang dipakai, tetapi tentu saja kita tidak perlu melakukan banyak pekerjaan hanya untuk membuat detail kecil yang akan muncul pada geometri seperti retakan atau tonjolan karena kita hanya perlu melakukan tesselasi dan meletakkan detail itu dalam satu kali pass melalui pipeline. Hal yang jauh lebih cepat, efisien dan menghasilkan lebih banyak efek yang mendetail sementara membebaskan resource pixel shader u tuk hal lain. Dengan TS, seorang artis dapat membuat satu sub divisi dari sebuah permukaan yang memiliki LOD dinamis de gan begitu mudah; sebuah HS sederhana dan sebuah displac ment map yang diterapkan dalam DS akan menghemat banyak pekerjaan, meningkatkan kualitas dan menghasilkan sedikit peningkatan performa. Jika para developer mengadopsi TS, akan kita lihat banyak hal keren, dan bersamaan dengan perpindahan ke hardware DX 11, baik NVIDIA atau AMD pasti akan turut ambil bagian dalam peningkatan kemampuan tesselasi. Namun sekali lagi, baik TS atau CS sendiri dalam waktu dekat tidak akan serta merta digunakan para developer. Karena DX 11 sendiri mampu berjalan pada tingkatan hardware yang lebih rendah maka pada saat perilisannya nanti masih akan ada ba yak penerapan fitur dari DX 11 yang ditunda agar bisa berjalan juga pada hardware DX 10.Tentu saja, pada titik ini game dev bisa dengan penuh percaya diri mengeksploitasi segala aspek dari hardware Dx 10. Banyak orang yang masih menginginkan DX9 karena kegagalan Vista, artinya Dx 10 lebih kurang hanya menjadi versi peningkatan DX9 daripada sesuatu yang secara fundamental berbeda. Jadi pada saat DX 11 keluar, akan kita saksikan apa yang bisa dilakukan game Dev dengan Dx10, Tentunya akan ada pula developer yang bereksperimen dengan TS, tapi mungkin hanya berkisar pada sedikit peningkatan untuk menyingkirkan tepian yang masih bergerigi disekitar permukaan melengkung. Masih dibutuhkan banyak waktu untuk menerapkan teknik tesselasi yang lebih maju seperti yang diharapkan banyak orang.
Penutup
Hal terakhir dari DX11 akan membahas mengenai update pada HLSL (high Level Shader Language) versi 5.0 yang membawa beberapa peningkatan bagi para developer. Dengan syntax yang menyerupai bahasa C, HLSL 5.0 menambahkan duku gan untuk class dan interface. Beberapa perubahan dibuthkan karena ukuran kode shader yang ada saat ini makin membengkak. Programmer dan artis perlu untuk membangun atau menghasilkan sebuah shader berukuran besar atau banyak sekali shader berukuran kecil- kecil untuk tiap game. Kode- kode ini sangat besar ukurannya dan akan sangat sulit diatur tanpa struktur OOP(object oriented programming) . Terdapat beberapa perbedaan antara OOP pada HLSL dan OOP program lain. Con ohnya pada HLSL tidak diperlukan adanya manajemen memori (karena tidak adanya pointer) atau constructor dan destructor. Task semacam proses inisialisasi ditangani melalui update terhadap buffer yang berupa konstanta, dan umumnya mewakili data member. Disamping aspek pemrograman, class dan iterface ditambahkan pula guna menghadapi rumitnya pengembangan dengan jumlah resource dan efek yang luar biasa besar. Dynamic linking memampukan aplikasi untuk memutuskan shader apa yang harus dikompilasi dan dihubungkan ketika program sedang berjalan serta menyediakan antar muka yang tetap ambigu hingga program dijalankan. Saat dijalankan, seluruh shader dihubungkan secara dinamis dan berdasarkan hubungan tersebut keseluruhan fungsi yang dimungkinkan pada batang tubuh program kemudian dikompilasikan dan dioptimalkan. Kumpulan kode asli hardware tidak akan dimasukkan dalam baris pemrograman sampai dengan fungsi SetShader yang sesuai dipanggil. Fleksibilitas yang diberikan akan mengijinkan pengembangan kode shader yang lebih dinamis dan kompleks, sehingga keseluruhan kode idak perlu berada dalam satu blok dengan banyak “if”, atau tidak diperlukan juga ribuan shader k cil yang mengganggu konsentrasi para developer. Cara ini akan membantu DX mengurangi kompleksitas kode yang seringkali menjadi masalah ketika pengembangan sebuah game berlan sung, meskipun performa dari shader sendiri masih sebatas hal- hal yang bisa dilakukan saat ini saja. DX 11 luar biasa agresif karena dilengkapi dengan kemampuan seperti akses memori tak berurutan, multi-threading, tesselasi, dan Compute Shader. Kompleksitas upgrade dapat dikurangi dengan kenyataan ba wa tidak terdapat perubahan besar- besaran seperti pada perubahan dari DX9 ke DX 10 karena DX 11 sendiri dalam hal fitur tidak lebih hanyalah penyempurnaan dari DX10. Hal ini yang memampukan DX 11 berjalan pada tingkatan hardware lebih rendah (dimana fitur khusus pada DX11 tidak digunakan ), ketika digabungkan dengan peningkatan pada HLSL dengan O Pnya dan linking shader dinamis bearti developer hanya akan mengalami sedikit kecemasan ketika berpindah dari DX 10 ke DX 11 daripada dari DX9 ke DX10(Tentu saja seperti biasanya seperti yang sudah-sudah: game DX8 yang pertama muncul ketika DX9 diluncurkan , dan game DX9 yang berbobot baru muncul ketika DX10 diluncurkan) Sejujurnya kebutuhan untuk mengupgrade OS juga dapat menjadi salah satu senjata and lan. Hal ini tidak akan menjadi masalah karena Vista yang m nyebalkan tetap mendapat dukungan DX11 (sehingga penguna vista tidak diharuskan melakukan upgrade) dan Win 7 dapat menjadi pilihan upgrade yang sesuai bagi pengguna XP. Para pengembang yang setia dengan DX9 juga akan melewatkan DX10 secara keseluruhan demi Dx11 tergantung prediksi tan gal peluncuran game mereka; tanda- tanda yang ada saat ini juga menunjukkan DX 11 akan sangat menentukan waktu te jadinya revolusi seperti yang dijanjikan sebelumnya oleh DX10. Developer masih memiliki cukup waktu untuk membiasakan diri dengan tambahan keunggulan dalam hal programibilitas yang sebelumnya ditawarkan DX 10(tapi tidak terwujud), pengkod an DX 11 pun akan lebih mudah dengan dukungan konstruksi OOP dan multi-threading, serta kemampuan untuk berjalan pada hardware yang lebih rendah dengan lingkungan pengkodean yang lebih baik akan membuat para developer tidak punya al san lagi untuk tidak segera berpindah ke DX11.
