HalfLife2 und Shader3.0 Path? Neue Gerüchte von Fuad... [Archiv]

winter

2004-08-28, 21:59:43

"TheInquirer Gerücht"

Das wichtigste vorweg:
http://www.theinquirer.net/?article=18134

"[...] Last but not the least is believe it or not Half Life 2 that will have support for this Shader model that currently works only at Nvidia cards. [...]"

Ja, es geht da wirklich um Shader3.0...

Mit folgendem Link:
http://www.nvnews.net/vbulletin/showthread.php?t=30736 (*Gelöschter Thread)

Wollte Fuad eine Liste mit TheWayIt'sMeantToBePlayed Games gefunden haben, welche Shader3.0 unterstützen werden.
Der Thread wurde offensichtlich gelöscht und war schon einmal existent. Die Frage ist allerdings, wie aussagekräftig der Inhalt wirklich war.
Immerhin ist diese Aussage von Fuad und damit zu bezweifeln.

Allerdings wäre das ganze eine durchaus positive Entwicklung für aktuelle Nvidia-Nutzer und künftige R520-Käufer. Ob da was dran ist, würde mich schon interessieren. Weiß einer da was genaueres?

P.S.: Ich weiß welche Diskussionen es im Grafikchipforum über das Thema gibt, aber ich finde, dass es hier besser hinpasst als auf Seite8 eines anderen Threads

M@g

2004-08-28, 22:35:49

Auf der Liste waren noch andere Spiele, die Teils schon eine bestätigte SM3 Unterstützung mitbringen.
Lord of the rings: Battle for the middle earth, Stalker: Shadows of Chernobyl, Splinter Cell 3, Tiger Woods 2005, Vampire: Bloodlines, Tiger Woods 2005, Madden 2005, Driver 3.0, Grafan, Medal of Honor: Pacific Assault, Patched Painkiller und patched Far cry.

deekey777

2004-08-29, 11:00:50

Die Aussage von Fuad ist nicht zweifelhaft oder unbegründet, da VALVe dies schon von mehreren Monaten bestätigte (war eine Email eines Fans mit der Frage über SM 3.0). HL2 wird SM 3.0-Support haben - aber nachgeliefert. Darum ist es keine Sensation.

reunion

2004-08-29, 12:13:49

deekey777

2004-08-29, 12:28:35

jap, nachgeliefert wenn ATi Sm3.0 fähige Hardware hat...
Davon ist auch auszugehen.

LovesuckZ

2004-08-29, 13:01:17

Ein SM3.0 Pfad sollte ueberhaupt kein Problem sein, immerhin uebernimmt dies heutzutage ein Compiler.

ironMonkey

2004-08-29, 13:12:59

Ja dann nennt mal die Vorteile davon..........ich mein bei 2.0 gibts ja bei HL² mehr nach wie Vorteile....................

Gruß

LovesuckZ

2004-08-29, 13:16:03

Ja dann nennt mal die Vorteile davon..........ich mein bei 2.0 gibts ja bei HL² mehr nach wie Vorteile....................

Die unterschiedlichen Profile ordnen die Anweisungen jeweils nach den Staerken der Karten an.
Es kann daher passieren, dass ein Shader nach PS2.0 mehr Anweisungen als nach der Bearbeitung mit dem PS2.a Profil hat.
Wenn man wirklich Vorteile durch die erweiteren Shader haben moechte, muss man natuerlich mehr machen.
ber ein einziger Compilerdurchlauf sollte auch bei Valve mit ihren "5 mal solange optimiert" noch drin sein.

Coda

2004-08-29, 13:44:26

Ein SM3.0 Pfad sollte ueberhaupt kein Problem sein, immerhin uebernimmt dies heutzutage ein Compiler.
Jain. Das nützt aber nix, weil man die branches ja trotzdem in den Code einfügen muss, wodurch man es dann nicht mehr für SM2.0 kompilieren kann.
Das einzige was geht, ist das spezielle Instructions von SM3.0 verwendet werden, was aber wohl kaum viel Performance bringt.

micki

2004-08-29, 14:50:30

