GL_nV_occlusion_query

[Quasar]

http://www.inf.bme.hu/%7ekenez/occl.html

Unter obiger URL ist ein Demo zur nV-OpenGL Extension "Occlusion Query" zu finden. Laut Beschreibung soll es damit möglich sein, zukünftig auf portalling und andere Techniken zur Verminderung der Anforderungen an die Grafikkarte durch die Szenenkomplexität zu verzichten (es ist geplant diese Extension in den OpenGL 2.0 Standard mitaufzunehmen, also auch auf anderen Chips möglich).

Angeblich ist es relativ leicht in Hardware einzubauen und wie die Demo zeigt, potentiell auch überaus effektiv zu nutzen.

Irgendwelche Meinungen?

[zeckensack]

Ist nicht wirklich einfach, das sinnvoll einzusetzen.

Normalerweise muß man die komplette Grafikpipeline ausleeren und in den Rückwärtsgang schalten, wenn man Daten vom Grafikchip zurückhaben will.

Mit der Extension bietet sich die Möglichkeit, in der Zwischenzeit noch etwas sinnvolles anderes zu tun.

So nach dem Motto, "Lieber Grafikchip. Sag' mir doch morgen mal Bescheid, ob dir die Daten von gestern gefallen haben".

Man muß also gründlich überlegen, was man in der Zwischenzeit, bis der Grafikchip seine 'Antwort' gegeben hat, sinnvolles anstellen kann. Ansonsten wird's halt lahm, da schnelle Grafik halt fast ausschließlich durch fettes Pipelining funktioniert.

[Quasar]

Es ist also nicht möglich, diese Rückmeldung auf einer Art Sideband (;)) zu erhalten?

BTW, läuft die Demo bei dir? Zumindest im Standard-Modus sollte sie's doch, oder?

[Unregistered]

Originally posted by Quasar
Es ist also nicht möglich, diese Rückmeldung auf einer Art Sideband (;)) zu erhalten?

BTW, läuft die Demo bei dir? Zumindest im Standard-Modus sollte sie's doch, oder? Hrrr, die alle Extensions, die mit NV_ beginnen, funktionieren bei mir wohl nicht so richtig. ;)
Außerdem: ich nix wissen, wo Demo. Wo ???

[zeckensack]

Ich!

[Quasar]

Das mit den nV Extensions hab ich mir schon gedacht, aber die Demo (Link zur Page is zwar oben, aber hier der direkt DL: http://www.inf.bme.hu/%7ekenez/occldemo.zip ) läuft OHNE "GL_NV_Occlusion_query" an, die Extension wird nachher zugeschaltet.

Deswegen dachte ich, möglicherweise nutzt sie ansonsten eher die Standard Extensions.

[Razor]

Für diejenigen, die's interessiert...

Auf Delphi3D (http://www.delphi3d.net/listfiles.php?category=4) gibt's eine Demo, das die Extension "GL_HP_occlusion_test" benutzt und wohl derzeit nur von den Deto's ab 27.xx geboten wird.

Ist also keine "NV_"-Extension und soll wohl Ähnliches zu Tage fördern...
(allerdings wohl nicht ganz so effektiv)

Das Demo gibt's direkt unter:
http://www.delphi3d.net/download/occlusion.zip

Much fun with it !

Razor

[Quasar]

JA, die kenne ich auch, ist allerdings wirklich nur eine "Demo", die den Effekt nicht vollständig zur Geltung bringt (wohl auch deswegen, weil das verdeckte Objekt ziemlich simpel ist..).

Wenn ich das richtig verstanden habe, prüft die HP-Extension aber nur, ab irgendwas in der "box" zu sehen ist und selbst wenn nur ein winziger Teil da ist, wird alles gerendert.

Die nV-Extension scheint da schon etwas fortschrittlicher zu sein, bin mir aber nicht sicher...

[Razor]

Das wäre natürlich ein sehr simpler Vorgang, ist aber zumindest eine allgemein gültige OGL-Funktion.

"Occlusion Query" scheint dagegen ja sehr effektiv. Habe mal ganz heraus gezoomt, so daß wirklich möglichst viele Objete/Polys zu sehen waren (180T/19Mio). Die Verwendung der Extension das Ganze dann aber auf 12T/1.3 Mio (Objekte/Polys) reduzierte.

Gut, meine fps sind zwar 'nur' von 0.24 auf ca. 2.34 gestiegen...
(immer noch keine 'wahnsinnige' Geschwindigkeit :D)
Aber immerhin bedeutet das eine Steigerung von satten 975% !!!

Würde mich wirklich interessieren, ob die Verwendung dieser Extension wirklich so ineffizient ist, wie es zeckensack darstellte. Eine Hardware-Implementierung könnte doch ev die einhergehende Problematik umgehen...

Hmmm...

Auf jeden Fall sehr interessant, man müsste wiklich mal einen Real-World-Bench haben, um zu sehen, ob sich dies nicht doch effizent einsetzen lassen würde.

Razor

[Quasar]

Vielleicht kann Z-Bag das ja in die OpenGL-Version des Villagemark einbauen? ;)

[Razor]

Na ja... VillageMark = "Real-World" ?
???

Eher nicht...
Aber insteressant wär's schon.
Also mach mal zeckensack !
:D

Razor

[Quasar]

Welchen Real-World Bench mit solch exzessiven Overdraw kennst du sonst noch, Razor? ;)

