Saat ini prosesor pada sebuah perangkat, bukanlah sekadar prosesor biasa saja. Di dalam sebuah paket “prosesor” sekarang sudah dijejalkan beragam komponen akselerator tambahan. Sebagai contoh, kontroler memori dan GPU sekarang sudah menjadi komponen umum di dalam prosesor. Bukan terletak di luar prosesor lagi (bukan di board). Pada smartphone dan tablet kini sudah dikenal apa yang disebut SoC (System on Chip) di mana keseluruhan sistem ada dalam sebuah paket “prosesor”. Ke depannya, SoC ini akan makin banyak digunakan oleh para produsen, bahkan hingga untuk prosesor berperforma tinggi seperti pada PC dan laptop.



Mari kita lihat, kira-kira ada komponen akselerator atau komponen yang bisa mengerjakan fungsi khusus di dalam SoC. Untuk tampilan, kini sudah ada GPU (atau dulu dikenal sebagai chip VGA card). Untuk audio, ada DSP (Digital Signal Processing) khusus. Untuk konversi video bisa saja disediakan sebuah unit khusus (contoh Intel Quicksync). Untuk pekerjaan sensor-sensor khusus bisa juga ditanamkan unit khusus (seperti pada Motorola MotoX). Ke depannya akan makin banyak komponen yang akan dijejalkan ke dalam SoC.

Pada awalnya, semua komponen di atas dikembangkan secara terpisah dan otomatis cara mengaksesnya pun terpisah. Jadi software yang ingin memanfaatkan komponen-komponen tersebut harus berusaha mengakses melalui interface berbeda. Bagaimana sebuah software bisa mengkombinasikan perangkat tersebut secara efisien adalah urusan software itu sendiri. Masalah ini diperburuk dengan kondisi lalu-lintas perintah yang rumit dan masing-masing komponen pun mengakses memori sesuai kebutuhannya sendiri-sendiri tanpa mempedulikan komponen lainnya.

Mari kita ambil contoh sederhana seperti pada APU AMD. Meski sekarang GPU sudah bisa dimanfaatkan untuk pekerjaan selain gaming, seperti melalui OpenCL, pemanfaatannya sebenarnya masih tidak efisien. Karena softare masih mengakses CPU dan GPU seakan keduanya terpisah dan bukan satu kesatuan. Kedua komponen tersebut masih akan mengakses memori sesuai kebutuhan masing-masing tanpa mempedulikan efisiensi kerja komponen lainnya. Selain itu, pemanfaatan GPU untuk kebutuhan general pun cenderung masih rumit.
contoh alur kerja dari sistem non-HSA seperti ini :

Masalah di atas adalah hal yang ingin dioptimalkan oleh HSA. Jadi, dengan teknologi yang dikembangkan HSA, semua komponen tersebut akan dapat diakses dari satu “titik” address yang sama. Metode aksesnya pun tidak rumit dan panjang. Hasilnya, perpaduan software dan hardware yang saling memahami kebutuhan satu dan yang lainnya dan dapat di-tune sesuai kebutuhan, misalkan untuk performa tinggi atau untuk hemat daya. Pada prakteknya, efisiensi dan optimalisasi ini menghasilkan performa yang lebih tinggi dengan konsumsi daya yang lebih rendah.

Satu hal yang menarik dari konsorsium ini adalah standar yang dirancang tidak mencanangkan adanya royalti. Jadi, bisa digunakan tanpa harus membayar ke satu pihak tertentu. Software dan tools yang dipakai juga digunakan yang berbasis open source, alias gratis juga. OpenCL adalah salah satu contohnya. Selain standar yang terbuka untuk mengakses GPU, OpenCL 2.0 yang baru saja diluncurkan, kini sudah kian optimal untuk bekerja sama dengan HSA. Seharusnya, dengan dasar ini, teknologi HSA bisa dikembangkan dengan mudah sekali. Akan banyak akademia dan bahkan mungkin “orang iseng” yang bisa mengembangkan software/perangkat yang kompatibel dengan sistem HSA dengan biaya minimum dan tanpa komplikasi hukum.