Jain. Das nützt aber nix, weil man die branches ja trotzdem in den Code einfügen muss, wodurch man es dann nicht mehr für SM2.0 kompilieren kann.
Das einzige was geht, ist das spezielle Instructions von SM3.0 verwendet werden, was aber wohl kaum viel Performance bringt.
es kommt auf den shader an, wenn man z.b. mehrere samples aus einer shadowmap macht um kanten zu verwischen, dann kann man vorher ein paar initialsamples machen anhand derer man prüft ob die nächsten samples überhaupt nötig wären. das kann mittels ps3.0 sehr viel performance bringen (bzw qualität)

es kommt immer auf den shader an

MfG
micki

Coda

2004-08-29, 15:09:05

es kommt auf den shader an, wenn man z.b. mehrere samples aus einer shadowmap macht um kanten zu verwischen, dann kann man vorher ein paar initialsamples machen anhand derer man prüft ob die nächsten samples überhaupt nötig wären. das kann mittels ps3.0 sehr viel performance bringen (bzw qualität)
Das Ding kannst du dann aber nicht mehr als PS2.0 kompilieren.

Einfaches rekompilieren reicht eben nicht, das ist eine falsche Annahme.

r@h

2004-08-29, 19:16:02

Das Ding kannst du dann aber nicht mehr als PS2.0 kompilieren.

Einfaches rekompilieren reicht eben nicht, das ist eine falsche Annahme.Der eigentliche HLSL-Code hat doch fast gar nichts mit dem RenderTarget-Compilat zu tun...

Ein Branch wird halt in seine Bestandteile zerlegt und es werden mehrere Shader erzeugt, wenn das SM2-Target anvisiert ist. Wird dagegen das SM3-Target ausgewählt, wird der originale HLSL-Shader eben nicht zerlegt.

Wo ist das Problem?
:confused:

Umgekehrt ist's schwieriger... denn wenn der Compiler zum Zerlegen der Shader gezwungen wird, hilft ein weiterer Durchlauf mit einem anderen Render-Target nicht, um diese wieder zusammen zu fügen.

Razor

P.S.: letzteres hatten wir gerade in 'nem anderen Thread und ich hoffe, dass ich es so richtig verstanden habe... ;)

Robbitop@work

2004-08-30, 16:59:21

angeblich basiert der R520 auf der R300 Linie und nicht auf der R400/Xenon Linie.
Demirug betonte oft, dass ein SM3 auf der R300 Architektur suboptimal ist.
Wenn das so ist, ist man offenbar mehr auf ein Checklistfeature aus als auf eine sinnvolle SM3 Architektur.
Vermutlich wird erst der R600 (R400 Linie) brauchbares SM3 bieten.
Bei NV wirds was mit dem NV50 etwas (CineFX Design).

Demirug

2004-08-30, 17:08:09

Robbitop, der R520 könnte ja durchaus vom Xenon abgeleitet sein und dieser macht von den Papierspec einen gar nicht mal so schlechten Eindruck.

IVN

2004-08-30, 17:09:57

@Demirug

Can you give me a link to those r520 papers?

Demirug

2004-08-30, 17:17:23

@Demirug

Can you give me a link to those r520 papers?

Ich meinte die Xenon Spec die vor einiger Zeit im Netz zu finden waren. Ob sie stimmen weiss ich natürlich nicht aber sie sahen eben ganz gut aus.

IVN

2004-08-30, 17:26:48

@Demirug

OK :wink:

betasilie

2004-08-30, 17:41:52

angeblich basiert der R520 auf der R300 Linie und nicht auf der R400/Xenon Linie.
Wie kommst Du darauf? ... Einige Leute glaube das, weil der R520 nicht R500 heißt, aber bis jetzt habe ich noch kein "glaubwürdiges" Gerücht gehört, welches deine Vermutung bestätigen würde.

robbitop

2004-08-30, 21:29:12

das sagen meine Quellen.
Aber ob es richtig ist weiss ich nicht.
Natürlich gilt meine Aussage nur, wenn er nicht von Xenon abgeleitet ist.
Xenon gefällt mir vom Design, was ich bisher sah, sehr.

