AMD向社群完全開放繪圖硬體規格

http://lwn.net/Articles/248227/
AMD to open up graphics specs

http://www.0xdeadbeef.com/weblog/?p=302
a new road for AMD and ATI

根據這兩篇所提到,AMD決定開放前ATI的硬體規格(回朔至R500為止)給社群,使得Open Source社群可以完整使用Radeon chipset的2D/3D功能,並且所有人都可以取得完整的文件而不需受到NDA限制。

  • To develop of a fully functional 2D and 3D driver that supports all of their newer radeon chipsets. This will be done in full collaboration with the open source community and will have the direct participation of hackers from companies like Red Hat and Novell.
  • To release documentation that anyone can use to build and support drivers for their chips.

從這個狀況來看,一兩年內ATI的硬體在Linux下的support應該會大幅改善,考慮XBMC的Linux化,這個演進應該蠻值得期待;但是短期內因為還是只放2D規格,3D規格不知道什麼時候才放,所以這次短期內唯一意義等於只有「2D Open Source Driver支援到R500以後的硬體」而已。

——
過去Intel因為採行Open Source策略而受到社群大幅歡迎,現在的話AMD也跟進了,但是這兩家都存在CPU這個最大的戰略物資,這應該不是手上只有GPU的NVIDIA可以輕易跟進的。

不過除了基本教義派,我想這並不會真的提高太多ATI硬體的吸引力倒是真的…._A_
http://linux.slashdot.org/comments.pl?sid=288669&op=Reply&threshold=1&commentsort=0&mode=thread&pid=20480099

“I’d rather have a slower video card that actually works, than a fast one that doesn’t”

“That’s why nearly all Linux gamers and more than 60% of Windows gamers buy Nvidia cards. They’ve had better drivers for ages. Not open source, which disturbs some of the hardcore, but great drivers nonetheless.”

也就是說,因為東西能用、因為性能與Windows沒有落差,所以即使只有binary Driver,在Linux上目前NVIDIA的產品還是非常有吸引力;雖然包含FireGL功能在內都有開放,但是實際上ATI在Linux下的性能差距與Windows下有50%以上的落差,這當然會讓人感覺還有規格沒開出來,更別提即使在Windows底下的性能都和NVIDIA有落差。

[EDIT]
看起來AMD好像不是嘴巴說說….9/12,RV630的完整register列表文件出爐。
http://www.x.org/docs/AMD/
據稱 Novell 會在下周發表根據這些資料編寫的open source driver。
但是這些文件基本上仍然只有2D spec,沒辦法拿來寫3D加速的driver….

B3D的R600 AA模式探究

http://www.beyond3d.com/content/reviews/47/9
這篇很有得看….

B3D是對shader based AA評價很高,主要的原因是因為提供了更大的可能性,所以即使image quality尚需努力,方向是沒錯的。只是我自己比較懷疑這點,畢竟shader based custom filter是NV3x/R3x0時代就在講的東西….不過至少這可以確定,R600的RingBus不是造成AA性能低落的原因。

而就像先前討論到記憶體線性定址來串連的方式,RingBus可以提供類似CELL的EIB透過FlexIO來與其他CELL連結的結構一樣,照理來說只要加上外部介面,R600也可以透過RingBus快速地實作多GPU連結。

另外,雖然不論narrow tent或是wide tent filter,tent filter系用下去就會糊掉沒辦法,但R600還是有提供傳統的box filter,所以經過調整的話還是可以得到和過去R5x0一樣品質的AA效果。

補充:Hardware-Accelerated High-Quality Filtering
一篇在GPU上實作高品質filter的技巧簡介。

話說扣掉AA的部分,R6x0在shader上想靠compiler省成本、但是卻遇上DX10的語法結構限制提高而使得compiler optimize大幅吃鱉…. 結果D3D Rightmark 2.0發生的狀況完全在BioShock上再現。

Source:FiringSquard

http://firingsquad.com/hardware/bioshock_directx10_performance/page5.asp
http://www.firingsquad.com/hardware/bioshock_mainstream_gpu_performance/page6.asp


以上R600 vs G80

以上R6x0中階 vs G8x中階

補充一張各GPU對BioShock的PostProcessing工作負載耐性問題的數字,注目的部分是下降比例而非性能本身….

G8x結構上的抗壓性不同凡響….

