3D Mark 06 obecna diskusia

[.:::iGor:::.]

Radeon X1900 hits image quality snag in 3DMark06

During the preparation of my Radeon X1900 review, I discovered a problem with Radeon X1900 cards in 3DMark06...

http://www.techreport.com/onearticle.x/9324

[Darth Maul]

Hmm, přes profily zase nic...

[no-X]

Here Nick kindly identified a 3DMk06 shader that uses dynamic branching.

Additionally, sections of the code use partial precision (_PP at the end of the instruction name).

What's interesting, in my view, is:

• clearly this is an optimisation for NVidia hardware - and who knows whether the driver will even respect this and instead just change every instruction to _PP
• the complexity in identifying the portions of shader code that can withstand _PP

To be honest, if you're a half-decent programmer, then an awareness of precision is right there at the time the algorithm is cast and the data structures formed, so I don't think it's actually that difficult to say these "variables are _PP". It's not much different from choosing texture formats, I guess.

I can imagine the lead graphics engine developer will have laid-down the parameters for _PP, too - so the code monkeys can get on without having to think too much.

I suppose where it might get interesting is in artist-configured shaders - but again I imagine the lead dev will have identified the conditions under which precision is at risk.

Arguably, I suppose, it would be nice as a dev to be able to think "FP32 all the way, no need to worry about the precision of my variables" - like when I used to program finance stuff I knew my money fields were always 15.4 and life was simple, I just had to be careful about when I rounded, etc. etc.

Jawed

Although I've not sat through the several hundred pixel shader dumps, the longer ones from the HDR test look something like this:

ps_3_0


def c6 , -0.018729299306869507000000, 0.074261002242565155000000, 1.570728778839111300000000, 10000.000000000000000000000000

def c7 , 0.000000000000000000000000, 1.000000000000000000000000, 0.031250000000000000000000, 0.062500000000000000000000

def c8 , 2.000000000000000000000000, -1.000000000000000000000000, 1.000000000000000000000000, -0.212114393711090090000000

def c9 , 0.416087001562118530000000, -0.303380995988845830000000, 0.135195001959800720000000, 0.220419004559516910000000

def c10 , -0.183682993054389950000000, 0.077253997325897217000000, -0.252817988395690920000000, -0.237764000892639160000000

def c11 , -0.054127000272274017000000, 0.662913024425506590000000, -0.031250000000000000000000, 0.318309873342514040000000

def c12 , -0.486135989427566530000000, 0.397747993469238280000000, -0.397747993469238280000000, 3.000000000000000000000000

def c13 , 0.574523985385894780000000, -0.062500000000000000000000, -0.574523985385894780000000, 0.108253002166748050000000

def c14 , -0.625000000000000000000000, -0.750000000000000000000000, 0.875000000000000000000000, 0.187500000000000000000000

def c15 , 1.000000000000000000000000, 1.001000046730041500000000, -0.797193884849548340000000, 0.014567226171493530000000

def c16 , 0.636619746685028080000000, -1.009999990463256800000000, -1.120000004768371600000000, 0.000100009805464651440000

def c17 , 0.500000000000000000000000, 1.000000000000000000000000, 0.159154936671257020000000, 16.000000000000000000000000

