UltraShadow der 5900 im Vergleich zu HyperZ III+

[Unregistered]

Hi,

also, der HyperZ III+ komprimiert die Dateien im Z-Buffer.Da der Z-Buffer in DoomIII massiv genutzt werden wird, wird das dann wohl einen Performance-sprung geben.So habe ich das mal verstanden.

Über den UltraShadow hab ich leider noch nicht viel gehört, außer, dass er in DoomIII Performance-Vorteile bringen soll.Was glaubt ihr (oder wisst ihr es schon),ist das auch eine Z-Buffer-Kompression?

[radioactiveman24]

hä?
war irgendwie nicht angemeldet, iss jedenfalls von mir

[Demirug]

Z-Buffer-Kompression gibt es schon viel länger das ist nichts mehr neues.

Da aber sowohl ATI wie auch NVIDIA sich ausschweigen wie sie die DOOM III Engine un beschleunigend wollen gibt es da nicht viel Grundlage für eine Spekulation.

[Frankie]

Originally posted by Demirug
Z-Buffer-Kompression gibt es schon viel länger das ist nichts mehr neues.

Da aber sowohl ATI wie auch NVIDIA sich ausschweigen wie sie die DOOM III Engine un beschleunigend wollen gibt es da nicht viel Grundlage für eine Spekulation.
Du kommst ja aus der Branche Demirug.
Mich würde mal interessieren ob du diese ganzen (Pseudo-?)Optimierungen für eine einzige Engine gut heißt.
Werden auch andere Engines davon profitieren? Oder ist es wie bei dieser "auf ATI/nVidia optimieren" Diskussion dass man eigentlich auch alles andere automatisch mit optimiert?

[Demirug]

Mich würde mal interessieren ob du diese ganzen (Pseudo-?)Optimierungen für eine einzige Engine gut heißt.
Solange es nicht zu lasten andere Dinge geht soll es mir egal sein. Wobei solche Optimierungen auf eine bestimmte Engine sowieso nur für Engines möglich sind bei denen man davon ausgehen kann das sie sich länger am Markt halten und einige Spiele damit gemacht werden. Das hängt einfach mit den Vorlaufzeiten zusammen.

Zudem muss man ja auch noch sagen das nicht wirklich auf eine Engine optimiert wird. Es wird die Fähigkeit eines Chips bezüglich einer bestimmte Rendertechnik optimiert. Für DOOM III könnte man die Dot3 Leistung sowie den Stencilbuffer (für die Schatten) als ganzes optimieren.

Werden auch andere Engines davon profitieren?
Ja wenn sie die gleichen Verfahren benutzten können auch andere Engines einen gewinn daraus ziehen

Oder ist es wie bei dieser "auf ATI/nVidia optimieren" Diskussion dass man eigentlich auch alles andere automatisch mit optimiert?

Optimiert wird immer aber wenn man in einem Bereich optimiert den eine Engine nicht benutzt nutzen diese Optimierungen eben reichlich wenig. So kann eine Engine die keinen Stencilbuffer benutzt eben auch nicht von Optimierungen in diesem Bereich profitieren.

[radioactiveman24]

nein, das hat nix mit auf Nvidia oder ATI hin optimieren zu tun.


Die im Triangle berechneten Tiefenwerte eines jeden Pixels werdem später im Z-Buffer abgelegt (ist ein Teil des Grafikspeichers)Durch das abspeichern dieses Tiefenwerts wird sichergestellt, dass nur die Teile der Dreiecke dargestellt werden, die auch wirklich sichtbar sind.
ATI optimiert so:HyperZ ist eine Kombination aus Tiefenspeicherkompression und vorgezogenen Tiefentests.Und der hierarchische Tiefenspeicher des Prozessors harmoniert nun noch besser mit Schattenberechnungen, die mit Daten im Stencil-Buffer hantieren. Und genau das macht DoomIII massiv.Deswegen, sollte HyperZ III+ Performance-vorteile bringen.
Es profitiert natürlich nicht nur DoomIII davon, sondern (wie Demirug bereits gesagt hat)jedes Spiel, dass den Stencil-Buffer nutzt.

Was Nvidia macht weiß ich eben noch nicht

[Anonym_001]

Originally posted by Frankie

Du kommst ja aus der Branche Demirug.
Mich würde mal interessieren ob du diese ganzen (Pseudo-?)Optimierungen für eine einzige Engine gut heißt.
Werden auch andere Engines davon profitieren? Oder ist es wie bei dieser "auf ATI/nVidia optimieren" Diskussion dass man eigentlich auch alles andere automatisch mit optimiert?

Ich komme auch nicht aus der Branche.

Es sind keine Optimierungen für eine Engine, sondern für die jeweiligen Karten (GPUs). Es wird also die Engine so optimiert das das jeweilige Game auf den Karten gleich aussieht.
So sehe ich das.
Sorry wenns falsch ist.