這次的測試因為測試不再混用A卡與N卡於NVIDIA主機板(ASUS P5WDH Deluxe for Radeon)的關係,主機板的干擾應該是減到最低….

上面的結果可以推論,目前這個compiler問題如果無法獲得解決,可能最終會重演過去Valve對待NV3x的慘況。(Half-Life 2內NV3x被視為DX8 device)

IFA2007相關新聞

http://www.watch.impress.co.jp/av/docs/20070831/intel.htm
Intel提出軟體CAS,並且提出獨自市場調查的結果:不該設置任何copy管制,類比做得到的事情數位化卻受限,消費者持負面態度。

消費者希望越來越自由,內容商希望可以同一份content可以收到無限多的錢,這擺明是平行線….但是日本的全面copyonce已經是內容商方面的暴走了。

http://www.watch.impress.co.jp/av/docs/20070831/pioneer.htm
Pioneer對發售前的BDP-LX80進行規格強化,可以經由HDMI送出DTS-HD Master Audio的Bit Stream。
但是反倒pcm解碼時只能解出DTS 5.1,也就是硬體本身沒辦法解DTS-HD MA。

這會和當初LX70提供24p的時候對PS3造成刺激嗎?
拭目以待….

http://www.watch.impress.co.jp/av/docs/20070831/ifa01.htm
新Walkman放棄ATRAC格式,全面Open化。BDP-S300/S500亦於歐洲上市。

放棄ATRAC的確讓人感受到衝擊….跑去支援WM DRM,管理檔案也不再需要SonicStage了。

至於S500和LX80定位類似,都提供TrueHD/DTS-HD MA的decode與bitstream….
所以現在到底是HDMI晶片的硬體限制,還是單純是軟體驗證時程搞不太清楚。
後者的話當然又會增加對PS3的期待….XD

補充:BD V1.1規格10/31起生效,包含PinP與BD-JAVA將成為強制支援規格,目前已上市的硬體中只有PS3能支援。

GOW到底能不能移植到PS3上?

這好像是一直以來有許多人提的問題….

最近UT3 for PS3的表現不錯,所以這個問題又被拉出來講。
不過這個問題真的很有趣,所以和nukeduke兄先前有一段討論,主要就是針對GOW的一些貼圖技術來討論的,內容集中在Offset Bump(or Parallax Mapping)上。

首先是兩份相關的paper:

http://fabio.policarpo.nom.br/relief/index.htm
Relief Mapping

http://www.ati.com/developer/i3d2006/I3D2006-Tatarchuk-POM.pdf
Dynamic Parallax Occlusion Mapping with Approximate Soft Shadows

其實這個部份的問題在當初R520發表的時候就被拿出來提過了。當時ATI宣稱,G70要跑動R520的Toy Shop demo,得要有2GB的onboard記憶體,主因是因為3Dc,同時期G70支援3Dc壓縮過的材質的方法,是將之轉換成VU16 format的材質(Far Cry的時候是這樣處理)…. 這理所當然會造成材質儲存容量膨脹。

[EDIT:感謝RacingPHT兄指證C1不支援Fetch4]

所以因為上述的硬體支援format原因,RSX很難直接處理GOW所採用的材質。

注意的是,這算是總容量的延伸問題,並不是256MB+256MB雙介面造成的問題。實際上對RSX而言,目前PS3上的記憶體頻寬與PC上的G7x高階產品共具備256bit並沒有多大的差異,尤其在Cell Computing Board推出之後,已經很大幅度地證實了RSX對兩塊記憶體空間存取的效率都是足以負擔實效作業的,而 Relief Mapping 在經過幾次改版之後其實已經可以達到相當不錯的效果,不過你要叫廠商重做這些材質的功夫,顯然廠商是不願意負荷的。

UT3則應該是反過來配合PS3,在PC版上面使用Relief Mapping系統的技術,達到兩個平台相當類似的效果;但是反過來說,以MS的作風來講他們應該會願意替UT3這種關鍵title的材質重製成本。(而且Epic在UE3上也相當強調外包content的流程,也就是有人付錢的話東西就好辦)

另外RSX本身雖然有辦法比一般只有128bit記憶體介面的GPU表現得更好,但是因為有兩個不同的物理定址介面的關係,使得這種狀況並不如真正的256bit GPU般常出現。