dcl_texcoord0  v0.xy 
dcl_texcoord1  v1.xy 
dcl_texcoord2  v2.xyz 
dcl_texcoord3  v3.xyz 
dcl_texcoord4  v4.xyz 
dcl_texcoord5  v5.xyz 
dcl_texcoord6  v6.xyz 
dcl_texcoord7  v7.xyz 
dcl v4096.xy 
dcl_2d s0 
dcl_2d s1 
dcl_2d s2 
dcl_2d s3 
dcl_2d s4 
dcl_cube s5 
dcl_cube s6 
texld r0 , v0.xyxx , s3 
mad_pp r1.xyz , c8.xxxx , r0.wyzw , c8.yyyy
nrm_pp r2.xyz , v2 
dp3_pp r4.x , r1 , v3 
dp3_pp r4.y , r1 , v4 
dp3_pp r4.z , r1 , v5 
dp3_pp r0.x , r2 , v3 
dp3_pp r0.y , r2 , v4 
dp3_pp r0.z , r2 , v5 
dp3_pp r0.w , -r0 , r4 
add_pp r0.w , r0.wwww , r0.wwww 
dp3_sat_pp r2.w , r1 , r2 
mad_pp r0.xyz , r4 , -r0.wwww , -r0 
texld_pp r1 , r0 , s6 
mad_pp r0.w , r2.wwww , c6.xxxx , c6.yyyy 
add_pp r0.z , -r2.wwww , c8.zzzz 
mad_pp r0.w , r0.wwww , r2.wwww , c8.wwww 
rsq_pp r0.z , r0.zzzz 
mad_pp r0.w , r0.wwww , r2.wwww , c6.zzzz 
rcp_pp r0.z , r0.zzzz 
mul_pp r0.w , r0.wwww , r0.zzzz 
mad r0.xy , r0.wwww , c16.xxxx , c16.yzzw 
mul r0.xy , r0 , r0 
rcp r0.x , r0.xxxx 
rcp r0.y , r0.yyyy 
add r0.w , -r0.xxxx , c6.wwww 
mul r1.w , r0.wwww , c16.wwww 
add r2.w , r0.yyyy , c15.zzzz 
texld r0 , v0.xyxx , s2 
mov r6.z , c4.xxxx 
add r2.z , -r6.zzzz , c5.xxxx 
mad r2.w , r2.wwww , -c15.wwww , c15.xxxx 
mad_pp r5.w , r0.wwww , r2.zzzz , c4.xxxx 
mul_pp r3 , r0.xyzz , c3.xyzz 
mul_pp r2.z , r5.wwww , r5.wwww 
add_pp r0 , r3 , c8.yyyy 
mad_pp r4.w , r5.wwww , -r2.zzzz , c8.zzzz 
mad r2 , r2.wwww , r0 , c8.zzzz 
add_pp r0.xy , -r4.wwww , c15 
mad_sat_pp r1.w , r0.yyyy , r1.wwww , r0.xxxx 
add_pp r5.w , -r5.wwww , c8.zzzz 
texld_pp r0 , r4 , s5 
mul_pp r0 , r3 , r0.xyzz 
mul_pp r1 , r1.xyzz , r1.wwww 
mul_pp r0 , r5.wwww , r0 
mul r2 , r2 , r1 
mul_pp r0 , r4.wwww , r0
texld r1 , v1.xyxx , s4 
mul r2 , r2 , r1.wwww 
mad_pp r0 , r0 , r1.xxxx , r2 