Morrowind mit voller Sichtweite vielleicht, aber das läuft mit DX8...

[Razor]

JK2 vielleicht... im Dschungel-Level...
Hmmm... hast schon recht.
Na ja, der VillageMark wär auf jeden Fall ein Anfang !
;-)

Razor

[Legolas]

Imho gibts in sämtlichen Quakeengines einen Befehl, um das Portaling auszuschalten. Bei Half-Life/Q1 ist der Befehl novis 1 glaub ich, bei Q3 wird er dann wohl so ähnlich heißen. So könnte man dann mal mit wirklich exzessivem Overdraw benchen. Wie wirklichkeitsnah das ganze dann ist, steht natürlich auf einem ganz anderen Blatt :D

[aths]

Soweit ich weiss bietet die in GF3(+4) HW neben early z occlusion und dieser beschriebenen Extrension keine zusätzlichen (besseren) Methoden.

[Quasar]

öh....steht das in irgendeiner Beziehung zu einem der vorhergehenden Postings?
Wenn ja, quote doch am besten den entsprechenden Passus...

[aths]

Du postest schneller als die Polizei erlaubt... Ich nahm Bezug auf "Die nV-Extension scheint da schon etwas fortschrittlicher zu sein, bin mir aber nicht sicher..."

[vogel]

Extrem nett fuer Coronas und andere Effekte dieser Art aber eher weniger um die Szenenkomplexitaet zu verringern. Wenn man die HW nicht "stallen" will bekommt man die Ergebnisse erst ein Frame spaeter.

-- Daniel, Epic Games Inc.

[Quasar]

@aths:
Ach so, dann verstehe ich das jetzt auch.
Ob in HW oder (was ich eher vermute) in Software, wäre auch die GL_HP_Occlusion_test zu betrachten, die nicht nur Füllrate sondern, wie es die entsprechende Demo aufzeigt, auch massiv Geometrie einsparen kann.

@vogel:
Dann gibt es also keine Möglichkeit, die occlusion query quasi an der Rendering Pipeline vorbei auszuführen?

[vogel]

Originally posted by Quasar

@vogel:
Dann gibt es also keine Möglichkeit, die occlusion query quasi an der Rendering Pipeline vorbei auszuführen?
Ein Ergebnis erfordert, dass alle Befehle vor der query ausgefuehrt worden sind also muss fuer syncronen Zugriff die HW 'gestallt' werden.
Ziemlich bloed formuliert von mir ;)

-- Daniel, Epic Games Inc.

[Quasar]

Also hat man immer einen Frame "Verzug". Bei Nutzung von Triple-Buffering stelle ich mir das nicht allzu schlimm vor...oder mach' ich da jetzt 'nen groben Denkfehler?

Egal, is' spät, Quasar muss schlafen ;)

[zeckensack]

Originally posted by vogel

Ein Ergebnis erfordert, dass alle Befehle vor der query ausgefuehrt worden sind also muss fuer syncronen Zugriff die HW 'gestallt' werden.
Ziemlich bloed formuliert von mir ;)

