處理器 AMD 打造12核心APU?有可能嗎?

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
OpenCL 簡介

OpenCL 是由 Khronos Group 針對異質性計算裝置(heterogeneous device)進行平行化運算所設計的標準 API 以及程式語言。所謂的「異質性計算裝置」,是指在同一個電腦系統中,有兩種以上架構差異很大的計算裝置,例如一般的 CPU 以及顯示晶片,或是像 CELL 的 PPE 以及 SPE。目前,最為常見的就是所謂的 GPGPU 應用,也就是利用一般的顯示晶片(即 GPU)進行 3D 繪圖以外的計算工作。

過去 GPGPU 的應用,有各種不同的使用方式。最早的 GPGPU,多半是直接透過 3D 繪圖的 API 進行,例如 OpenGL 或 D3D 的 HLSL(High Level Shading Language)。但是,這樣做有很多缺點,主要是即使想要進行的運算和 3D 繪圖無關,仍需要處理很多 3D 繪圖方面的動作(例如建立 texture,安排 render-to-texture 動作等等)。這讓 GPGPU 變得十分複雜。後來開始有些嘗試把這些 3D 繪圖部份隱藏起來的想法,例如由 Stanford 大學設計的 BrookGPU,可以透過不同的 backend 將 Brook 程式轉換成由 CPU、Direct3D、或 OpenGL 來執行。另外,也有各家顯示卡廠商自行開發的系統,包括 ATI 針對其產品設計的 Close to Metal(以及後來的 AMD Stream),以及 NVIDIA 的 CUDA。Microsoft 也在 DirectX 11 中加入了特別為 GPGPU 設計的 DirectCompute。

由於各家廠商的 GPGPU 方案都是互不相容的(例如 AMD Stream 的程式無法在 NVIDIA 的顯示晶片上執行,而 CUDA 的程式也不能在 AMD 的顯示晶片上執行),這對 GPGPU 的發展是不利的,因為程式開發者必須為不同廠商的顯示晶片分別撰寫程式,或是選擇只支援某個顯示晶片廠商。由於顯示晶片的發展愈來愈彈性化,GPGPU 的應用範圍也增加,因此 Apple 決定提出一個統一的 GPGPU 方案。這個方案得到包括 AMD、IBM、Intel、NVIDIA 等相關廠商的支持,並很快就交由 Khronos Group 進行標準化。整個計畫只花了五個月的時間,並在 2008 年十二月時正式公開。第一個正式支援 OpenCL 的作業系統是 Apple 的 MacOS X 10.6 "Snow Leopard"。AMD 和 NVIDIA 也隨後推出了在 Windows 及 Linux 上的 OpenCL 實作。IBM 也推出了支援 CELL 的 OpenCL 實作。

OpenCL 的主要設計目的,是要提供一個容易使用、且適用於各種不同裝置的平行化計算平台。因此,它提供了兩種平行化的模式,包括 task parallel 以及 data parallel。目前 GPGPU 的應用,主要是以 data parallel 為主,這裡也是以這個部份為主要重點。所謂的 data parallel,指的是有大量的資料,都進行同樣的處理。這種形式的平行化,在很多工作上都可以見到。例如,影像處理的程式,經常要對一個影像的每個 pixel 進行同樣的動作(例如 Gaussian blur)。因此,這類工作很適合 data parallel 的模式。

OpenCL 的架構

OpenCL 包括一組 API 和一個程式語言。基本上,程式透過 OpenCL API 取得 OpenCL 裝置(例如顯示晶片)的相關資料,並將要在裝置上執行的程式(使用 OpenCL 程式語言撰寫)編繹成適當的格式,在裝置上執行。OpenCL API 也提供許多裝置控制方面的動作,例如在 OpenCL 裝置上取得一塊記憶體、把資料從主記憶體複製到 OpenCL 裝置上(或從 OpenCL 裝置上複製到主記憶體中)、取得裝置動作的資訊(例如上一個程式執行所花費的時間)等等。

例如,我們先考慮一個簡單的工作:把一群數字相加。在一般的 C 程式中,可能是如下:

float a[DATA_SIZE];
float b[DATA_SIZE];
float result[DATA_SIZE];

// ...

for(int i = 0; i < DATA_SIZE; i++) {
result = a + b;
}