cmp r2.w , -v6.zzzz , c7.xxxx , c7.yyyy 
mul r1.xy , v4096 , c7.zzzz 
texld_pp r1 , r1 , s1
if_ne r2 , -r2.wwww    ******* NOTE ******
dsx r2 , v7.xyxy 
dsy r3 , v7.xyxy 
add r2 , abs r2 , abs r3 
mov r3.w , c2.xxxx 
mad_pp r2 , r2 , r3.wwww , c1.xyxy 
mul_pp r4 , r1.zwxy , r2 
mad r2 , r4 , c14.zzww , v7.xyxy 
texldl r1 , r2.xyxy , s0 
texldl r5 , r2.zwzw , s0 
mad r2 , r4.zwzw , c17.xxyy , v7.xyxy 
texldl r3 , r2.xyxy , s0 
texldl r2 , r2.zwzw , s0 
mov r1.y , r5.xxxx 
mov r1.z , r3.xxxx 
mov r1.w , r2.xxxx 
mul_pp r2 , r4 , c9.xxyy
add r1 , r1 , -v7.zzzz 
mad_pp r2 , r4.zwxy , c9.zzww , r2 
cmp_pp r1 , r1 , c7.yyyy , c7.xxxx
add r3 , r2 , v7.xyxy 
texldl r2 , r3.xyxy , s0 
texldl r5 , r3.zwzw , s0 
mul_pp r3 , r4 , c10.xxyy 
mad_pp r3 , r4.zwxy , c10.zzww , r3
mov r2.y , r5.xxxx 
add r3 , r3 , v7.xyxy 
texldl r5 , r3.xyxy , s0 
texldl r3 , r3.zwzw , s0 
mov r2.z , r5.xxxx 
mov r2.w , r3.xxxx 
add r3 , r2 , -v7.zzzz 
mul_pp r2 , r4 , c11.xxyy 
cmp_pp r3 , r3 , c7.yyyy , c7.xxxx 
mad_pp r2 , r4.zwxy , c11.zzyy , r2 
dp4_pp r6.w , r3 , c7.wwww 
add r2 , r2 , v7.xyxy 
texldl r3 , r2.xyxy , s0 
texldl r5 , r2.zwzw , s0 
mul_pp r2 , r4 , c12.xxyy 
mad_pp r2 , r4.zwxy , c12.xxzz , r2 
mov r3.y , r5.xxxx 
add r5 , r2 , v7.xyxy 
texldl r2 , r5.xyxy , s0 
texldl r5 , r5.zwzw , s0 
mov r3.z , r2.xxxx 
mul_pp r2 , r4 , c13.xxyy  
mov r3.w , r5.xxxx 
mad_pp r2 , r4.zwxy , c13.zzww , r2  
add r3 , r3 , -v7.zzzz 
add r5 , r2 , v7.xyxy 
texldl r2 , r5.xyxy , s0 
texldl r5 , r5.zwzw , s0 
mov r2.y , r5.xxxx 
mad r4 , r4 , c14.xxyy , v7.xyxy 
texldl r5 , r4.xyxy , s0 
texldl r4 , r4.zwzw , s0 
mov r2.z , r5.xxxx 
mov r2.w , r4.xxxx 
cmp_pp r3 , r3 , c7.yyyy , c7.xxxx 
add r2 , r2 , -v7.zzzz 
dp4 r3.w , r3 , c7.wwww 
cmp_pp r2 , r2 , c7.yyyy , c7.xxxx 
add_pp r3.w , r6.wwww , r3.wwww 
dp4 r2.w , r2 , c7.wwww 
dp4 r1.z , r1 , c7.wwww 
add_pp r1.w , r3.wwww , r2.wwww 
add_pp r6.w , r1.zzzz , r1.wwww 
texld r1 , v0.xyxx , s3 
mad_pp r1.xyz , c8.xxxx , r1.wyzw , c8.yyyy 
nrm_pp r5.xyz , v6 
dp3_sat_pp r5.w , r1 , r5 
nrm_pp r2.xyz , v2 
add_pp r2.w , -r5.wwww , c8.zzzz 
mad_pp r1.w , r5.wwww , c6.xxxx , c6.yyyy 
rsq_pp r2.w , r2.wwww 
mad_pp r1.w , r1.wwww , r5.wwww , c8.wwww 
rcp_pp r2.w , r2.wwww 
mad_pp r1.w , r1.wwww , r5.wwww , c6.zzzz 
add_pp r4.xyz , r5 , r2 
mul_pp r1.w , r2.wwww , r1.wwww 
nrm_pp r3.xyz , r4 
mad r4.xy , r1.wwww , c16.xxxx , c16.zyzw 
dp3_sat_pp r4.z , r1 , r3 
mul r3.xy , r4 , r4 
dp3_sat_pp r1.y , r1 , r2  
rcp r2.x , r3.xxxx 
rcp r2.y , r3.yyyy 
mad_pp r1.w , r1.yyyy , c6.xxxx , c6.yyyy 
add_pp r1.z , -r1.yyyy , c8.zzzz 
mad_pp r1.w , r1.wwww , r1.yyyy , c8.wwww 
rsq_pp r1.z , r1.zzzz 
mad_pp r1.w , r1.wwww , r1.yyyy , c6.zzzz 
rcp_pp r1.y , r1.zzzz  
add r1.z , r2.xxxx , c15.zzzz 
mul_pp r1.w , r1.wwww , r1.yyyy 
mul r1.z , r1.zzzz , c15.wwww 
mad r1.xy , r1.wwww , c16.xxxx , c16.yzzw 
add r1.w , -r2.yyyy , c6.wwww 
mul r1.xy , r1 , r1 
mul r1.w , r1.zzzz , r1.wwww 
rcp r1.x , r1.xxxx 
rcp r1.y , r1.yyyy 
mul r1.z , r1.wwww , c16.wwww 
add r1.w , -r1.xxxx , c6.wwww 
mul r1.w , r1.zzzz , r1.wwww 
add r1.z , -r6.zzzz , c5.xxxx 
texld r3 , v0.xyxx , s2 
mad_pp r4.w , r3.wwww , r1.zzzz , c4.xxxx  
mul r3.w , r1.wwww , c16.wwww 
add_pp r6.z , -r4.wwww , c8.zzzz  
add r1.z , r1.yyyy , c15.zzzz 
rcp_pp r1.w , r6.zzzz 
mad r6.y , r1.zzzz , -c15.wwww , c15.xxxx 
mul_pp r1.w , r1.wwww , c12.wwww 
pow r2.z , r4.zzzz , r1.wwww 
add r2.w , r1.wwww , c8.zzzz 
mul_pp r1 , r6.wwww , c0.xyzz 
mul r2.w , r2.zzzz , r2.wwww 
mul_sat r2.w , r2.wwww , c17.zzzz 
mul_pp r4.z , r4.wwww , r4.wwww 
mul r2 , r1 , r2.wwww 
mad_pp r6.w , r4.wwww , -r4.zzzz , c8.zzzz 
add_pp r5.xy , -r6.wwww , c15 
mul_pp r4 , r3.xyzz , c3.xyzz 
mad_sat r5.y , r5.yyyy , r3.wwww , r5.xxxx 
add_pp r3 , r4 , c8.yyyy  
mul r2 , r2 , r5.yyyy 
mad r3 , r6.yyyy , r3 , c8.zzzz 
mul_sat_pp r5.z , r5.zzzz , c17.wwww 
mul r3 , r2 , r3 
texld r2 , v1.xyxx , s4 
mul_pp r1 , r1 , r4 
mul_pp r1 , r6.zzzz , r1 
mul_pp r1 , r6.wwww , r1 
mul r3 , r3 , r2.wwww 
mul_pp r1 , r1 , c11.wwww 
mul_pp r2.w , r5.wwww , r5.zzzz 
mad_pp r1 , r1 , r2.xxxx , r3 
mad oC0 , r1 , r2.wwww , r0 
else
mov oC0 , r0 
endif