-- Daniel, Epic Games Inc. Ich finde die Erklärung in der Einleitung der Spec (http://oss.sgi.com/projects/ogl-sample/registry/NV/occlusion_query.txt) eigentlich recht brauchbar, zumal sie gleich die Unterschiede zur HP-Extension (http://oss.sgi.com/projects/ogl-sample/registry/HP/occlusion_test.txt) nennt.

Das Problem bei beiden Extensions ist, daß die Geometrie erst die komplette Pipeline durchlaufen muß, von der Transformation bis zum z-Test, bevor die Anfrage 'fertig' ist.

Im Gegensatz zu Daniel sehe ich den Sinn vor allem darin,
1)Geometrielast auf Kosten von Fillrate zu reduzieren. Man schicke ein extrem grobes Modell voraus, ohne den Framebuffe anzutasten. Wenn es sichtbar gewesen wäre, dann rendert man die hochaufgelöste Version.
2)Die Sachen, die Matt sonst noch in der Spec geschrieben hat, halte ich für nützliches Beiwerk.

[vogel]

Bis Du darauf bauen kannst, dass jeder 'ne Karte hat die diese Extensions beherrscht, wird sich das Bild gewandelt haben und Fuellrate wird eine etwas weniger wichtige Rolle spielen. Meiner Meinung nach wird man eher vermeiden wollen, dass komplexe Pixelshader ausgefuehrt werden und Speicherbandbreite wird auch eine gehobenere Rolle spielen mit all den floating- point Formaten. Das geht am einfachsten wenn man die komplette Szene nur in den Z Buffer rendert und dann erst richtig loslegt. Mit effektiver "early Z rejetion" reduziert das den opaquen overdraw dann auf 1 und eliminiert texture fetches. Hat zwar relativ wenig jetzt mit der Extension zu tun, aber wenn das Bottleneck Pixel Shader Instruktionen sind dann werden sich Entwickler sicher zweimal ueberlegen Ihre Renderpipeline umzumoddeln um irgendwie die Extension sinnvoll benutzen zu koennen.

Syncroner Zugriff raubt alle Vorteile - NVIDIA's Loesung mit "fences" ist zwar ziemlich nett, aber in der Praxis wird man einfach ein Frame warten und dann auf ein Ergebnis mit 'ner busy- loop warten. Ich kann mir nicht Vorstellen, dass jemand ernsthaft diese Extension fuer "visibility determination" benutzen wird.

Fuer Coronas und Sonneneffekte und all den Schnickschnack fuer die es ziemlich Schnuppe ist ob die Ergebnisse ein Frame alt sind eignet sich die Extension jedoch perfekt! Vor allem da man Coronas 'ausfaden' kann je nachdem wie stark sie ueberdeckt sind. Im Augenblick muss man dazu entweder vom Backbuffer lesen oder NVIDIA's render-to-texture trick anwenden.

Sorry fuer die vielen Anglizismen... bins halt gewohnt ;)

-- Daniel, Epic Games Inc.

[zeckensack]

Jojo, das mit den Anglizismen geht mir auch so. Fällt mir momentan sehr viel schwerer, sachen auf Deutsch vernünftig zu erklären ;)
Und an sich halte ich überhaupt nicht sonderlich viel von dieser Extension, weder in der HP-, noch der NV-Version, wollte halt nur aus meiner Sicht schildern, was die so macht.

Daß man Pixelshader erst nach dem Z-Test ausführt (solange kein Z-Replace im Spiel ist), ist eigentlich eine Optimierung, die man von den Kartenentwicklern erwarten sollte. Ob's die gibt oder nicht, kA, ich renn hier immer noch auf einer Radeon 1 rum.

Und Coronas .... halte ich für viel zu primitiv, als daß sie Optimierungen irgendeiner Art rechtfertigen sollten. Ok, overdraw inklusive Blending, aber es ist doch recht unwahrscheinlich, daß mehr als 20% des Bildes aus Coronas bestehen ???

[vogel]

Durch das zweifach rendern erreichst Du praktisch das gleiche wie das sortieren der Objekte von nah nach fern jedoch hilft es auch bei nicht konvexen Objekten und meistens will man nach Material (Shader/Texture Kombination) sortieren was in der Regel mehr bringt. Naja, mal sehen was die Zukunft da bringt. "State changes" sollen ja schneller werden...

Wreckless hat sehr sehr nette Coronas. Wuerd mich nicht wundern wenn da das XBox equivalent der Extension genutzt wurde :)

-- Daniel, Epic Games Inc.

[vogel]

Tom Forsyth's post zum Thema.

http://sourceforge.net/mailarchive/forum.phpthread_id=712606&forum_id=6188

Jedoch wuerde ich nicht so weit gehen und Texturen selber managen und ein niedrig LOD Objekt nach eins zwei Frames zu einem high LOD Objekt zu morphen hoert sich nach mehr Problemen an als es wert ist.

-- Daniel, Epic Games Inc.