PCDVD數位科技討論區
第3頁 共4頁 上一頁 1 2 3 4 下一頁
每頁顯示此主題的 10 個文章

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   顯示卡討論區 (https://www.pcdvd.com.tw/forumdisplay.php?f=8)
-   -   Half-Life 2 出問題啦!!! (https://www.pcdvd.com.tw/showthread.php?t=253765)

Artx1 2003-10-03 06:54 PM
基本上, 這個事件對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有丟到別的地方嗎?)

mokap 2003-10-03 07:00 PM
引用:
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沒有被有心人士改過啊？
能偷到手，當然也能改他，所以是不是真的，也有待證實吧

yonoko 2003-10-03 11:21 PM
引用:
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空跑...因此效能低落:jolin:

GPF 2003-10-04 12:19 AM
還好吧...
揭露出NV3X PS 2.0效能不佳的測試程式，也不光是HL2而已。

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

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

Ghost Lee 2003-10-04 01:20 AM
引用:
Originally posted by GPF
還好吧...
揭露出NV3X PS 2.0效能不佳的測試程式，也不光是HL2而已。

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

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

陰謀論?!:confused::confused:

Artx1 2003-10-04 02:50 AM
引用:
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真的快不起來"
的解釋啊?

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

wufu 2003-10-04 03:01 AM
程式碼 160 MB, Hoho 真大!!

Minos 2003-10-04 06:00 AM
沒看錯的話約7千多個檔案....
實際瀏覽一遍後....比想像的還糟.....
可以說是應有盡有....還有cs及hl1, tf的東西在裡面...
如這些source code是真的~且ok....
我同意以上大大的說話....
Valve多年的努力可能會不保...

Lii 2003-10-04 06:12 AM
引用:
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真的快不起來"
的解釋啊?

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


有道理!
推~

GPF 2003-10-04 07:41 AM
引用:
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真的快不起來"
的解釋啊?

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

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

我的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。:D


所有的時間均為GMT +8。 現在的時間是09:39 PM.
第3頁 共4頁 上一頁 1 2 3 4 下一頁
每頁顯示此主題的 10 個文章

vBulletin Version 3.0.1
powered_by_vbulletin 2025。