There are a few like this in the HDR tests.

řádky kódu s _PP jse pro názornost vyznačil červeně

[Haste]

Tomuto pristupu Futuremarku se ale neda nic vytknout. "Partial Precison"... neboli instrukce s modifikatorem "_pp" neboli 24/16 u SM2.0 a 32+/16 u SM3.0 je zcela standardni featurka DX9 skrz SM2.0,a,b,3.0. To ze se na ni v ATi vyprdli stejne jako na VertexTextureFetch je ciste jejich problem. Futuremark proste napsal spravny a OPTIMALNI kod podle DX9.0c specifikaci. Z pohledu benchmarku naprosto korektni pristup. Ac to rikam nerad, tak tady se da neco vycitat pouze ATi...

[no-X]

Tomuto pristupu Futuremarku se ale neda nic vytknout. "Partial Precison"... neboli instrukce s modifikatorem "_pp" neboli 24/16 u SM2.0 a 32+/16 u SM3.0 je zcela standardni featurka DX9 skrz SM2.0,a,b,3.0. To ze se na ni v ATi vyprdli stejne jako na VertexTextureFetch je ciste jejich problem. Futuremark proste napsal spravny a OPTIMALNI kod podle DX9.0c specifikaci. Z pohledu benchmarku naprosto korektni pristup. Ac to rikam nerad, tak tady se da neco vycitat pouze ATi...

Vážně? Futuremark tvrdí, že 3DMark má simulovat nároky budoucích her...

Proč tedy používá PP, když vývojáři her se s jeho implementací párali pouze kvůli shaderům GeForce FX a poslední hra, která PP výrazněji používá je FarCry. Od té doby nic. Co tedy 3DMark 06 řekne o nárocích budoucích her, když už ani současné PP téměř nepoužívají? SM4.0 podle současných informací ani PP podporovat nebude, takže směr vývoje je myslím zřejmý. Futuremark přesto PP implementoval a obzvlášť v shaderech používajích dynamic branching. Proč asi Futuremark implementoval PP v shaderech používajících dynamic branching?

Jak tu už jednou padlo, Futuremark pro stíny používá nestandardní D24X8 formát a nutí karty, které jej nepodporují - R520 - (upozorňuji, že D24X8 není třeba pro kompatibilitu s DX9/SM3.0) používat 32bit formát. Proč Futuremark nVidii servíruje pro shadery FP16 až pod nos, zatímco ATi nutí používat pro shadow-mapy 32bitovou texturu?! Pokud Futuremark ustoupil jednomu výrobci, čekal bych, že ustoupí i druhému. Ale ono ne, jednomu se pomůže, druhému se zavaří...

[Haste]

Mel bys to zkusit brat z jineho pohledu. Z pohledu Futuremarku. Chci napsat co NEJOPTIMALNEJSI DX9.0c shader daneho materialu. Nejoptimalnejsi proto, ze jde o benchmark. Jim je jedno jestli je to NV nebo ATi, oni berou matematicky optimalni model pro API DX9.0c a vyuzivaji to co poskytuje. To je zaklad DX9 benchmarku. Pokud se ti jejich matematicky model nasvetleni/zvolenych render targetu zda z nejakeho duvodu spatny(jako napr. degradace kvality ci naopak zbytecne velka precison atd) potom to rozebirejme z tohoto hlediska, ale ne z pohledu typu "tento model materialu/nasvetleni jde lip na jednom HW a hur na jinem".

Pochop, ze nejde jenom o ATi/NV. TO je benchmark APIcka a to jak vsemozny HW podporujici toto API zvlada co nejoptimalnej napsany shader pro API....rozumime ? pro API a ne pro dany HW !