—-
如果當初PS3採用G84的話,毫無疑問地可以吃下這些功能(後來都包進DX10了)….不過這又會造成peak performance削減;而且G84能不能直接吃下C1在360底下的負荷那又是另一回事。(雖然我傾向有辦法XD)

只是畢竟G84推出的時間離PS3上市的時間實在太遠了,討論上市時程的設定只怕也免不了事後諸葛的問題。

[EDIT]
補充一下Fielia提供的一些比較:

就目前rendering的研究來看,relief mapping在功能性上事實上比parallax mapping強大很多。
一來他能針對map起伏模擬self shadow,並且含有normal mapping,更可怕的是relief mapping本身其實足以勝任image-based rendering的相關問題。
這是因為parallax mapping只單純用coordinate offset製造表面起伏造成的視差,relief mapping則是真的做image warping,因此只要幾張圖片,就可以讓場景中出現一個看起來像是用mesh拼出來的model。
relief mapping不管是在XB360還是PS3都因為效率不如parallax+mesh,兩台都沒使用是意料中的事情,這兩台的vertex處理能力沒廢到幾千個polygon都跑不動,沒必要去用讓fragment shader壓力變超大的東西。
但是parallax mapping在PS3上很少看到,跟RSX處理parallax好壞應該無關(前面也已經證實parallax mapping對性能耗損不大);我認為需要浪費時間重寫shader,還有重建跟shader溝通的管道或許才是可能的因素。

Sample code:
http://www.shadertech.com/cgi-bin/shaders.cgi?filter=-1&page=3

也就是說,把4D+1D的東西重寫成3D+1D & 2D+2D的NV4x style是障礙了?

Silion Knight 對 Epic 興訟

ゲームエンジン裁判(1)巨額開発費に苦しむ中堅ソフト会社
ゲームエンジン裁判(2)EAも苦しんだ統合型環境の夢と現実
ゲームエンジン裁判(3)予期せぬ成功と大失敗を分けた差

http://amanoudume.s41.xrea.com/2006/11/post_299.html
次世代ゲーム機における日米の温度差

這兩篇一樣,都是提到UE3在各廠發生的問題,只是下篇是2006年底的事情,剛好是Frame City取消前後;上面則是剛剛發生的事情。

根據新清士所提到,SK針對UE3興訟主要的重點有:
1. 性能嚴重不如預期
2. update緩慢,以至於問題點改善遙遙無期

所以UE3的表現遠遠不能以當初UE2的實績來衡量,以目前來說Silion Knight在上訴書中的企圖是”將自己寫出來的引擎能視為獨立的引擎而不需要繳權利金”,當然Epic也沒辦法容許這點,不然大家都訂一套UE3當課本然後自己寫引擎就好不必繳權利金了,所以拼到後來老實說和解的機會最高,只是重點在於一家知名廠商也會被逼到這個地步,是很令人吃驚的一件事情。

對日本廠商來說,採用UE3的title其實不少,但是已經有一些掛掉了;反過來看到CAPCOM自行開發MT framework得到的成功,真的會讓人忍不住問UE3是不是問題大了。

趣文:能與貓共存的PC?

http://pc.watch.impress.co.jp/docs/2007/0828/nekopc01.htm
http://pc.watch.impress.co.jp/docs/2007/0903/nekopc02.htm
呃,應該說「能耐得住貓摧殘的PC」會比較適當。

這篇的作者大原雄介先生認識了一些家裡有貓的朋友,PC常常受到貓咪摧殘….所以開始思考一些PC用的抗貓對策。
這裡面有不少有趣的心得可以參考,不過主要的重點其實不出下列幾點:

1. cable類的話,包裹較厚的外包材,如軟管之類。
目的不是要牠沒辦法破壞,而是讓牠不想咬。Notebook當然比較不怕這點沒錯,問題是會被摔。

2. 對抗貓咪跳上跳下推倒的狀況,桌上型電腦可以利用合板釘個架子來強化,周邊則設法固定。

—-
看了這篇之後發現,自己家裡的貓咪是有比較安分…._A_a
相比之下,JK的回應是