Pada implementasi awal, HSA memang masih berkutat seputar CPU (prosesor) dan GPU terlebih dahulu. Pada dasarnya sebuah software akan membutuhkan pengerjaan perintah dan umumnya diselesaikan oleh prosesor. Pada perkembangannya, seperti diketahui, GPU pun bisa membantu pengerjaan perintah tersebut dengan komputasi paralel. Akan tetapi, tidak semua pekerjaan yang dilimpahkan oleh software akan optimal jika dikerjakan di GPU saja. Jadi, ada pekerjaan yang sebenarnya lebih pas dikerjakan CPU dan ada yang lebih tepat dikerjakan oleh GPU.

Saat ini, software yang sudah bisa memanfaatkan GPU masih terhambat oleh sistem akses yang berbeda antara CPU dan GPU. Itulah sebabnya, penggunaan GPU pun masih cenderung jarang dilakukan oleh software secara umum. Akan tetapi, HSA kini datang untuk memuluskan hal tersebut. HSA, secara sederhana, memungkinkan software untuk mengakses CPU dan GPU secara mudah dan melimpahkan pekerjaan yang cocok baik untuk CPU maupun GPU tanpa waktu tunggu yang berarti.

Untuk menguji efisiensi HSA, dilakukan beberapa percobaan dengan menggunakan konfigurasi hardware:
APU: AMD A10-4600M (4 core CPU, AMD Radeon HD 7660G dengan 6 compute unit pada 685 Mhz)
RAM: DDR3 4GB
OS: Windows 7 64-bit







Di awal pembahasan mengenai HSA, memang teknologi ini ditujukan untuk sistem terintegrasi seperti pada APU AMD yang memiliki CPU dan GPU atau SoC pada smartphone dan gadget Anda. Akan tetapi, secara terbuka, Frank mengungkap bahwa HSA tidak harus hanya bekerja pada prosesor yang mengintegrasikan semua akselerator. Pada dasarnya, HSA seharusnya bisa membuat VGA card dan prosesor yang terpisah bekerja dalam keharmonisan dan kendali sebuah software secara efektif.

Jika ini diimplementasikan, ada kemungkinan, para pengguna PC pun bisa menikmati HSA di masa mendatang. Server dan workstation berat akan bekerja super-efisien dengan komponen super-kencang yang tidak/belum mungkin diintegrasikan ke dalam prosesor. Seperti kita ketahui, performa VGA terintegrasi paling kencang pun belum bisa mengalahkan VGA card kelas menengah.

Apakah AMD akan membuat VGA card yang dirancang kompatibel dengan HSA? Hal ini belum bisa dijawab oleh pihak AMD. Akan tetapi, jika ada yang paling pas untuk melakukannya, tentu adalah AMD. Karena AMD adalah salah satu perintis HSA. Sementara Intel dan NVIDIA, saat ini belum tergabung dalam konsorsium HSA.

Untuk membuat sistem HSA efektif, AMD sudah sejak lama memperkenalkan hUMA atau heterogeneus Uniform Memory Access. Ini jawaban terhadap masalah utama yang terjadi jika ingin mengendalikan CPU dan GPU dengan HSA.

Tanpa hUMA

• CPU memiliki alokasi memorinya sendiri. Semua yang ada dalam memori yang dikendalikan CPU ini hanya bisa dilihat oleh CPU.
  
• Di sisi GPU, terjadi hal yang sama dengan di atas.
  
• Masalah timbul saat ada sebuah pekerjaan yang harus diselesaikan CPU lalu diteruskan pengerjaannya oleh GPU.
  
• CPU akan memiliki data yang harus dilanjutkan pengerjaannya. Padahal, data ini adanya di memori khusus untuk CPU. Jadi, CPU harus memindahkan data ini ke memori khusus GPU terlebih dahulu, sebelum GPU dapat meneruskan pekerjaan.
  

Dengan hUMA

• Pada dasarnya, hUMA membuat CPU dan GPU bisa melihat data yang sama di dalam memori.
  
• Hal ini membuat pertukaran data antara CPU dan GPU menjadi mudah. Karena, CPU bisa menunjukkan alamat memori yang juga bisa dikendalikan (atau “terlihat”) oleh GPU. Begitu pula sebaliknya.
  

Nah, jika hUMA sudah membereskan masalah akses ke data, sekarang caranya perintah yang dikerjakan CPU bisa dipindahkan atau “dioper” atau dilanjutkan ke GPU dan sebaliknya? Untuk keperluan ini, AMD memperkenalkan hQ.