betasilie

2004-08-31, 03:34:48

das sagen meine Quellen.
Aber ob es richtig ist weiss ich nicht.
Natürlich gilt meine Aussage nur, wenn er nicht von Xenon abgeleitet ist.
Xenon gefällt mir vom Design, was ich bisher sah, sehr.
Nun, ich habe zwar z.Zt. keine Insiderinfos, aber imho wird der R520 ein Xenon-Devirat. Alles andere wäre unlogisch und unpassend.

robbitop

2004-08-31, 08:19:35

Nun, ich habe zwar z.Zt. keine Insiderinfos, aber imho wird der R520 ein Xenon-Devirat. Alles andere wäre unlogisch und unpassend.

das sagst du so einfach ... ;)
Aber enttäuschen würde es mich auch, wenn es nicht auf Xenon basiert.

Spake

2004-08-31, 21:45:30

Nun, ich habe zwar z.Zt. keine Insiderinfos, aber imho wird der R520 ein Xenon-Devirat. Alles andere wäre unlogisch und unpassend.
ich bin ganz deiner meinung:
wenn Ati nicht bald mal ihr xenon-design benutzt wirds wirklich alt ;) und da gpu-entwicklung teuer ist kann ich mir nicht vorstellen wieso Ati ein design verwerfen sollen ?!
andererseits ist es imo interressant das Ati ihren neuen chip r520 nennen was wiederrum eine verwandschaft zum r420 andeutet

robbitop

2004-08-31, 22:15:21

Xenon soll wohl eher SM4 sein.
Es besteht aus einem ALU Array.
R520 hingegen ist wohl SM3 also noch getrennt SIMD PS ALUs und MIMD VS ALUs.

Ein Design wird nicht sooo schnell alt. R200 ist die Basis für R3xx/4xx und vermutlich/vieleicht R520.

IVN

2004-09-01, 14:43:41

@robbitop

What for does the 1st m stands in MIMD (instruction multiple data) ??

Coda

2004-09-01, 14:54:53

Wo ist das Problem?
Dass das bei dynamische Branches nicht funktioniert.

Sunrise

2004-09-01, 15:07:35

@robbitop

What for does the 1st m stands in MIMD (instruction multiple data) ??I´m not robbitop (obviously ;)) .. but

SIMD -> Single-Instruction Multiple-Data
MIMD -> Multiple-Instruction Multiple-Data

IVN

2004-09-01, 15:09:29

@Sunrise

Thx,but i knew what SIMD describes.

robbitop

2004-09-01, 15:52:25

danke sunrise, hätte ich nicht besser machen können :D

LovesuckZ

2004-09-01, 21:06:33

R520 hingegen ist wohl SM3 also noch getrennt SIMD PS ALUs und MIMD VS ALUs.

Oh, also nicht wirklich weiter als der NV40?

robbitop

2004-09-01, 21:40:51

das ist eine logische Schlussfolgerung.
wenn es stimmt was die Gerüchte sagen, ist R520 SM3 und nicht SM4.
SM3 ist kein Array. Hier ist Geometrie und Texturierung getrennt.

Die Xenonreihe hingegen soll laut der PPT ein Array sein. Somit wäre das für mich SM4.

Daraus schliesse ich:

-> R520 != Xenon
-> R520 = R300 Reihe
-> SM3 = aufgesetzt (Checklistfeature)

Ob das nun stimmt, ist eine andere Frage ;)

[Allerdings kann man auch einen logischen Array aus physikalisch getrennten Einheiten realisieren. Sprich: SM4 ist auch mit der NV40 Reihe möglich.]

Gast

2004-09-01, 21:49:44

das ist eine logische Schlussfolgerung.
wenn es stimmt was die Gerüchte sagen, ist R520 SM3 und nicht SM4.
SM3 ist kein Array. Hier ist Geometrie und Texturierung getrennt.

Das spielt für die konkrete HW-Implementierung überhaupt keine Rolle. Man kann selbstverständlich auch reines SM3 als HW in "Array-Form" implemetieren.