這只是無謂的努力(經驗者

….ナムナム。

第二篇替XPC作了個很大的散熱改造。
不過我家的大概也沒有這樣改造的價值….XD

PS3 1.90 + TA-DA5300ES視聽報告 by 鈴木桂水

http://www.phileweb.com/news/d-av/200708/23/19165.html

在這篇裡面可以看到金井老爹拿著Sixaxis盯著小CRT上面的XMB….所以音質還是以外部手改過的PS3為前提,然後搭配TA-DA5300ES、喇叭採用B&W Matrix 801。
裡面除了既有的SACD視聽課題之外,還包含了TrueHD lossless codec decode測試。

なお今回はPS3での音出しですので、ドルビーT-HDのデコードはPS3のデコード部での音質差となります (PS3はドルビーT-HDのデコードができます)。つまりCELLパワーであればロスレスデコードとリニアPCMの音質の差は相当に小さいわけです。
TA-DA5300ESの低ジッタ・ロスレスデコードエンジンは、当然これを超える仕上がりをめざしており、すでにその差はほとんどわからないところまで来ています。是非今度、もう一度聴いてくださいね>桂水さん。
(by かないまる)

所以,TA-DA5300ES的開發最主要目的是把Lossless codec調到和LPCM同等的表現。

此外,かないまる針對了2007年9月號的「レコード芸術」的PS3 SACD專題寫了一點短文,還預告了Bit Mapping Type3即將release,會在之後的update放上去。
レコード芸術由於是classic音樂專門誌而非音響設備雜誌的關係,文章的意義有點不太一樣;當然主筆還是麻倉怜士就是了。

不過現在都8/28了,看來這個月沒有update啦…._A_

GeForce8延續

最近可能真的步調該放慢一點…..在年底NVIDIA的新產品只能算是產品小改款。

GeForce 8700 — G84的65nm版、或者是G98。前者的話是2TPC、後者的話就是3TPC。
GeForce 8950 — G92,規模應該會是6TPC,最高階版很可能是雙晶片的MCM。

這兩款的Shader可能會從MAD+MUL改成MAD+ADD,修改的部分不多,主要是成本改善。
不過本來G8x就已經幾乎完整支援DX10.1,就算僅止於改bug也還很夠用,而且PCIe 2.0也會開出來….
本來因為bug搭不起來的BR02會弄出A5版來配合,繼續對永遠打不死的AGP市場供貨。

看來雖然還是有點小改款,G8x會再陪伴我們好一陣子。

另外,如果G98確實是3TPC化,這樣和6TPC的G92就可以達成1:2,高階則是雙G92的MCM共12TPC,就可以達成從低到高剛好1:2:4,彌補先前G8x在G80與G84中間落差過大(沒有4TPC產品)的問題。

8/31的時候ZOL主辦一個NVIDIA市場經理專訪,在提供的資訊上面出現下面這張圖:
http://vga.zol.com.cn/topic/636500.html

上面提到G92 1000M電晶體。注意是「顯示卡」的總電晶體發展趨勢,不是單一GPU….且原始網址的G92數字已經被mask掉了。這夠此地無銀三百兩了吧XD

—-
補充一點別的東西: 兩顆G92該怎麼連接的問題,其實要回頭檢視G8x的TCP、以及CELL computing Board。

從CELL computinb Board的結構上、RSX對XDR存取的效率可以知道,線性對應定址、Cache coherency protocol做得好的話,一個GPU可以非常有效率地對另一個device的local memory作讀寫,所以其實我們大可把多數GPU用線性定址mapping串接起來,所以要是G92有512bit,那兩個G92就可以256bit對外、256bit互接就可以了;而G92的單晶片產品只要封裝上不實作完整的512bit,就可以達到產品區隔。

當然實體層不見得是這樣,可是觀念應該很接近了:既然上層結構(TCP)已經做了切割,那麼要做的其實只是把TPC–ROP中間這段corssbar跨晶片連結起來就可以。那麼前端FIFO workload的分配做好之後,所有的動作其實就都與Driver沒有關係,那連結效率就只剩底層I/O overhead,以及分離成兩塊的記憶體造成的一些零碎問題,但是這都可以解決(極端地來說對每塊ROP而言記憶體都是切塊分散的)。

用BR03對這部分也有一個明顯的好處:GPU BIOS其實在BR03上,對Host而言BR03後全部視為同一個GPU,除了能跨越BR03的NVIDIA之外。這對上述的實做法其實也是有利,只是沒搞錯的話目前Quadro Plex靠的也是BR03,這顆晶片適合這樣像多層星形連結的方式嗎?這倒是還有疑問。

現在只剩下黑歷史….