Half-Life 2 出問題啦!!! - PCDVD數位科技討論區

Artx1

Master Member

加入日期: Jun 2002

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

文章: 1,959

基本上, 這個事件對Valve本身的損失最大, 因為Valve本來是計畫在HL2之後,
販賣這套引擎的, 目前看來是別想賣了....
而且還外加洩漏了一些簽約的工具廠商的資料, 可以想見的是那些公司應該也會來索賠....
Valve現在動用社群的力量開始找兇手, 不過看來是只有亡羊補牢的效果了.

至於程式碼是不是有針對NV3x進行不當的負擔增大, 覺得是要慢慢K了.
ex:

代碼:

#ifdef NV3X

HALF4 EnvReflect( sampler envmapSampler,
    sampler normalizeSampler,
    HALF3 normal,
    float3 eye,
    HALF2 fresnelScaleBias )
{
HALF3 normEye = texCUBE( normalizeSampler, eye );
HALF fresnel = Fresnel( normal, normEye, fresnelScaleBias );
HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye );
return texCUBE( envmapSampler, reflect );
}

#else // NV3X

HALF4 EnvReflect( sampler envmapSampler,
    HALF3 normal,
    HALF3 eye,
    HALF2 fresnelScaleBias )
{
eye = normalize( eye );

HALF fresnel = Fresnel( normal, eye, fresnelScaleBias );
HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye );

return texCUBE( envmapSampler, reflect ) * fresnel;
}

#endif

目前看來, for NV3x的那些空跑似乎是頗有問題....

本來NV3x的那部份最後應該也是
return texCUBE( envmapSampler, reflect ) * fresnel
才對.... 不然那fresnel不就變成白算了嗎. ：～
(fresnel有丟到別的地方嗎?)

此文章於 2003-10-03 07:23 PM 被 Artx1 編輯.

2003-10-03, 06:54 PM #21

mokap

Major Member

加入日期: Jan 2000

您的住址: Taiwan,Taipei

文章: 238

引用:

Originally posted by Artx1
基本上, 這個事件對Valve本身的損失最大, 因為Valve本來是計畫在HL2之後,
販賣這套引擎的, 目前看來是別想賣了....
Valve現在動用社群的力量開始找兇手, 不過看來是只有亡羊補牢的效果了.

至於程式碼是不是有針對NV3x進行不當的負擔增大, 覺得是要慢慢K了.
ex:

代碼:

#ifdef NV3X HALF4 EnvReflect( sampler envmapSampler, sampler normalizeSampler, HALF3 normal, float3 eye, HALF2 fresnelScaleBias ) { HALF3 normEye = texCUBE( normalizeSampler, eye ); HALF fresnel = Fresnel( normal, normEye, fresnelScaleBias ); HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye ); return texCUBE( envmapSampler, reflect ); } #else // NV3X HALF4 EnvReflect( sampler envmapSampler, HALF3 normal, HALF3 eye, HALF2 fresnelScaleBias ) { eye = normalize( eye ); HALF fresnel = Fresnel( normal, eye, fresnelScaleBias ); HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye ); return texCUBE( envmapSampler, reflect ) * fresnel; } #endif

目前看來, for NV3x的那些空跑似乎是頗有問題....

本來NV3x的那部份最後應該也是
return texCUBE( envmapSampler, reflect ) * fresnel
才對.... 不然那fresnel不就變成白算了嗎. ：～
(fresnel有丟到別的地方嗎?)

不過，也不能保證這些丟出來的CODE沒有被有心人士改過啊？
能偷到手，當然也能改他，所以是不是真的，也有待證實吧

__________________
浩子是也

一字曰心~

2003-10-03, 07:00 PM #22

yonoko

*停權中*

加入日期: Mar 2000

您的住址: 竹科之中很操的地方

文章: 2,496

引用:

Originally posted by Artx1
基本上, 這個事件對Valve本身的損失最大, 因為Valve本來是計畫在HL2之後,
販賣這套引擎的, 目前看來是別想賣了....
而且還外加洩漏了一些簽約的工具廠商的資料, 可以想見的是那些公司應該也會來索賠....
Valve現在動用社群的力量開始找兇手, 不過看來是只有亡羊補牢的效果了.

至於程式碼是不是有針對NV3x進行不當的負擔增大, 覺得是要慢慢K了.
ex:

代碼:

#ifdef NV3X HALF4 EnvReflect( sampler envmapSampler, sampler normalizeSampler, HALF3 normal, float3 eye, HALF2 fresnelScaleBias ) { HALF3 normEye = texCUBE( normalizeSampler, eye ); HALF fresnel = Fresnel( normal, normEye, fresnelScaleBias ); HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye ); return texCUBE( envmapSampler, reflect ); } #else // NV3X HALF4 EnvReflect( sampler envmapSampler, HALF3 normal, HALF3 eye, HALF2 fresnelScaleBias ) { eye = normalize( eye ); HALF fresnel = Fresnel( normal, eye, fresnelScaleBias ); HALF3 reflect = CalcReflectionVectorUnnormalized( normal, eye ); return texCUBE( envmapSampler, reflect ) * fresnel; } #endif