[no-X]

Tak v tomhle s tebou právě nesouhlasím. Pokud jde o benchmark API, proč používá technologie, které API nevyžaduje

[Haste]

Tak v tomhle s tebou právě nesouhlasím. Pokud jde o benchmark API, proč používá technologie, které API nevyžaduje

Prave proto ze je to benchmark a ten ma tyhle veci testovati
Tot jest muj nazor, a verim, ze spravny. Na to abych se s tebou hadal(verejne ) si te prilis vazim, takze timto debatu tady radsi ukoncuju...

[no-X]

Prave proto ze je to benchmark a ten ma tyhle veci testovati
Tot jest muj nazor, a verim, ze spravny.

Nebudu posuzovat, jestli je správný nebo ne, ale určitě mi připadá zvláštní

Na to abych se s tebou hadal(verejne ) si te prilis vazim, takze timto debatu tady radsi ukoncuju...

Dobře, jak myslíš

[iPoK]

je nekde nejake videjko at se mi chudaci muzem juknout jak to vlastne vypada?

Tak som vytvoril vlastne videeka, priamo pomocou ulozenia vsetkych frameov do *.bmp, potom som ich spojil do raw avi (uncompressed) a nasledne som to komprimoval do H.264 na tri prechody. Fps som zvolil 30. Vytvoril som dve verzie: low a high. Low - bitrate 1536kbit/s, High - bitrate 3584kbit/s. Low by mala ist vacsine z Vas, High odporucam iba ak mate nejaku technologiu na akceleraciu H.264, alebo athlona aspon na 2.2GHz, mne uz trhala (i P4 3000MHz).

Nastavenia kvality:


Dal by som aj 1280*1024, ale mam iba 128MB video ram, takze to nejde

Return to Proxycon - low (19MB)
Return to Proxycon - high (44.3MB)

Firefly forrest - low (11.4MB)
Firefly forrest - high (26.5MB)


Testy Canyon Flight a Deep freeze, sa v tychto chvilach renderuju a nebudu mat FSAA, lebo moja karta nepodporuje FSAA a HDR zaroven.

[ace960]

iPoK: nadherna pracicka, takto plynule to v takej kvalite v reale asi nejde dnes nikomu, tesim sa na ostatne

==
edit: video mi ide plynule na A64 3200+ @ 2700 MHz, utilizacia 80-100%, bezi mi to cez bsplayer a to mi gspot pise, ze mi to nepojde lebo, ze namam codec

[MadCap]

mno nice, ale nechapem jakou fekal cestou si to vyrabal ked to nie je akcelerovane pure video decoderom ... dokonca mi to prehrava nejaky nero shit a nechce sa nechat donutit na nic ine ... pritom ine h.264 videa su bezne akcelerovane a v pohode ich prehram ...
EDIT:
ace-ovi to zjavne tie neakceleruje grafika, je to nejak divne urobene (ja mam o dost slabsi cpu takze nestihacky, aj ked vacsie a narocnejsie videa so zvukom davam v pohode cez purevideo)
EDIT2:
stahovat veci s rapidshare.de vedia aj opice ... nerieste to prosim TU!

[iPoK]

mno nice, ale nechapem jakou fekal cestou si to vyrabal ked to nie je akcelerovane pure video decoderom ... pritom ine h.264 videa su bezne akcelerovane a v pohode ich prehram ...

Fuu, to mi je luto, robil som to nejakym "h.264 v281.exe" z 07.2005, vcera som skusal robit cez FDD 20051129 (nie je tam multipass, vie niekto ako to zapnut?) a ide mi to plynulo aj pri 4096kbit/s 1280x1024, takze to budem asik prerabat, majte strpenie. Ale mohol by sa niekto pripojit a spravit nejaky test. Vstupne data maju cca 9GB, potom z nich sa urobi 9GB avi, takze na jeden test je treba tak 20GB volneho miesta.
BTW ako zistim, ze purevideo akceleruje. Pustil som tie videa cez MPC aj cez PureVideo, ale zatazenie CPU bolo rovnake!!

[THX]

Vážně? Futuremark tvrdí, že 3DMark má simulovat nároky budoucích her...

Ma, teda sa ma snazit. Nikto nemoze povedat so 100% istotou co bude v buducnosti. Je sice velmi nepravdepodobne, ale kto vie, co ak niekto vyda hru, ktora bude obsahovat PP, prave koli ohladu na majitelov rady FX?
A dalsia vec, 3dm06 je D3D benchmark, takze nemoze simulovat presne naroky OpenGL hier, aj ked sa da povedat, ze openGL je v podstate iba ine "rozhranie" pre pristup k tym istym HW funkciam karty, je tam predsa len oproti D3D rozdiel a myslim nezanedbatelny.

