R520 在 GPGPU 方面的優勢 - PCDVD數位科技討論區

		PCDVD數位科技討論區 > 電腦硬體討論群組 > 顯示卡討論區
R520 在 GPGPU 方面的優勢

主題工具

Artx1

Master Member

加入日期: Jun 2002

您的住址: 耗電量頗高的地方.

文章: 1,959

R520 在 GPGPU 方面的優勢

http://techreport.com/onearticle.x/8887

Tech-Report報導了ATI與Stanford的Mike Houston合作的這次demo。

要點有二：
1. ATI將與Havok合作，開發物理引擎所需的相關API。
2. R520在GPGPU上的優勢，並且有幾個現成的demo

有一份相關的文件可以參考，並且包含了相關的測試結果。
http://graphics.stanford.edu/~mhous...20-mhouston.pdf

可以看得出來這些測試裡面X1800XT有相當的優勢。

引用:

GROMACS – GPU Implementation：
Written using Brook by non-graphics programmers
– Offloads force calculation to GPU (~80% of CPU time)
– Force calculation on X1800XT is ~3.5X a 3.0GHz P4
– Overall speed up on X1800XT is ~2.5X a 3.0GHz P4
Not yet optimized for X1800XT
– Using ps2b kernels, i.e. no looping
– Not making use of new scatter functionality
The revenge of Ahmdal’s law
– Force calculation no longer bottleneck (38% of runtime)
– Need to also accelerate data structure building (neighbor lists
‧ MUCH easier with scatter support
This looks like a very promising application for GPUs
– Combine CPU and GPU processing for a folding monster!

話說這邊有個有趣的部份，就是Mike Houston倡導的部份：

引用:

What GPGPU needs from vendors More information
– Shader ISA
– Latency information
– GPGPU Programming guide (floating point)
‧ How to order code for ALU efficiency
‧ The “real” cost of all instructions
‧ Expected latencies of different types of memory fetches Direct access to the hardware
– GL/DX is not what we want to be using
‧ We don’t need state tracking
‧ Using graphics commands is odd for doing computation
‧ The graphics abstractions aren’t useful for us
– Better memory management Fast transfer to and from GPU
– Non-blocking Consistent graphics drivers
– Some optimizations for games hurt GPGPU performance

What GPGPU needs from the community
Data Parallel programming languages
– Lots of academic research
“GCC” for GPUs
Parallel data structures
More applications
– What will make the average user care about GPGPU?
– What can we make data parallel and run fast?

這段的意思等於是說，GPGPU需要的資訊至少需要和CPU廠商提供出來的資訊同樣詳細；而以過往的經驗來說，這似乎會觸動到NVIDIA的神經....比方說光那個Shader ISA、Latency Information公開就已經觸動到NVIDIA的神經了吧。XD

所以短期內GPGPU這個範疇大概會是ATI比較佔優勢了。

此文章於 2005-10-13 03:16 AM 被 Artx1 編輯.

2005-10-13, 03:11 AM #1

熱鬥小狐

*停權中*

加入日期: Apr 2001

您的住址: 香港

文章: 1,441

那就等於跟要微軟開放程式碼一樣，甚麼都被看光光了

這樣不觸動NVIDIA的神經才怪

2005-10-13, 03:32 AM #2

L34RN3R Advance Member 加入日期: Oct 2001 文章: 373	這 Mike Houston 的網頁其實倡導的理念也不賴..『藉由更詳細的理解硬體，才能做出正確的軟體方面決定』不過在電腦程式越來越高階的今天，會實踐這理念來寫遊戲的人會越來越少吧。好像現在八成的程式設計師不會百分之百的狂打 assembly 一樣...
2005-10-13, 07:22 AM #3

Kis2080

*停權中*

加入日期: Apr 2005

文章: 709

引用:

作者熱鬥小狐

那就等於跟要微軟開放程式碼一樣，甚麼都被看光光了

這樣不觸動NVIDIA的神經才怪

+1
這是生門，亦是死門

2005-10-13, 09:53 AM #4

dvd+rw Basic Member 加入日期: Aug 2005 文章: 29	看看 ATI 開放 DX9 VGA 資料給 Intel 後，被 Intel 915G/915GM 吃掉多少市場便知一二，沒錯短期有所得着，但長久便輸掉市場.....
2005-10-13, 10:22 AM #5

chlang Master Member 加入日期: Dec 2001 文章: 1,747	起先還以為看錯, 或者打錯. GPGPU 原來是 General Purpose Computation on GPU.... 這樣的設定不是跟 PPU + GPU 蠻相似嗎 ? 可以有多少的取代性 ? 會不會讓 PPU 失去生存空間 ?
2005-10-13, 01:45 PM #6

idleic2

Master Member

加入日期: Mar 2004

您的住址: 亞洲.台灣.台北

文章: 2,054

引用:

作者L34RN3R

這 Mike Houston 的網頁其實倡導的理念也不賴..『藉由更詳細的理解硬體，才能做出正確的軟體方面決定』

不過在電腦程式越來越高階的今天，會實踐這理念來寫遊戲的人會越來越少吧。

好像現在八成的程式設計師不會百分之百的狂打 assembly 一樣...

shader 程式就像 assembly 一樣....

2005-10-13, 05:44 PM #7

Artx1

Master Member

加入日期: Jun 2002

您的住址: 耗電量頗高的地方.

文章: 1,959

引用:

作者idleic2

shader 程式就像 assembly 一樣....

繼續那樣寫下去會太辛苦吧....
HLSL有compiler，雖然應該不會比手刻assembly的效能好，
但是整體開發時程顯然會好很多。

Mike houston的本意應該是說，"開放規格出來讓社群作出GPGPU用的Compiler"
(原文－GPU's GCC)
但是反過來說，其實廠商如果也針對GPGPU的用途推出合需求的compiler就可以了，
除非通通都要Open Source，那就又是另一個範疇了。

2005-10-14, 12:14 AM #8

dabochi

*停權中*

加入日期: Nov 2002

您的住址: 東湖

文章: 1,688

引用:

作者dvd+rw

看看 ATI 開放 DX9 VGA 資料給 Intel 後，
被 Intel 915G/915GM 吃掉多少市場便知一二，
沒錯短期有所得着，
但長久便輸掉市場.....

這話怎講?
雖說ATi跟Intel有交叉授權
但是並不表示915G/GM內部的四條管線就是從ATi那兒來的吧
因為915G/GM的效能可是連同為4管的X300都比不上啊

2005-10-14, 02:33 AM #9

« 上一主題 | 下一主題 »

POPIN

主題工具
顯示可列印版本傳送本頁給好友

發表文章規則
您不可以發起新主題您不可以回應主題您不可以上傳附加檔案您不可以編輯您的文章 vB 代碼打開表情圖示打開 [IMG]代碼打開 HTML代碼關閉

所有的時間均為GMT +8。現在的時間是10:41 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。