GDC Folien von ATI

[Demirug]

ATI hat die Folien zu den Vorträgen auf der GDC online gestellt.

http://www.ati.com/developer/techpapers.html

Da es diesesmal PDFs sind fehlen die Sprechernotizen.

Interesant ist IMHO denoch folgendes:

- Auch ATI warnt vor der sorglosen Verwendung von Dynamic Branching.
- Sie gestehen ein das es Dinge gibt die man nur mit 2.A und 3.0 machen kann.
- Es gibt einen netten Vergleich bezüglich der "doppelten Z-Leistung" auf ATI und nVidia Hardware. Das ganze allerdings mit einem schönen Trick von Seiten ATIs.

[agffwfw]

Sehr intressant.Hmm wie es aussieht steht der R520 vor der tür!Auf der Seite gibts ein interview mit ein programmierer von Far Cry.Da werden bilder mit und ohne HDR gezeigt,sind das bilder vom r520 oder von nv40 ?

[Gfawf]

Wo steht denn das Es gibt einen netten Vergleich bezüglich der "doppelten Z-Leistung" auf ATI und nVidia Hardware. Das ganze allerdings mit einem schönen Trick von Seiten ATIs.habs nicht gefunden ?

[Demirug]

Wo steht denn das Es gibt einen netten Vergleich bezüglich der "doppelten Z-Leistung" auf ATI und nVidia Hardware. Das ganze allerdings mit einem schönen Trick von Seiten ATIs.habs nicht gefunden ?

"D3DTutorial04_Optimization" Seite 16 und 17.

[mapel110]

HDR HDR – Watch out Watch out
• Currently no FSAA Currently no FSAA
• Extremely fill rate hungry
• Needs support for float buffer blending Needs support for float buffer blending
• HDR HDR-aware production aware production1 :
– Light maps Light maps
– Skybox

hm, in dem Farcry pdf heissts, HDR wäre Fillrate hungry. Ich dachte, das geht auf Bandbreite?!

For prototyping, we actually modified our light map generator
to generate HDR maps and tried HDR skyboxes. They look to generate HDR maps and tried HDR skyboxes. They look
great. However we didn’t include them in the patch because…
– Compressing HDR light map textures is challenging
– Bandwidth requirements would have been even bigger
– Far Cry patch size would have been huge
– No time to adjust and test all levels

Dann wieder doch?! :confused:

/edit
wieso sind einige Sätze doppelt durch simples Copy/paste?! Na egal *wegeditier*

[Exxtreme]

Seite 20 von D3DTutorial04_Optimization finde ich interessant da sie einen vagen einblick in die Zukunft ermöglicht. :)

[Demirug]

mapel, so wie Crytek implementiert trift wohl beides zu. Man hat dort ja eine sehr aufwendige Filtercascade im Einsatz.

Zudem ist sinnvolles HDR ja immer mit einem Postprocessing verbunden und Postprocessing kostetet immer auch Fillrate.

[Demirug]

Seite 20 von D3DTutorial04_Optimization finde ich interessant da sie einen vagen einblick in die Zukunft ermöglicht. :)

Meinst du das?

This ratio will only go up This ratio will only go up
– Because available bandwidth doesn’t rise Because available bandwidth doesn’t rise as fast as chip density

Falls ja das hat ATI schon vor längerem schonmal erzählt.

[Coda]

For post processing try splitting your color into color into rg, ba and write them into two MRTs of format G16R16F. That’s more cache efficient on some cards.Warum steht das in einem ATi PDF?

[Exxtreme]

Meinst du das?

Japp, das meine ich.

[Demirug]

Warum steht das in einem ATi PDF?

Vielleicht ist das bei ATI auch so? Es ist ja aber auch nur ein halbes ATI pdf.

[Coda]

Falls es so wäre, würde es hier wenigstens weniger HDR Streitigkeiten geben ;)

Ist es richtig, dass man PS 3.0 nur mit VS 3.0 verwenden darf?

[DrumDub]

Ist es richtig, dass man PS 3.0 nur mit VS 3.0 verwenden darf?

ich meine, das so gelesen zu haben. von wegen der entwicklungsrichtung hin zu unified shader.

[Demirug]

Falls es so wäre, würde es hier wenigstens weniger HDR Streitigkeiten geben ;)

Ist es richtig, dass man PS 3.0 nur mit VS 3.0 verwenden darf?

Vollständig geklärt wurde das nie. Theoretisch kann man PS und VS 3.0 auch mit älteren VS bzw. PS benutzen. Was die Runtime da aber genau zulässt wurde IIRC bisher nicht veröffentlicht.

[Ailuros]

Vollständig geklärt wurde das nie. Theoretisch kann man PS und VS 3.0 auch mit älteren VS bzw. PS benutzen. Was die Runtime da aber genau zulässt wurde IIRC bisher nicht veröffentlicht.

Wenn ja dann nur D3D oder? 3DLabs waere ja sonst mit dem P20 ganz schoen im Eimer :confused:

[Demirug]

Wenn ja dann nur D3D oder? 3DLabs waere ja sonst mit dem P20 ganz schoen im Eimer :confused:

Sie melden zumindestens VS2.0 und PS 3.0. Es wird also auch irgendeine Möglichkeit geben das zu nutzen. Da sich 3DLabs aber ja noch nie sonderlich um D3D gekümmert hat gibt es dort AFAIK auch kein Techpaper zu dem Thema.

Bei OpenGL gibt es diese Einteilung in Shadermodele ja nicht. Mit allen Vor und Nachteilen die sich daraus ergeben.

[Jesus]

HDR HDR – Watch out Watch out
• Currently no FSAA Currently no FSAA

Heisst das jetzt nicht möglich oder nicht sinnvoll ?

[Exxtreme]

Heisst das jetzt nicht möglich oder nicht sinnvoll ?
AFAIK technisch NICHT machbar. Ich weiss aber nicht ob es sich auf's ganze Bild bezieht oder nur auf die Bildbereiche, die von HDR betroffen sind. Ich schätze aber, daß das ganze Bild betroffen ist.

Man bräuchte ROPs, die mit Fliesskomma-Formaten umgehen können. Ob es der R520 kann, weiss ich nicht.

[Coda]

Wenn dann bezieht sich das natürlich auf das ganze Bild, weil MSAA Rendertarget abhängig ist.

Und mit FP ROPs ist bei HDR AA noch nicht getan, siehe NV40.

[Ailuros]

AFAIK technisch NICHT machbar. Ich weiss aber nicht ob es sich auf's ganze Bild bezieht oder nur auf die Bildbereiche, die von HDR betroffen sind. Ich schätze aber, daß das ganze Bild betroffen ist.

Man bräuchte ROPs, die mit Fliesskomma-Formaten umgehen können. Ob es der R520 kann, weiss ich nicht.

Falls R520 dazu faehig sein wird, waere es ein sehenswerter Vorteil im Vergleich zu zukuenftigen NV4x (falls diese wieder nicht ueber MSAA/float HDR Kombinationen faehig sind).

[Jesus]

Hm, ich dachte das ganze bezieht sich auf den R520. Wenn man das so liest hört sichs eher so an als ob es sich noch auf NV Karten beziehen würde.

[Ailuros]

Hm, ich dachte das ganze bezieht sich auf den R520. Wenn man das so liest hört sichs eher so an als ob es sich noch auf NV Karten beziehen würde.

Die Behauptung ist genau genug. Momentan kann man eben float HDR mit MSAA nicht kombinieren. Es ist aber auch keine Anzeige ob sich dieses mit R520 aendern wird (schoen waere es auf jeden Fall).

[Exxtreme]

Falls R520 dazu faehig sein wird, waere es ein sehenswerter Vorteil im Vergleich zu zukuenftigen NV4x (falls diese wieder nicht ueber MSAA/float HDR Kombinationen faehig sind).
Das Problem ist, daß HDR Bandbreite wegschluckt wie nix. Nvidia hat sich wohl gedacht, wozu HDR + AA einbauen wenn die Bandbreite eh' nicht reicht zum Zocken? Es könnte auch beim R520 so sein.

[Ailuros]

Das Problem ist, daß HDR Bandbreite wegschluckt wie nix. Nvidia hat sich wohl gedacht, wozu HDR + AA einbauen wenn die Bandbreite eh' nicht reicht zum Zocken? Es könnte auch beim R520 so sein.

Bei ersten Implementationen geht es ja sowieso meistens nur um den feature-support und selten um Leistung (das Zeug ist ja in der Mehrzahl fuer die Entwickler interessant; generell nicht auf HDR alleine bezogen).

R520 ohne diese Faehigkeit klingt mir langweiliger, als ich es mir vorgestellt habe.

[Exxtreme]

Bei ersten Implementationen geht es ja sowieso meistens nur um den feature-support und selten um Leistung (das Zeug ist ja in der Mehrzahl fuer die Entwickler interessant; generell nicht auf HDR alleine bezogen).

R520 ohne diese Faehigkeit klingt mir langweiliger, als ich es mir vorgestellt habe.
Also um beim HDR richtig Power rauszuholen, braucht man viel Bandbreite. Und da sich die speicherchips nicht wesentlich höher takten lassen als beim NV40, wird ATi entweder das Speicherinterface vergrössern oder QDR-RAM verbauen müssen. Oder sie haben eine Technik drinne, die die Chose irgendwie komprimiert und so Bandbreite spart.

Ansonsten sehe ich da schwarz für ordentliche HDR-Performance.

[Coda]

Das Problem unterscheidet sich eigentlich überhaupt nicht von der 16/32 bit Diskussion damals.

[ShadowXX]

Bei ersten Implementationen geht es ja sowieso meistens nur um den feature-support und selten um Leistung (das Zeug ist ja in der Mehrzahl fuer die Entwickler interessant; generell nicht auf HDR alleine bezogen).