Teda podla teba je chybou futuremarku ze urobily optimalny kod? Ved ATi pohorsit nemohli, ak nepodporuje partial, tak ci tak by si to pocitala vo full precision. Mal teda futuremark urobit kod bez PP? Potom by sa to dalo napadnut, ze to nevyuziva vsetky moznosti niektorych kariet, ktore ine hry (napr. FC) vyuzivaju..... atd.

(Ad. ze ATi musi D24x8, ale ber to tak ze aj nvidia sice podporuje S3m (alebo jak sa vola ta super fuadom doneba pred cca rokom vychvalovana kompesia ati) ale tusim iba driverovo a musi si to prekladat do nejakeho ineho formatu)

A ze sa jednej firme prilepsi a inej nie... no neviem, doom3 da sa povedat ze je pisany na nvidia, resp. carmack uz vopred vravel, ze bude chciet mat zrychlenu pracu so z bufferom (hmm, alebo s niecim inym... proste to co maju nvidie 2x rops (hmm, tusim rops, fakt si to uz nepamatam) ak sa pracuje s pixelmi bez farieb, alebo skratka take nieco), co bolo implementovane priamo v HW. Ale co take ATi, ktore pekne zaplatilo Valve, ze potom HL2 isiel na FX kartach velmi zle, ale sa urobila finta (no teraz si uz zase nepamatam presne ako sa volal ten program, musel by som to dohladat) ze pomocou nejakeho programu sa urobilo to, ze FX karta sa pre system javila ako radeon, tak potom na tej istej FX karte s rovnakymi nastaveniami to islo lepsie (a o dost lepsie)....

Takze asi tak. Nebudem sa tu zaoberat marketingovymi kecami ATi a nv ale v tomto mi ATi pripada omnoho horsie (staci si pozriet ich reklamne PR z pred roka, alebo aj viac, kde kritizuju velkost a spotrebu nvidia kariet a teraz zrazu ked oni maju take iste velke karty s este vyssou spotrebou su ticho....)

[LosDatlos]

No uvidíme kolik sežere nová řada nVidie se svými 32pip ....

A myslím si, že když nová hra nebude stíhat staršímu hw, lze ji přeci renderovat pomocí DX7 či DX 8.1, viz např CoD2, tak proč by se měl někdo párat _pp ? Věřím že je lepší vidět jen "něco" a zahrát si plynule, než pak vidět sice vše a nervovat se u slideshow.

A o těch fintách bych raději pomlčel, když vyšel full FEAR, stačilo jen .exe soubor přejmenovat na např. FEA.exe a rázem to šlapalo na ATi kartách o 20-30% lépe..

[Masster]

A o těch fintách bych raději pomlčel, když vyšel full FEAR, stačilo jen .exe soubor přejmenovat na např. FEA.exe a rázem to šlapalo na ATi kartách o 20-30% lépe..

Ehm, ale to byla chyba ATI

[no-X]

Ma, teda sa ma snazit. Nikto nemoze povedat so 100% istotou co bude v buducnosti. Je sice velmi nepravdepodobne, ale kto vie, co ak niekto vyda hru, ktora bude obsahovat PP, prave koli ohladu na majitelov rady FX?

V tomle si jsem jistý 100%, nadcházející DX _pp vůbec umožňovat nebude. Vývojáři nepoužívali _pp pro FX kvůli tomu, aby na ní hry běhaly lépe, ale kvůli tomu, že s _fp na ní neběhaly prakticky vůbec a nelze vydat hru, kterou si polovina lidí nezahraje. Stručně řečeno pokud vývojáři skutečně nemusí, tak neoptimalizují a očekávat jakoukoli podporu GF-FX v dnešní době je hodně naivní.

Krom toho nechápu tvůj styl myšlení - výslovně jsem uváděl, že _pp v 3DM06 je použita v 3.0 shaderech s dynamic branchingem. Jakou souvislost s tím má GeForce FX?

A dalsia vec, 3dm06 je D3D benchmark, takze nemoze simulovat presne naroky OpenGL hier, aj ked sa da povedat, ze openGL je v podstate iba ine "rozhranie" pre pristup k tym istym HW funkciam karty, je tam predsa len oproti D3D rozdiel a myslim nezanedbatelny.