[Pussycat]

Die Chips werden anscheinend aber tatsächlich auf Doom III getuned (oder wenigstens verkauft man's, alsob dass so sei). Normalerweise geht's andersrum.

[Demirug]

Originally posted by Pussycat
Die Chips werden anscheinend aber tatsächlich auf Doom III getuned (oder wenigstens verkauft man's, alsob dass so sei). Normalerweise geht's andersrum.

Es wird nicht wirklich direkt auf DOOM III getuned. Die DOOM III engine ist nur die erste grosse die massiv den Stencil buffer benutzt. Da dieser vorher kaum genutzt wurde hat man dort auch nie besonders grossartig was optimiert. Er war eben da und gut ist. Nachdem die Chiphersteller ja nun schon eine ganze Weile wissen was JC für DOOM III wie macht war es nur logisch das man mal etwas für die Stencilbuffer performance tut. Da DOOM III aber als erstes davon profitieren wird könnte man natürlich schon von einer DOOM III optimierung sprechen.

[micki]

was haltet ihr davon, dass man nur einen 1but stencilbuffer macht, und dann immer xort, bei shadowvolumes wie für doom3, werden die schatten immer an die stelle gezeichnet, wo ein ungerader wert im stencilbuffer steht, quasi frontfaces Xor Backfafes, damit würde man vielleicht alles in den chip bekommen...

also wäre ma ne idee von mir was die bei nvidia getan haben könnten....

MfG
micki

[Xmas]

Originally posted by micki
was haltet ihr davon, dass man nur einen 1but stencilbuffer macht, und dann immer xort, bei shadowvolumes wie für doom3, werden die schatten immer an die stelle gezeichnet, wo ein ungerader wert im stencilbuffer steht, quasi frontfaces Xor Backfafes, damit würde man vielleicht alles in den chip bekommen...
Diese Idee hatte ich auch mal, stimmt nur leider nicht. Doom3 rendert Schatten dort, wo der Stencilbuffer nicht 0 ist. Anders würde die Schachtelung von Shadow Volumes nicht funktionieren. Es kann sich ja ein Shadow Volume in einem anderen befinden. Befindet sich ein Objekt zugleich in beiden, dann hast du zweimal Z-Fail für die Backfaces, also +2.

[micki]

stimmt, das ist mir später auch irgendwie eingefallen... hmm... dann wird wohl nur eine extra compression für stencil in frage kommen..


vielleicht würde es auch reichen, wenn nvidia den stencilbuffer gesondert vom zbuffer speichert, weil nach dem ersten pass muss nicht mehr in den z-buffer geschrieben werden, aber der stencil wird ja noch mehrmals bearbeitet, die würden also den buffer kompakter hinbekommen an gesonderter stelle... aber ich weiß net ob das viel bringen könnte.

MfG
micki

[Demirug]

Originally posted by micki
stimmt, das ist mir später auch irgendwie eingefallen... hmm... dann wird wohl nur eine extra compression für stencil in frage kommen..


vielleicht würde es auch reichen, wenn nvidia den stencilbuffer gesondert vom zbuffer speichert, weil nach dem ersten pass muss nicht mehr in den z-buffer geschrieben werden, aber der stencil wird ja noch mehrmals bearbeitet, die würden also den buffer kompakter hinbekommen an gesonderter stelle... aber ich weiß net ob das viel bringen könnte.

MfG
micki

Ja die Idee mit dem getrennt gespeicherten Stencil-Buffer hatte ich auch schon.

Der Vorteil wäre das man den Stencilbuffer so viel schneller löschen könnte. Bei einem gemischten Z/Stencil Buffer muss man ja das ganze immer erst einladen alle Stencilwerte auf 0 setzten und dann wieder schreiben.

Aber auch in der benutzung dürfte man so Bandbreite Sparen denn man schreibt und liest immer nur das (Z und Stencil) was wirklich notwendig ist.

Beim Z-Pass verändert man ja eigentlich nur den Z-Wert und bräuchte den Stencilbuffer gar nicht anzufasssen.

Bei Schattenpass muss man zwar den Z und den Stencilwert einladen aber höchsten den Stencilwert schreiben

Bei Lichtpass ist es dann aber egal weil beides braucht.

Eine andere Idee die ich noch hätte wäre den Stencilbuffer verzögert zu löschen. Also erst wenn die Stencilbufferkachel beim Schattenpass zum ersten mal wieder eingeladen wird.

[Demirug]

Mehr zu UltraShadow: http://www.nvidia.com/docs/lo/2968/SUPP/UltraShadow_050903_v3.pdf

[micki]

eigentlich löscht man den stencilbuffer nicht extra, sondern löscht beim beleuchtungspass den stencil, weil man dort eh nur einmal jeden pixel mit der liechtquellen intensität erhöcht. dann braucht man nicht extra löschen, damit sparrt man sich einen read des zbuffers pro lichtquelle.

in dem zusammenhang könnte ich mir vorstellen, dass der stencilbuffer in die oberen 8bit des colorbuffers rutschen aus dem zbuffer, weil man den colorbuffer sowieso beschreibt, somit wäre der clear gratis.


vielleicht packen die das auch einfach nur im chip, 16x16 kacheln oder so, weil der stencilwert öfters großflächig gleich ist...


bei heise steht, dass die optimierung darin liegt, dass ein bereich nur mit den schatten gezeichnet wird, das hat jemand von Nv schon vor längeren von opengl.org aus verlinkt, er nutzt dafür clippingplanes... hoffentlich ist das nicht das, was die marketingabteilung von Nv als shadowbuffer optimierung anpreisst.


MfG
micki

[Demirug]

Originally posted by micki
eigentlich löscht man den stencilbuffer nicht extra, sondern löscht beim beleuchtungspass den stencil, weil man dort eh nur einmal jeden pixel mit der liechtquellen intensität erhöcht. dann braucht man nicht extra löschen, damit sparrt man sich einen read des zbuffers pro lichtquelle.

Das funktioniert leider nicht. Bei diesem Verfahren würde man nur dort den Stencilbuffer löschen wo auch wirklich ein Object ist. Im Stencilbuffer sind aber auch Schattenbereiche gespeichert an denen sich überhaupt kein Object befindet. Ein Komplettes löschen kann man daher nicht vermeiden.

in dem zusammenhang könnte ich mir vorstellen, dass der stencilbuffer in die oberen 8bit des colorbuffers rutschen aus dem zbuffer, weil man den colorbuffer sowieso beschreibt, somit wäre der clear gratis.

Das funktioniert aber nur wenn beim Anlegen des Framebuffers auf den Alphawert verzichtet wird. Und selbst dann heist es immer noch komplett löschen.

vielleicht packen die das auch einfach nur im chip, 16x16 kacheln oder so, weil der stencilwert öfters großflächig gleich ist...

Ja Kompression ist auch bei Stencilwerten eine gute Idee.

bei heise steht, dass die optimierung darin liegt, dass ein bereich nur mit den schatten gezeichnet wird, das hat jemand von Nv schon vor längeren von opengl.org aus verlinkt, er nutzt dafür clippingplanes... hoffentlich ist das nicht das, was die marketingabteilung von Nv als shadowbuffer optimierung anpreisst.


MfG
micki

Es scheint so das es sich hier wirklich primär nur um Clipplanes handelt. Zumindestens ist in dem Paper sonst nichts zu erkennen.

[micki]

Originally posted by Demirug
Das funktioniert leider nicht. Bei diesem Verfahren würde man nur dort den Stencilbuffer löschen wo auch wirklich ein Object ist. Im Stencilbuffer sind aber auch Schattenbereiche gespeichert an denen sich überhaupt kein Object befindet. Ein Komplettes löschen kann man daher nicht vermeiden.


da der schatten dadurch entsteht, dass man ein OBJEKT nicht beleuchtet, wo der stencilwert gesetzt ist, sind leere bereiche ohne objekte egal, weil dort sowieso schatten ist... egal welcher stencilwert... ist ja nix da zum beleuchten.

das clear vom zbuffer+stencil zwischen frame muss natürlich gemacht werden..alleine schon aus performancegrründen :).. aber nicht zwischen den einzelnen passes.... also ich hab damit noch nie artefakte gehabt auf diese weise, ich wüste auch nicht weshalb :)