目前看來, for NV3x的那些空跑似乎是頗有問題....

本來NV3x的那部份最後應該也是
return texCUBE( envmapSampler, reflect ) * fresnel
才對.... 不然那fresnel不就變成白算了嗎. ：～
(fresnel有丟到別的地方嗎?)

我看到的就是這裡 ...
這裡很可議...
很像讓NV3X空跑...因此效能低落

2003-10-03, 11:21 PM #23

Artx1

Master Member

加入日期: Jun 2002

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

文章: 1,959

引用:

Originally posted by GPF
還好吧...
揭露出NV3X PS 2.0效能不佳的測試程式，也不光是HL2而已。

TR-AOD、ShaderMark、3DMark03....
全部都是一樣的結果，
難道這些程式也都讓NV3x空轉?

有心人士竄改程式碼，想讓所有NV使用者與Valve為敵
也不無可能。

這種想法我覺得稍嫌不太實際.

1. 流出原始碼不比上回id流出alpha版, 這對Valve社運有舉足輕重影響.
發生這種狀況, 現在擔心Valve會不會倒掉大概都不會太誇張.
比如說, 裡面有一些商業開發工具的資料, 這些東西是禁止流出的.
一起被人流出來, Valve八成要賠錢了, 而且是大賠.
不只繪圖資料, 還有些比如AI-module之類的東西, Valve五年來的心血,
都變成類似心不甘情不願的慈善事業般, 做給其他廠商看了.
即使有人說似乎沒有包括成像引擎本體, 光這些Shader Code就夠其他競爭對手或懂門路的人,
立時提升一甲子功力, 這可不是開玩笑的, Valve未來等於會面臨更大的競爭壓力.

2. 對硬體廠商而言同時有利多也有利空.
軟體技術進步需要硬體市場產品配合, 目前看來最大的利空可能是nVIDIA,
因為DX9的產品需求有可能提升, 而NV31/34看來是無法應付DX9的遊戲需求,
而這些流失的版圖, 就是其他廠商的大利多了. (不過也要它們吃得下來)

3. 基本上, Valve官方diff過的話自然會知道有沒有修改過.
雖然沒有官方正式發表(只有提過真假與否, 並且呼籲社群提供援助幫忙追緝駭客),
但是以這回的程式碼行文的高度可讀性, 其實會讓人對Valve有肅然起敬的感覺.
這樣的程式, 要改得不讓人抓出毛病, 十足認定是Valve在搞鬼, 實在需要相當的時間....
以這回Valve官方宣稱的事件過程, 我不認為有這種時間去搞.
何況, 真的有人會信這套?

4. 另一個問題, NV3x到底有沒有那些效能可以擠出來呢?
NV35比起NV30實質上增加了相當多的資源, 但是基本上與R3x0在執行資源上有天壤之別,
一定會比較慢的....
說起來, NV35的best case(4x2~3)僅相當於R3x0(8x1~5!!)的worst case而已.
但是NV35的best case頗容易達到(基本上使用FP16/FP32/FX12都能達到4x2甚至4x3),
相比之下R3x0則比較常處在worst case(各指令必須照某個順序, 並在同一個fetch cycle才能一併讀入,
不然依序讀入只會各自運作, 平行度會浪費掉.... 這算原罪嗎?)

所以基本上NV35 vs R350是有機會拉得非常近的, Driver改善效能並不一定得要放棄畫質.
畢竟NV3x是弱在Shader Performance, 其餘部分仍然有其基本實力.
如果慢得太離譜的話也難說有沒有問題, 比如說單元數少了兩倍, 慢個兩倍合理, 如果慢得只有1/4或更低,
就太誇張了.... HL2的測試就算9600打贏5900其實也沒這個問題, 反倒是Shader Mark的數字慢得很詭異,
有針對過R3x0做最佳化的關係嗎?

何況, 這回HL2流出碼出現針對NV3x的判別式, 換種說法其實也有
"Valve仁至義盡了, NV3x真的快不起來"
的解釋啊?

總之要詳細去判讀才能搞清楚就是了, 現在八成大半的硬體網站人員都在研究這些東西吧.

2003-10-04, 02:50 AM #26

Lii

Senior Member

加入日期: Mar 2000

文章: 1,148

引用:

Originally posted by Artx1
這種想法我覺得稍嫌不太實際.

1. 流出原始碼不比上回id流出alpha版, 這對Valve社運有舉足輕重影響.
發生這種狀況, 現在擔心Valve會不會倒掉大概都不會太誇張.
比如說, 裡面有一些商業開發工具的資料, 這些東西是禁止流出的.
一起被人流出來, Valve八成要賠錢了, 而且是大賠.
不只繪圖資料, 還有些比如AI-module之類的東西, Valve五年來的心血,
都變成類似心不甘情不願的慈善事業般, 做給其他廠商看了.
即使有人說似乎沒有包括成像引擎本體, 光這些Shader Code就夠其他競爭對手或懂門路的人,
立時提升一甲子功力, 這可不是開玩笑的, Valve未來等於會面臨更大的競爭壓力.