Co má 3dmark společného s opengl hrama? Tvoje tvrzení ("openGL je v podstate iba ine "rozhranie" pre pristup k tym istym HW funkciam karty, je tam predsa len oproti D3D rozdiel a myslim nezanedbatelny") není pravdivé. Pokud bys měl zájem o diskuzi na toto téma, můžeme pokračovat v jiné sekci.

Teda podla teba je chybou futuremarku ze urobily optimalny kod? Ved ATi pohorsit nemohli, ak nepodporuje partial, tak ci tak by si to pocitala vo full precision. Mal teda futuremark urobit kod bez PP?

Ano. Futuremark prohlašuje, že 3DM06 simuluje nároky budoucích her. Už současné hry a mnohé starší _pp nepoužívají. Je to jako kdybys čekal, že ještě nějaký vývojář v budoucnu bude optimalizovat kód pro register combiner, truform, nebo podobné "mrtvé" technologie.

Potom by sa to dalo napadnut, ze to nevyuziva vsetky moznosti niektorych kariet, ktore ine hry (napr. FC) vyuzivaju..... atd.

FarCry je relativně stará hra, která byla vyvíjená v době GF-FX a už tak patřila k posledním svého typu. Jejím ekvivalentem byl 3Dmark 2003. Dnes jsme ale o tři roky dál. Odkdy bere Futuremark ohledy na 3 roky staré technologie, hry a hardware?

(Ad. ze ATi musi D24x8, ale ber to tak ze aj nvidia sice podporuje S3m (alebo jak sa vola ta super fuadom doneba pred cca rokom vychvalovana kompesia ati) ale tusim iba driverovo a musi si to prekladat do nejakeho ineho formatu)

Tady jaksi nechápu, o čem mluvíš, mícháš tu hrušky a jabka. Nevím proč dáváš do souvislosti D24X8 a SM3.0. D24X8 ve specifikacích SM3.0 není. Tento formát není povinný pro DX9.0c; jeho použití je další záhadou. Kdybych to vzal z druhého hlediska, mohl Futuremark použít 3Dc kompresi, kterou podporouje pouze ATi; grafické karty nVidie by měly ve 3Dmarku silně zvýšené nároky na grafickou paměť a sběrnici a bylo by to stejně "korektní", protože 3Dc, stejně jako D24X8 nejsou nutné pro splnění požadavků SM3.0. A věř mi, že komprese normálových map se bude v budoucnu používat rozhodně častějim než partial precision

A ze sa jednej firme prilepsi a inej nie... no neviem, doom3 da sa povedat ze je pisany na nvidia, resp. carmack uz vopred vravel, ze bude chciet mat zrychlenu pracu so z bufferom (hmm, alebo s niecim inym... proste to co maju nvidie 2x rops (hmm, tusim rops, fakt si to uz nepamatam) ak sa pracuje s pixelmi bez farieb, alebo skratka take nieco), co bolo implementovane priamo v HW.

Doom 3 byla myslím poslední hra využívající nvidia register combiner, takže na GF-FX běžel pouze přes fixed-function pipeline; PS ALUs vábec nepoužíval, proto byly jeho výsledky na FX docela akceptovatelné. Na GF6/7 šlo o trochu jinou věc - konkrétně o dual-issue ROPs v kombinaci s mini-ALUs. Doom 3 není dobrý příklad pro ukázku vývoje budoucích her; stencil shadows jsou mrtvé (viz. X2->X3, morrowind->oblivion atp.)

Ale co take ATi, ktore pekne zaplatilo Valve, ze potom HL2 isiel na FX kartach velmi zle, ale sa urobila finta (no teraz si uz zase nepamatam presne ako sa volal ten program, musel by som to dohladat) ze pomocou nejakeho programu sa urobilo to, ze FX karta sa pre system javila ako radeon, tak potom na tej istej FX karte s rovnakymi nastaveniami to islo lepsie (a o dost lepsie)....

HalfLife2 byl především optimalizovaný pro SM2.0, tzn. FP24. nVidia (GF-FX) FP24 nepodporovala, a proto musela běžet v FP32. Jenže za to si mohla sama, FP24 byl požadavek DX9.0 a všichni výrobci (ATi, S3, XGI) ho dokázali dodržet, pouze nVidia ne.

Takze asi tak. Nebudem sa tu zaoberat marketingovymi kecami ATi a nv ale v tomto mi ATi pripada omnoho horsie (staci si pozriet ich reklamne PR z pred roka, alebo aj viac, kde kritizuju velkost a spotrebu nvidia kariet a teraz zrazu ked oni maju take iste velke karty s este vyssou spotrebou su ticho....)