R520 ohne diese Faehigkeit klingt mir langweiliger, als ich es mir vorgestellt habe.

Der r520 wird auch "relativ" langweilig werden....IMHO wir der r520 quasi ein nv40-Clone (von den Features her) werden......anderes gesagt, die gleiche Suppe von einem neuen Koch oder "Im Westen nichts neues..."

(Bei kleineren Details, wie 3Dc oder SSAA / MSAA werden Sie sich natürlich weiterhin unterscheiden..)

Das einzige was interessant sein wird, ist a.) wie hoch bekommen Sie den Chip getaktet und welchen Ram packen Sie dazu und b.) wie haben Sie SM3.0 realistiert.

Im Prinzip also nur sehr spezielle technische Aspekte, die ausser hier im Forum wohl kaum jemand interessieren werden.

[:D]

Falls R520 dazu faehig sein wird, waere es ein sehenswerter Vorteil im Vergleich zu zukuenftigen NV4x (falls diese wieder nicht ueber MSAA/float HDR Kombinationen faehig sind).

allzu sinnvoll wäre es wohl nicht, schon HDR alleine frisst bandbreite zum frühstück, das noch mit FSAA zu kombinieren wäre wohl der leistungskiller schlechthin ;)

[Exxtreme]

allzu sinnvoll wäre es wohl nicht, schon HDR alleine frisst bandbreite zum frühstück, das noch mit FSAA zu kombinieren wäre wohl der leistungskiller schlechthin ;)
Nicht wenn ATi ein 512 Bit RAM-Interface mitbringt. Und eigentlich wäre es auch Zeit sowas zu nutzen. Der R100 und der R200 hatten 128 Bit, der R3xx und der R4xx 256 Bit und jetzt wäre der R520 eigentlich mit 512 Bit an der Reihe.

[Coda]

Exponentielle PCB Komplexität :rolleyes:

[mapel110]

allzu sinnvoll wäre es wohl nicht, schon HDR alleine frisst bandbreite zum frühstück, das noch mit FSAA zu kombinieren wäre wohl der leistungskiller schlechthin ;)
1. R520 sollte doch einiges schneller sein als NV40
2. Es wird AMR geben.
3. Ist HDR wohl laut nvidia bislang nicht richtig optimiert gewesen bzw es wurde Leistung verschwendet. siehe
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208788

[Exxtreme]

Exponentielle PCB Komplexität :rolleyes:
Na und? :tongue:

Die Fertigung der PCBs ist ja auch nicht stehen geblieben sondern wurde immer weiter verbessert.

[Coda]

Multilayer PCBs sind genauso teuer wie eh und je. Das sind ganz einfach Material und Zeitkosten.

[:D]

1. R520 sollte doch einiges schneller sein als NV40

stimmt, aber ich gehe nicht von mehr als 256bit speicherinterface bei max. 700MHz speichertakt aus, was für HDR ohne FSAA wohl schon ganz gut zu gebrauchen ist, mit FSAA aber wohl stark einbrechen würde.

2. Es wird AMR geben.

ob es sich für ein derartiges nischenprodukt auszahlt zusätzliche transistoren zu verwenden? ich denke eher dass ati wieder versuchen wird mit taktoptimiertem design zu glänzen. zudem ist ati traditionell sehr geizig was den umgang mit transistoren angeht, siehe AF-muster, oder "nur" FP24-einheiten usw.


3. Ist HDR wohl laut nvidia bislang nicht richtig optimiert gewesen bzw es wurde Leistung verschwendet. siehe
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208788
stimmt, HDR ohne FSAA wird, richtig optimiert wohl ganz gut brauchbar sein, für FSAA+HDR denke ich wird die leistung weder beim r520 noch bei nvidias potintiellem gegenstück ausreichend sein und auf entsprechende transitoren verzichtet.
ich denke dass die zeit frühestens bei nv50 und r600 (oder wie die codenamen auch immer lauten werden) reif sein wird HDR+FSAA vernünftig einzusetzen. (was nicht heißt dass der eine oder ander chip das ganze zumindest theoretisch kann)

[Demirug]

ob es sich für ein derartiges nischenprodukt auszahlt zusätzliche transistoren zu verwenden? ich denke eher dass ati wieder versuchen wird mit taktoptimiertem design zu glänzen. zudem ist ati traditionell sehr geizig was den umgang mit transistoren angeht, siehe AF-muster, oder "nur" FP24-einheiten usw.

Warum Transitoren verschwenden? AMR (oder wie immer es auch am Ende genannt werden mag) kann als reine Softwarelösung im Treiber realisiert werden.

[mapel110]

Warum Transitoren verschwenden? AMR (oder wie immer es auch am Ende genannt werden mag) kann als reine Softwarelösung im Treiber realisiert werden.
Ich denke, er meint eher "HDR+AA-Fähigkeit" und nicht AMR.

[:D]

Ich denke, er meint eher "HDR+AA-Fähigkeit" und nicht AMR.

richtig, so war es gemeint ;)