hanzo0313 wrote:
hUMA應該不只這樣
因為HSA最終目標是要讓指令集進CPU之後能夠自由決定是交給CPU/GPU處理
這個要等Kaveri之後的後繼者再說,畢竟Kaveri並沒有作到你說的情況。如果是現有的x86/x87/SSE/AVX指令,進了CPU後就沒有理由再吐出來給GPU處理了,效率會很差;如果是定義新指令集,就必須讓作業系統跟開發工具廠商如微軟也買單。這就不像hUMA是技術問題,而是升級到公司-公司間的business層面了。
hanzo0313 wrote:
要解決這個問題首先就是要讓CPU/GPU能同樣存取共同的記憶體
因為不管是Intel UMA or A/N的獨顯,在交換系統記憶體時都還是需要轉譯
也就是GART,這部分一刀一槍都是要一個一個來,佔了很多記憶體cycle
所以hUMA要做的是這一步,跟Intel做的用快取來加速不太一樣...(恕刪)
讓CPU/GPU存取相同的記憶體,跟讓CPU/GPU存取相同的快取,出發點是類似的,前者是在記憶體層級上直接處裡CPU/內顯資料的Coherency,後者是在快取層級上處理CPU/內顯資料的Coherency。如果後者是為了「加速」,前者當然也是「加速」。作法不一樣,但都是為了讓CPU/GPU能夠直接存取同一份資料,不用一律複製來/複製去、同步來/同步去。
快取的存在跟快取演算法的設計,本來就是為了提高read/write命中率,讓CPU核心不用去相對慢很大的記憶體存取資料,Intel只是把內顯也擺在跟CPU核心一樣的層級,可以直接存取L3快取,跟CPU核心共享資料。
至於AMD把coherency設計在記憶體層級,也是合理的,前面就說過了,畢竟APU根本沒有L3快取。
Intel在3D遊戲效能這一塊,以HD4600來說,還是落後APU的(HD5200雖然遊戲效能贏過APU,但可預見無法普及),但是以OpenCL計算效能來看,完全不輸給APU。
hanzo0313 wrote:
真正能完成HSA的最後目標就是不用管什麼APP,計算的部份會由HW來決定
...(恕刪)
由系統軟體決定。
hanzo0313 wrote:
至於快取的部份...我想應該這麼說,不過我不確定Intel是不是100%這樣做
某APP透過OpenCL來執行計算
資料從SRAM(OS)->GART->CPU Cache->GPU FB->GPU Processing
如果像hUMA所做的
資料從SRAM(OS)=GPU FB->GPU Processing
...(恕刪)
SRAM(OS)??
Intel 作法:
L3快取命中:(絕大多數情況)
CPU core <--> L3 Cache <--> internal GPU
L3快取miss : (少數情況)
[CPU access GPU data]
DRAM allocated to internal GPU --> L3/L2/L1 cache --> CPU core
\> DRAM allocated to CPU
[GPU access CPU data]
DRAM allocated to CPU --> L3 cache --> internal GPU
\> DRAM allocated to GPU
AMD作法:
CPU core <--> DRAM <--> internal GPU
hanzo0313 wrote:
intel內顯還需要加油啦...但是有進步就是好事
不然一次解決,去找NV談GPU授權直接包進CPU比較快...
...(恕刪)
這......個人是覺得,等AMD能夠作到在FX-8350等級的處理器也包入等同HD4600效能等級的內顯,或是8670D等級的內顯搭配等同於4770K的處理器運算能力,再來酸也不遲.......

hanzo0313 wrote:
不不,如果是真正的HSA,計算工作進COMMAND queue之後
會交由scheduler來決定工作該直接交給誰處理
...(恕刪)
「工作」?command queue?在CPU核心跟GPU之上,再多加上一個太上皇硬體scheduler,來決定「工作」交給CPU或GPU(如何決定?),你所謂的真正HSA,根本已經不是x86架構了,所以才說必須系統軟體廠商背書,沒有作業系統支援,連最最最基本的context switch,都不會正確。
hanzo0313 wrote:
另外你提到的東西要做也不是做不到
看看ps4 & xb1....包的還是超特殊的小C大G哩 XD
...(恕刪)
說到小C大G,現階段桌上型APU便是如此,CPU加上GPU的總合運算力仍然不夠,畢竟CPU部分受限於只能2M4T便到頂了,且沒有L3快取。