Nevím, proč to sem taháš. Nejdřív píšeš, že to nebudeš rozebírat, pak to stejně rozebíráš. Jestli máš ještě ty PR slajdy ATI schované, tak si je přečti znovu. ATi kritizovala, že nVidia má při vyšší spotřebě nižší výkon. FX5800Ultra vs. R9700PRO, GF6800Ultra vs. X800XT-PE... Současná situace je taková, že spotřeba srovnatelně výkonných konkurujících si kartet vychází líp pro ATi (X1800XL vs. 7800GT, X1600XT vs. 6600GT). X1900XTX žere víc než 7800GTX512? Ano, spotřebu má vyšší o 7%, jenže výkon v průměru o 15% a cenu minimálně o 5000 nižší. Spočítej si, jak dlouho by ti musel běžet 20ti W spotřebič, aby ti to dalo 5000Kč na složence za elektřinu

[THX]

Jenže za to si mohla sama, P24 byl požadavek DX9.0 a všichni výrobci (ATi, S3, XGI) ho dokázali dodržet, pouze nVidia ne.

ATi kritizovala, že nVidia má při vyšší spotřebě nižší výkon. FX5800Ultra vs. R9700PRO, GF6800Ultra vs. X800XT-PE... Současná situace je taková, že spotřeba srovnatelně výkonných konkurujících si kartet vychází líp pro ATi (X1800XL vs. 7800GT, X1600XT vs. 6600GT). X1900XTX žere víc než 7800GTX512? Ano, spotřebu má vyšší o 7%, jenže výkon v průměru o 15% a cenu minimálně o 5000 nižší. Spočítej si, jak dlouho by ti musel běžet 20ti W spotřebič, aby ti to dalo 5000Kč na složence za elektřinu

Ale nvidia predsa dodrzala poziadavku dx9, sice nie P24, ale P32, ale poziadavok to splnilo.

Kym nevysla X1900 a x1800, tak to neplatilo, ked vyjde 7900, znova sa to moze menit...

Dalsia vec, ak si nvidia zaplatila futuremark aby pre nu optimalizoval, tak potom predpokladam ze zaplati aj ostatne firmy aby pre nu optimalizovali a teda nakoniec 3dmark vdaka tomuto bude benchmarkovat vykon buducich hier

No a potom myslim ze nikde nie je napisane ze 3dmark sa snazi benchmarkovat vykon vsetkych buducich hier, to je samozrejma nemozne, ved 3dmark03, 05 aj 01 tiez odhadovali vyvoj buducich hier ale kym ta buducnost prisla, tak uz tie ich odhady boli celkom nepresne. Ten odhad vykonu plati max tak na 2-3 roky (povedal by som ze menej...)

[no-X]

Ale nvidia predsa dodrzala poziadavku dx9, sice nie P24, ale P32, ale poziadavok to splnilo.

Požadavek to splnilo, ale použitelnost byla nulová. Což ostatně není nic nového.

[ace960]

Testy Canyon Flight a Deep freeze, sa v tychto chvilach renderuju a nebudu mat FSAA, lebo moja karta nepodporuje FSAA a HDR zaroven.

Bude, nebude? Nove PC kvoli 3dm06 kupovat nebudem ale video by som si rad pozrel Moze byt aj neakcelerovane cez gpu, na jedno dve pozretie staci.

[Semik]

Shader Particles (SM 3.0) Not Supported

Preco ze to ATI RADEON X1900 XTX nepodporuje nechapem...

[Haste]

Preco ze to ATI RADEON X1900 XTX nepodporuje nechapem...

Uz jsem tu o tom psal nekolikrat. Zadny z Radeonu nepodporuje VertexTextureFetch a kdybys cetl WhitePapers k 3DM06, tak bys vedel, ze tento test vyuziva onu featurku z DX9.0c ...

[iPoK]

Dal som si znova tu namahu (nakolko mi od minula ostali RAW avi-cka) a vytvoril som videeka z testov z 3DMark06. Su v max. kvalite, aku moj system este zvlada, XviD 3600 kb/s.
Ak by ste nemohli stahovat kôli "slot-limitu", pouzite tuto adresu: http://www.anonycat.com (na stranke sa ale pise, ze 29.4 a 30.4 nebude stranka funkcna!)

Firefly Forrest - 26.7MB
http://www.megaupload.com/?d=K2ZMEPSC

Deep Freeze - 29.4MB
http://www.megaupload.com/?d=R70NAQUU

Canyon Flight - 34.9MB
http://www.megaupload.com/?d=I1NOHIHW

Return To Proxycon som uz nerobil, ale najdete ho na predchadzajucej stranke.