Originally posted by Demirug
Das funktioniert aber nur wenn beim Anlegen des Framebuffers auf den Alphawert verzichtet wird. Und selbst dann heist es immer noch komplett löschen.


ich glaube es ist sehr selten dass man auf den framebuffer alpha anlegt, ich glaube mich zu erinnern dass man dann auf manchen grakas trotzdem kein alpha bekommt, wenn man's versucht.. unter opengl hab ich es jedenfalls nie geschaft... :-S

Originally posted by Demirug
Ja Kompression ist auch bei Stencilwerten eine gute Idee.


runlenght schätze ich :)

Originally posted by Demirug
Es scheint so das es sich hier wirklich primär nur um Clipplanes handelt. Zumindestens ist in dem Paper sonst nichts zu erkennen.
schrieb ich doch :);D



MfG
micki

[Demirug]

Originally posted by micki


da der schatten dadurch entsteht, dass man ein OBJEKT nicht beleuchtet, wo der stencilwert gesetzt ist, sind leere bereiche ohne objekte egal, weil dort sowieso schatten ist... egal welcher stencilwert... ist ja nix da zum beleuchten.

Ich habe das schon fertig gebracht. Aus diesem Grund lösche ich grundsätzlich den gesamten Stencilbuffer. Das könnte aber durchaus damit Zusammenhängen das ich nicht jedes Objekt mit jeder Lichtquelle rendere und so blieben die Stencilwerte auch an den Stellen auf den Schattenwerten an denen in einem späteren Lichtpass doch noch ein Objekt gerendert wird.