2. 對硬體廠商而言同時有利多也有利空.
軟體技術進步需要硬體市場產品配合, 目前看來最大的利空可能是nVIDIA,
因為DX9的產品需求有可能提升, 而NV31/34看來是無法應付DX9的遊戲需求,
而這些流失的版圖, 就是其他廠商的大利多了. (不過也要它們吃得下來)

3. 基本上, Valve官方diff過的話自然會知道有沒有修改過.
雖然沒有官方正式發表(只有提過真假與否, 並且呼籲社群提供援助幫忙追緝駭客),
但是以這回的程式碼行文的高度可讀性, 其實會讓人對Valve有肅然起敬的感覺.
這樣的程式, 要改得不讓人抓出毛病, 十足認定是Valve在搞鬼, 實在需要相當的時間....
以這回Valve官方宣稱的事件過程, 我不認為有這種時間去搞.
何況, 真的有人會信這套?

4. 另一個問題, NV3x到底有沒有那些效能可以擠出來呢?
NV35比起NV30實質上增加了相當多的資源, 但是基本上與R3x0在執行資源上有天壤之別,
一定會比較慢的....
說起來, NV35的best case(4x2~3)僅相當於R3x0(8x1~5!!)的worst case而已.
但是NV35的best case頗容易達到(基本上使用FP16/FP32/FX12都能達到4x2甚至4x3),
相比之下R3x0則比較常處在worst case(各指令必須照某個順序, 並在同一個fetch cycle才能一併讀入,
不然依序讀入只會各自運作, 平行度會浪費掉.... 這算原罪嗎?)

所以基本上NV35 vs R350是有機會拉得非常近的, Driver改善效能並不一定得要放棄畫質.
畢竟NV3x是弱在Shader Performance, 其餘部分仍然有其基本實力.
如果慢得太離譜的話也難說有沒有問題, 比如說單元數少了兩倍, 慢個兩倍合理, 如果慢得只有1/4或更低,
就太誇張了.... HL2的測試就算9600打贏5900其實也沒這個問題, 反倒是Shader Mark的數字慢得很詭異,
有針對過R3x0做最佳化的關係嗎?

何況, 這回HL2流出碼出現針對NV3x的判別式, 換種說法其實也有
"Valve仁至義盡了, NV3x真的快不起來"
的解釋啊?

總之要詳細去判讀才能搞清楚就是了, 現在八成大半的硬體網站人員都在研究這些東西吧.

有道理!
推~

2003-10-04, 06:12 AM #29

GPF

Senior Member

加入日期: Nov 2001

文章: 1,397

引用:

講得落落長...
完全看不太懂你是針對我講的哪點post。

我的post是針對yonoko所說
"HL2 leaked的source很像讓NV3X空跑...因此效能低落"這句話而來。

所以我才舉出"TR-AOD、ShaderMark、3DMark03效能一樣低落"的反証。
總不可能全世界都跟NV為敵，故意讓NV3X空轉吧!

NV3X雖然如你所說，
資源利用度較高，
但是還是一句話，"跑起來慢又有何用?"...

如果資源利用度高才是好的design的話，
那大家回去用486就好了，
不會像P6、K7一樣，實作了好幾條pipeline還有一堆OOE、Dynamic Branch Prediction的機制，
結果還是一堆pipeline以及執行單元是閒置的。

再說R300也不過使用了0.15 um而已，以比NV3X低很多的時脈就可以與之抗衡...
也不需誇張的吹風機等級散熱器，
要比暴力的話，可能還比不過NV3X。

2003-10-04, 07:41 AM #30

GPF Senior Member 加入日期: Nov 2001 文章: 1,397	還好吧... 揭露出NV3X PS 2.0效能不佳的測試程式，也不光是HL2而已。 TR-AOD、ShaderMark、3DMark03.... 全部都是一樣的結果，難道這些程式也都讓NV3x空轉? 有心人士竄改程式碼，想讓所有NV使用者與Valve為敵也不無可能。
2003-10-04, 12:19 AM #24

wufu 停權中加入日期: Jan 2002 文章: 838	程式碼 160 MB, Hoho 真大!!
2003-10-04, 03:01 AM #27

Minos 停權中加入日期: Sep 2002 您的住址: 總部文章: 684	沒看錯的話約7千多個檔案.... 實際瀏覽一遍後....比想像的還糟..... 可以說是應有盡有....還有cs及hl1, tf的東西在裡面... 如這些source code是真的~且ok.... 我同意以上大大的說話.... Valve多年的努力可能會不保...
2003-10-04, 06:00 AM #28