在 OpenCL 中,則大致的流程是:
把 OpenCL 裝置初始化。
在 OpenCL 裝置上配置三塊記憶體,以存放 a、b、c 三個陣列的資料。
把 a 陣列和 b 陣列的內容,複製到 OpenCL 裝置上。
編譯要執行的 OpenCL 程式(稱為 kernel)。
執行編譯好的 kernel。
把計算結果從 OpenCL 裝置上,複製到 result 陣列中。
透過 data parallel 的模式,這裡的 OpenCL 程式非常簡單,如下所示:

__kernel void adder(__global const float* a, __global const float* b, __global float* result)
{
int idx = get_global_id(0);
result[idx] = a[idx] + b[idx];
}


在一般的版本中,是透過一個迴圈,執行 DATA_SIZE 次數的加法動作。而在 OpenCL 中,則是建立 DATA_SIZE 個 work item,每個 work item 都執行上面所示的 kernel。可以看到,OpenCL 程式語言和一般的 C 語言非常類似。__kernel 表示這個函式是在 OpenCL 裝置上執行的。__global 則表示這個指標是在 global memory 中(即 OpenCL 裝置上的主要記憶體)。而 get_global_id(0) 會傳回 work item 的編號,例如,如果有 1024 個 work item,則編號會分別是 0 ~ 1023(實際上編號可以是二維或三維,但在這裡先只考慮一維的情形)。

要如何讓上面這個簡單的 OpenCL kernel 實際在 OpenCL 裝置上執行呢?這就需要透過 OpenCL API 的幫助了。以下會一步一步說明使用 OpenCL API 的方法。
 

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
sorry吶 上面那兩篇不是故意要凸你 追車尾燈已經是好多年前就不流行的 現在流行橫向發展多核、多工、多能的CPU了 追製程追頻率追誰X86架構處理最快已經過時了
 

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
越玩越有趣 – OpenCL 與行動裝置的未來!
3月
11
2013
CTai
先節錄一下 OpenCL 在維基百科的介紹

OpenCL (Open Computing Language,開放計算語言) 是一個為異構平台編寫程式的框架,此異構平台可由 CPU , GPU 或其他型別的處理器組成。 OpenCL 由一門用於編寫 kernels (在 OpenCL 裝置上執行的函式)的語言(基於 C99 )和一組用於定義並控制平台的 API 組成。 OpenCL 提供了基於任務分割和資料分割的並列計算機制。
OpenCL 類似於另外兩個開放的工業標準 OpenGL 和 OpenAL ,這兩個標準分別用於三維圖形和電腦音訊方面。 OpenCL 擴充了 GPU 圖形生成之外的能力。 OpenCL 由非盈利性技術組織 Khronos Group 掌管。

最近對 OpenCL 很有興趣,常利用空閒時間看這方面相關的東西,所以跟大家分享一下個人的一些淺見。因為想講的東西很多,所以就打算把他寫成肥皂劇的劇本,看看會不會有人改編成電視劇,第一集就先介紹一些來龍去脈的東東,希望點閱率會不錯,不要被腰斬 :P。

第一集暖身就來介紹兩件事, OpenCL 的由來,以及 2012 年底前支援的狀況。

OpenCL 的由來
隨著 CPU 時脈對於效能的貢獻進入高原期,眾多軟硬體開發商將目光移向平行運算跟 GPU Computing 中。其中 Apple 聯合 AMD、IBM、Intel 跟 nVidia合作,在 2008 年提出一個支援異質運算的 API 給 Khronos 組織,這一個組織就是成功推動 OpenGL 的組織,希望藉由這專案能讓軟體開發人員可以將需要平行處理的高運算量程式碼用 OpenCL 寫好,然後可以在 CPU 或是 GPU 甚至是支援 OpenCL 的 DSP 上運算,達到一碼跑天下的境界。目前最新的是 2011 年 11 月的 OpenCL 1.2 版本。

到 2012 年底為止支援 OpenCL 的裝置
介紹完由來,現在拉回來告訴大家有哪些裝置或公司對 OpenCL 情義相挺,以及目前我收集到的近況。