[micki]

aber eigentlich wird NV nix neues an features eingebaut haben denk ich mir, also wohl nur etwas altes neu nutzen... *boring*

MfG
micki

[Crazytype]

hat Nvidia nicht was eingebaut, wodurch sie Stencil Shader Berechnungen in nur einen pass berechnen können, wogegen andere 2 brauchen? Glaub die nennen es Shadow Culling oder so.

[Quasar]

Two-Sided Stencil, glaube ich. Aber das können die Radeons (>=9500) ebenso, auch wenn nVidia das natürlich ungern erwähnt.

[Ailuros]

Ich haette eventuell noch eine dritte Alternative fuer stenciling aber ich werde wohl wieder den Thread OT jagen :D

[Demirug]

Originally posted by Crazytype
hat Nvidia nicht was eingebaut, wodurch sie Stencil Shader Berechnungen in nur einen pass berechnen können, wogegen andere 2 brauchen? Glaub die nennen es Shadow Culling oder so.

Wie Quasar schon sagt ist das Two-Side Stencil und das können alle R(V)3xx und NV3x Chips. Der Hauptvorteil dieser Methode liegt an zwei Punkten die aber eng miteinader verbunden sind.

1. Mit Two-Side Stencil muss die Geometrie der Schattenvolumen nur einmal berechnet werden ohne eben zweimal. Bei den Highendkarten mit sehr viel Vertexleistung bringt das aber kaum etwas.

2. Da die Geometrie nur einmal berechnet werden muss braucht man sie auch nur einmal zu übergeben. Und da man für jedes Anstossen einer Berechnung etwas CPU Leistung braucht verringert Two-Side Stencil die CPU-Lastigkeit der Schattenberechung etwas.

[AlfredENeumann]

Originally posted by Quasar
Two-Sided Stencil, glaube ich. Aber das können die Radeons (>=9500) ebenso, auch wenn nVidia das natürlich ungern erwähnt.

Ja. können alle R300.

[ow]

Originally posted by AlfredENeumann


Ja. können alle R300.

und alle NV3x. wie demi schon sagte.

[zeckensack]

Originally posted by Unregistered
Hi,

also, der HyperZ III+ komprimiert die Dateien im Z-Buffer.Da der Z-Buffer in DoomIII massiv genutzt werden wird, wird das dann wohl einen Performance-sprung geben.So habe ich das mal verstanden.

Über den UltraShadow hab ich leider noch nicht viel gehört, außer, dass er in DoomIII Performance-Vorteile bringen soll.Was glaubt ihr (oder wisst ihr es schon),ist das auch eine Z-Buffer-Kompression? Wenn ich eins (http://www.anandtech.com/video/showdoc.html?i=1821&p=7) und eins (http://developer.nvidia.com/docs/IO/4449/SUPP/GDC2003_ShadowVolumes.pdf) korrekt zusammenzähle, dann handelt es sich bei 'Ultra Shadow' oder was auch immer um dies hier:
GL_NV_depth_clamp (http://oss.sgi.com/projects/ogl-sample/registry/NV/depth_clamp.txt)

Wie man sieht (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_NV_depth_clamp), ist dies keineswegs ein Exklusiv-Feature der FX5900. Es wurde zwar erst kürzlich in die Treiber eingebaut, aber sogar die altehrwürdige Geforce 3 beherrscht das ganze :|

edit: ein gewisser jemand hat mir auch etwas von Stencil-Kompression geflüstert, diese Information ist aber wohl nicht offiziell (oder doch???)

[Xmas]

Originally posted by zeckensack
Wenn ich eins (http://www.anandtech.com/video/showdoc.html?i=1821&p=7) und eins (http://developer.nvidia.com/docs/IO/4449/SUPP/GDC2003_ShadowVolumes.pdf) korrekt zusammenzähle, dann handelt es sich bei 'Ultra Shadow' oder was auch immer um dies hier:
GL_NV_depth_clamp (http://oss.sgi.com/projects/ogl-sample/registry/NV/depth_clamp.txt)

Wie man sieht (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_NV_depth_clamp), ist dies keineswegs ein Exklusiv-Feature der FX5900. Es wurde zwar erst kürzlich in die Treiber eingebaut, aber sogar die altehrwürdige Geforce 3 beherrscht das ganze :|
Nein, die UltraShadow-Extension ist NV_depth_bounds_test. NV_depth_clamp spart das Capping für Near und Far Clipping Plane.