IVN

2004-09-01, 21:53:21

@robbitop

Don't forget,nv3x=> VSs (3) are one array.

robbitop

2004-09-01, 22:55:33

@IVN

die MIMD VS Units des NV3x sind nur aus PR Gründen mit dem Namen "Array" versehen worden.

Ich meine allerdings einen Array, eine Art Pool aus gemeinsamen ALUs, welche dynamisch für alle möglichen Aufgaben eingeteilt werden können. Ob nun Geometrieberechnung oder Texturberechnungen.

@Gast

Richtig, nur würde es keinen Sinn machen, wenn man schon ein Unified ALU Array designed (die Logik für eine dynamische Aufgabenverteilung ist irre komplex). Sowas tut man für SM4. Das ist sehr sehr nah an SM3.
Es wäre Unsinn das für SM3 zu tun.
AFAIK ist XENON auf SM4 aus. Warum sollte man also einen Xenon Nachfolger/Derivat auf SM3 herrunterdesignen?

Somit wäre für mich R520 != Xenon

IVN

2004-09-01, 22:58:22

What about r400??

It should be SM3.
What if r520=r400 in 110nm is?

robbitop

2004-09-01, 23:03:27

R400 = Xenonreihe

Soweit ich das weiss, ebenfalls ein unified Array.
SM4 sollte hier das Ziel gewesen sein.
Laut Demirug kann man mittels eines Treibers sogar NV40 SM4 fähig machen (logischer Array). R400 soll dem NV40 technologisch sogar vorausgewesen sein.
Aber eben alles Gerüchte.

Ich glaube man würde R400 in der Form nicht mehr bringen. Wenn dann weiterentwickelt, die Anzahl der Ausführungseinheiten erhöhen usw.
Weiterhin wäre ich skeptisch was 110nm betrifft, da es eigentlich ein low cost prozess ist (low cost/mid range).

IVN

2004-09-01, 23:06:56

robbitop

2004-09-01, 23:09:00

yupp
ya got it.

IVN

2004-09-01, 23:13:07

I read those Xenon specs,as i remember it has 48 ALUs and 8 pipes (or 2 quads).2 quads is not much if you have high overdraw and an not so efficient HSR subsystem.

robbitop

2004-09-01, 23:16:41

there was AFAIK nothing about Pipelines.
There are 16 TMUs. AFAIR sorted in another array.
Finally we can stop speaking of "pipelines" :)

IVN

2004-09-01, 23:19:23

Old habits never die . :D

IVN

2004-09-01, 23:25:29

there was AFAIK nothing about Pipelines.

There is something abot that at xbitlabs:
Max. throughputs per cycle:
1 vertex
1 triangle
2 2x2 pixel quads + z/stencil.

2 2x2 should be 2 quad piplines.

robbitop

2004-09-01, 23:33:55

yeah xbitlabs ;)

AFAIK:
There are 16 TMUs in an Array. They could be used in some configurations.
Dunno if they could fetch a trilinear pixel/clock or just a bilinear.
The Framebuffer is linked very wide w/ the Chip (eDRAM connected to the texturecache??), so 16 tri Texel/clock would be possible w/out limitating bandwith so hard.
But thats only rumor.

IVN

2004-09-01, 23:46:14

@robbitop

Those are only bilinear TMUs.

There is a paper with all those specs. I think ,i saw it at an other I-page(also),but i'm not sure. :confused:

robbitop

2004-09-02, 08:23:22

yeah u're right. They were bilinear.

IVN

2004-09-02, 10:25:51

@robbitop

What do you mean "were" ?

If they were bi- then,there is no chance they are tri- now.That is a big change in design,and breaks the transistor count.

robbitop

2004-09-02, 10:41:50

@IVN

nope it was just a missunderstanding because of my broken english ;)
[I can imagine about the difficulty of a redesign for tri TMUs. All the internal data paths/bussystems and texture caches have to be significantly improved for that.]

I meant, that you are right w/ "bi TMUs" and I was wrong about "tri TMUs". I couldn't remember as well as you did.