x86 系統:x86 的世界有分 CPU 的廠商跟作 GPU 的廠商,以及兩邊都做的廠商。只做 CPU 廠商中最有名的當然首推 Intel。 Intel 的 CPU 在 Core i3, i5, i7 就有支援 OpenCL ,但是在 Ivy Bridge 才有讓 Intel HD Graphics 支援 OpenCL 。 而講到 GPU,最有名的當然就是 nVidia,大家都知道 nVidia 也有推自己的 GPU Computing — CUDA ,所以你要使用 nVidia 的 OpenCL SDK 其實是要裝 CUDA 的 SDK 的,然後就可同時實現兩種願望。 最後壓軸的是 AMD ,他是腳踏兩條船的代表,旗下有 CPU 跟 GPU 的技術,所以他開始推 APU,希望靠這瀨尿牛丸來一展身手,可惜出師未捷,就遇到 PC 業界的寒冬,一整個慘兮兮,否則我個人認為 AMD 可以說是推 OpenCL 最認真的廠商。 AMD 還有舉辦 AMD OpenCL Coding Competition,可惜只辦了一屆就沒有再持續下去,比如 2012 年的比賽看來就胎死腹中了。不然 Innovation Challenge 的第一名還有兩萬美金可以撈…總之,希望 AMD 可以振作起來囉!
附帶一提, x86 的 OpenCL 要注意的是 memory bus 的速度,因為 GPU 的記憶體和 RAM 的溝通很花時間,所以 x86 版本除了 AMD 的 APU 之外都要特別小心這件事,之後再來和大家分享 APU ,希望在我研究完之前 AMD 不要倒掉 :(。

ARM 的世界:ARM 的世界目前比較積極推 OpenCL 的屬推 ARM 的 Mali GPU 跟 Qualcomm 的 Adreno GPU 。目前在行動裝置上已經可以找到 Qualcomm S4 Pro ( Nexus 4就是用這個晶片組) 有硬體支援 OpenCL。SDK (Software development Kit) 目前應該是還在作,相關文件還不齊全,希望在 2013 年可以有較多的行動裝置支援 OpenCL。此外, Android 有推 RenderScript 這東西但目前只能支援在 CPU 上,尚不支援在 GPU 上運作,不過他的意圖跟 OpenCL 有不少相近之處,所以我個人倒很好奇在 Android 的 OpenCL 支援會是怎樣發展。另外因為 ARM 系統一般是 CPU 跟 GPU 共用記憶體,所以這方面的溝通成本應該會比較低。
因為 SDK 的提供,2013 年起已經可以在行動裝置上開發 OpenCL 的程式,個人保守估計在 2015 應該會是 OpenCL 在行動裝置上大放異彩的時候,之後再跟大家介紹一些 OpenCL 的 coding 如何撰寫,以及其他 Open Source Project 囉!
 

ga66728

我愛APU
已加入
10/10/06
訊息
2,263
互動分數
0
點數
36
看不懂!? 是凸我嗎?
我是挺AMD的啊!嘿嘿

謠言:NVIDIA說 ARM不玩了
想做X86的處理器 卻一直碰壁 最後輾轉做ARM!
要不是安卓崛起
我想ARM 軟體應用 是不會大於X86的

製程頻率是有極限的
以空冷最實際能應用的層面來說
5G 我想是INTEL最大的極限體質

INTEL製程技術算是頂尖的了
頂尖呈現出來也就是這樣
而且
INTEL敢開放低階不鎖倍頻處理器
我想 應該是單核心軟體的末日倒數了

想當年一堆人去追E8400 最後只能死守DDR2記憶體
之後記憶體DDR3 單條4G 崛起
導致
E8X00 2手最多僅存的殘值 是一堆不值錢(當然包括771處理器大量傾倒 你看775接腳一堆人死守 你就知道硬體效能沒進步多少!)

最後軟體會慢慢拋棄32位元
取而代之64位元

記憶體越來越大的情況底下
單核心效能 越來越不被需求(因為以後是沒多核心就跑不順的年代 說穿了製程到頂點了 頻率也超不上去了 只能往多核心發展)

遊戲大作 肯定是多核心的
只有模擬器 才需要單核心效能(這一點我還是懂的)

其實INTEL也一直再抉擇
桌機出的那幾款都是以單核心效能為依歸

伺服器 就不是了
而以多核心為依歸
在我看過 8C16T 與6C12T 同樣140W
6C12T 頻率比較高
但售價 8C16T比較貴

我想答案一切盡在不言中
 

bob015012

進階會員
已加入
3/2/07
訊息
326
互動分數
0
點數
16
年齡
37
這都你們自己想的= =
I社也不是白癡
要單核心我就給你單核心
要多核我就給你多核
整個電腦市場都被I社控制了= =
AMD只是往應用發展不然會倒
等市場決定要買單甚麼他就做甚麼
消費者不會管你們這麼多
甚麼多核-單核
我好用就好
 

ga66728

我愛APU
已加入
10/10/06
訊息
2,263
互動分數
0
點數
36
以前我常說
製程技術不如人
開放倍頻 讓一切依照體質而走(能超多少 是你的命)
AMD 確實做到了(被INTEL壓的打的情況底下 顆顆不鎖倍頻)
如今
這20週年不鎖倍頻 耐人尋味啊!
恰巧在手機-移動市場大流行的一年(堅持鎖倍頻 +100MHZ的成長幅度)
也就是低價K版 都不吸引人去玩超頻的時候........

整個電腦市場都被I社控制了
其實有第三方勢力崛起
電腦的形狀 和大小 一直在改變中

賈伯斯 最大的貢獻是 20年改變滑鼠的樣貌(手指觸控在以前是昂貴的技術 從電阻式 演變成電容式 一直到普及)
點子 可能10~20年就想出來了
可是要實現與普及卻是很難
巨磁電阻也是....(硬碟成長 從單碟500G ->1T ->1.2T)
前人種樹 後人乘涼
 

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
OpenGL[編輯]
OpenGL
OpenGL logo
原作者 矽谷圖形公司(SGI)
開發者 Khronos Group
穩定版本 4.4[1] / 2013年7月22日;11個月前
程式語言 C
作業系統 跨平台
型別 API
許可協定 多種[2]
網站 http://www.opengl.org
開放圖形庫(英語:Open Graphics Library,縮寫為OpenGL)是個定義了一個跨程式語言、跨平台的應用程式介面(API)的規范,它用於生成二維、三維圖像。這個介面由近三百五十個不同的函式呼叫組成,用來從簡單的圖形位元繪製複雜的三維景象。而另一種程式介面系統是僅用於Microsoft Windows上的Direct3D。OpenGL常用於CAD、虛擬實境、科學視覺化程式和電子遊戲開發。

OpenGL的高效實現(利用了圖形加速硬體)存在於Windows,很多UNIX平台和Mac OS。這些實現一般由顯示裝置廠商提供,而且非常依賴於該廠商提供的硬體。開放原始碼函式庫Mesa是一個純基於軟體的圖形API,它的代碼相容於OpenGL。但是,由於許可證的原因,它只聲稱是一個「非常相似」的API。

OpenGL規範由1992年成立的OpenGL架構評審委員會(ARB)維護。ARB由一些對建立一個統一的、普遍可用的API特別感興趣的公司組成。根據OpenGL官方網站,2002年6月的ARB投票成員包括3Dlabs、Apple Computer、ATI Technologies、Dell Computer、Evans & Sutherland、Hewlett-Packard、IBM、Intel、Matrox、NVIDIA、SGI和Sun Microsystems,Microsoft曾是創立成員之一,但已於2003年3月退出。

目錄 [隱藏]
1 設計
2 文檔
3 相關程式庫
4 歷史
5 繫結
6 高階功能
7 版本
8 參考文獻
9 外部連結
10 參見
設計[編輯]


圖形管線
OpenGL規範描述了繪製2D和3D圖形的抽象API。儘管這些API可以完全通過軟體實現,但它是為大部分或者全部使用硬體加速而設計的。

OpenGL的API定義了若干可被客戶端程式調用的函式,以及一些具名整型常數(例如,常數GL_TEXTURE_2D對應的十進制整數為3553)。雖然這些函式的定義表面上類似於C編程語言,但它們是語言獨立的。因此,OpenGL有許多語言綁定,值得一提的包括:JavaScript綁定的WebGL(基於OpenGL ES 2.0在Web瀏覽器中的進行3D渲染的API);C綁定的WGL、GLX和CGL;iOS提供的C綁定;Android提供的Java和C綁定。

OpenGL不僅語言無關,而且平台無關。規範隻字未提獲得和管理OpenGL上下文相關的內容,而是將這些作為細節交給底層的窗口系統。出於同樣的原因,OpenGL純粹專注於渲染,而不提供輸入、音頻以及窗口相關的API。

OpenGL是一個不斷進化的API。新版OpenGL規範會定期由Khronos Group發布,新版本通過擴展API來支援各種新功能。每個版本的細節由Khronos Group的成員一致決定,包括顯示卡廠商、作業系統設計人員以及類似Mozilla和谷歌的一般性技術公司。

除了核心API要求的功能之外,GPU供應商可以通過擴展的形式提供額外功能。擴展可能會引入新功能和新常數,並且可能放鬆或取消現有的OpenGL函式的限制。然後一個擴充功能就分成兩部分發行:包含擴充功能函式原型的表頭檔和作為廠商的裝置驅動。供應商使用擴展公開自定義的API而無需獲得其他供應商或Khronos Group的支援,這大大增加了OpenGL的靈活性。OpenGL Registry負責所有擴展的收集和定義。

每個擴展都與一個簡短的標識符關聯,該標識符基於開發公司的名稱。例如,英偉達(nVidia)的標識符是NV。如果多個供應商同意使用相同的API來實現相同的功能,那麼就用EXT標誌符。這種情況更進一步,Khronos Group的架構評審委員(Architecture Review Board,ARB)可能「祝福」該擴展,那麼這就被稱為一個「標準擴展」,標識符使用ARB。第一個ARB擴展是GL_ARB_multitexture。

OpenGL每個新版本中引入的功能,特別是ARB和EXT類型的擴展,通常由數個被廣泛實現的擴展功能組合而成。
 

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
OpenAL[編輯]
OpenAL
OpenAL Logo
原作者 Loki Software
開發者 創新科技
穩定版本 1.1 / 2005年6月1日
作業系統 跨平台
型別 API
許可協定 LGPL
網站 openal.org
OpenAL(Open Audio Library)是自由軟體界的跨平台音效API。它設計給多通道三維位置音效的特效表現。其 API 風格模仿自 OpenGL。

目錄 [隱藏]
1 歷史
2 API 結構和功能
3 可攜性
4 應用程式
5 參閱
6 外部連結
歷史[編輯]
OpenAL 最初是由 Loki Software 所開發。是為了將 Windows 商業遊戲移植到 Linux 上。Loki 倒閉以後,這個計畫由自由軟體/開放源始碼社群繼續維護。不過現在最大的主導者(並大量發展)是創新科技,並得到來自 蘋果公司 和自由軟體/開放原始碼愛好者的持續支援。

API 結構和功能[編輯]
OpenAL 主要的功能是在來源物體、音效緩衝和收聽者中編碼。來源物體包含一個指向緩衝區的指標、聲音的速度、位置和方向,以及聲音強度。收聽者物體包含收聽者的速度、位置和方向,以及全部聲音的整體增益。緩衝裡包含 8 或 16 位元、單聲道或立體聲 PCM 格式的音效資料,表現引擎進行所有必要的計算,如距離衰減、都卜勒效應等。

不同於 OpenGL 規格,OpenAL 規格包含兩個API分支;以實際 OpenAL 函式組成的核心,和 ALC API,ALC 用於管理表現內容、資源使用情況,並將跨平台風格封在其中。還有「ALUT」程式庫,提供高階「易用」的函式,其定位相當於 OpenGL 的 GLUT。
 

bbb1206

一般般會員
已加入
6/1/10
訊息
175
互動分數
0
點數
0
砸們別聽樓上那老鳥囉嗦 多吸收點知識有益身心健康
 

Patrick12345

一般般會員
已加入
4/10/07
訊息
86
互動分數
4
點數
8
sorry吶 上面那兩篇不是故意要凸你 追車尾燈已經是好多年前就不流行的 現在流行橫向發展多核、多工、多能的CPU了 追製程追頻率追誰X86架構處理最快已經過時了
這是一個值得思考的問題

每個人心中有把尺, 至少目前的市場並沒反應出HSA就是一切, HSA就是王道
Intel仍然盤據在x86成為霸主, 否則隨便一顆中低的的APU, 只考慮理論的運算能力峰值, 不只是AMD 最頂級的FX系列無法抗衡
連Intel最高階的i7系列也不會是對手的

而在ARM的市場上, 目前也仍然追隨著最先進的核心, 如果HSA在大多視情況都能有效發揮其強大(理論上)的運算能力
那可能用A7 or A5去配強而有力的GPU反而是更省電的, 但實際上我們看到的卻是各家SoC廠商, 仍然追著去使用最先進的核心A15和A57
(如果HSA如果廣告說詞般的強大, PowerVR應該可以兜售其強大的GPU IP, 風采搶過ARM, 而主導著市場,
而NV則在授權A9/A15後, 應該可以直接無視ARM核心的升級, 專心搞HSA)

HSA絕對是有幫助的, 但HSA可能不是一切
多核也是有幫助的, 但多核的效率在一般的應用上會被打折扣, 這也是顯而易見的
這類的東西, 絕對不是只往一邊傾斜

這種東西, 以商業的角度, 大家絕對都是對自己的產品/策略大肆吹捧,
然而商業的說法固然是一回事, 大家仍然要有自我思考的能力
 
▌延伸閱讀