HSR: Hidden Surface Removal

[betasilie]

Thanks aths, das war mal ein interessanter Artikel. :) =) :)

[Pussycat]

Absolut! Aber stimmt das hier?

"Mit nur 230 Megatexel Füllrate (Kyro1, 115 MHz) zersägte sie problemlos eine GeForce2 MX (im 32-Bit-Modus 350 Megatexel Füllrate) bzw. mit 350 MegaTexel (Kyro 2, 175 MHz) kann sie durchaus mit einer GeForce2 GTS (im 32-Bit-Modus 800 MegaTexel) mithalten."

Hast du nich texel mit pixel verwechselt?

[Quasar]

Nein, er hat nur die "effektiv" erreichte Füllrate angegeben....

[Pussycat]

jaja, aber die GF2 hat 1,6Gtexel und 800 megapixel.

Das die Kyro auch mit seinen schlechten füllraten mithalten kann (konnte) ist mir bekannt.

[Quasar]

Ich denke, aths bezieht sich da auf die Werte, die die GeForce2 (MX) in 32Bit nur zu leisten im Stande ist.
Irgendwas wegen einer Limitierung im Register Combiner.

[Pussycat]

Und dadurch verhält er sich wie ein 4*1 (bzw 2*1) Renderer unter 32 bit? Ist aber gar nicht um stolz drauf zu sein!

[Demirug]

Der Thread für den Artikel ist eigentlich dort: http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=40546

[StefanV]

Originally posted by Pussycat
Und dadurch verhält er sich wie ein 4*1 (bzw 2*1) Renderer unter 32 bit? Ist aber gar nicht um stolz drauf zu sein!

wie genau er sich verhält ist nicht bekannt, vermuten würd ich eher 2x2 ;)

Jedenfalls halbiert sich die Füllrate, da diese Combiner nur für 16bit ausgelegt sind, weswegen sie für 32bit kombiniert werden müssen, was für die miese Performance der NV Karten unter 32bit mitverantwortlich ist.

[aths]

Originally posted by Pussycat
jaja, aber die GF2 hat 1,6Gtexel und 800 megapixel. Das ist nur im 16-Bit-Modus so. Da ich nicht zu sehr vom Artikelthema abweichen wollte und eine lange Erklärung schreiben, wieso in 16 Bit GF2MX die Kyro1 bzw. die GTS die Kyro2 (fast) immer überholen, beschränkte ich mich gleich auf den (imo auch sinnvolleren) 32-Bit-Fall.

[Demirug]

Originally posted by Stefan Payne


wie genau er sich verhält ist nicht bekannt, vermuten würd ich eher 2x2 ;)

Jedenfalls halbiert sich die Füllrate, da diese Combiner nur für 16bit ausgelegt sind, weswegen sie für 32bit kombiniert werden müssen, was für die miese Performance der NV Karten unter 32bit mitverantwortlich ist.

Ja 2*2 ist richtig. Allerdings werden dabei aus dem bi TMUs tri TMUs.

[Quasar]

Hm, bevor ich jetzt nen neuen Thread starte, poste ich's lieber hier rein. Allein vom Titel passt's auch ganz gut:

Ist jemand anderem schonmal mit einer früheren Treiberversion aufgefallen, dass der R300 (zumindest ab den DX9-Treibern) die "GL_NV_occlusion_query" unterstützt?

Das könnte dann ja doch noch was werden, wenn die beiden Großen auch mal über ihren eigenen Schatten springen....

[Demirug]

Originally posted by Quasar
Hm, bevor ich jetzt nen neuen Thread starte, poste ich's lieber hier rein. Allein vom Titel passt's auch ganz gut:

Ist jemand anderem schonmal mit einer früheren Treiberversion aufgefallen, dass der R300 (zumindest ab den DX9-Treibern) die "GL_NV_occlusion_query" unterstützt?

Das könnte dann ja doch noch was werden, wenn die beiden Großen auch mal über ihren eigenen Schatten springen....

Sowas kommt schon mal öfter vor. In der Regel wird dann aus diesen Extensions eine ARB Extension.

EDIT: BTW diese "Extension" gibt es jetzt auch bei DX9.

[Quasar]

Ja? Sowas gibt's in DX9 auch? Das gefällt mir, endlich mal eine praktische Extension, die auch noch von MS kopiert wird ;)

[Demirug]

Originally posted by Quasar
Ja? Sowas gibt's in DX9 auch? Das gefällt mir, endlich mal eine praktische Extension, die auch noch von MS kopiert wird ;)

Ja gibt es. Es funktioniert fast genauso wie die NVIDIA Extension. Im Direkt X für die X-Box ist das sogar schon länger drin.

[Quasar]

Siehst du Chancen, dass die von den Entwicklern akzeptiert wird, so in ein oder anderthalb Jahren?

[Demirug]

Originally posted by Quasar
Siehst du Chancen, dass die von den Entwicklern akzeptiert wird, so in ein oder anderthalb Jahren?

Schwer zu sagen. Mann müsste erst mal prüfen wie sich dieses Feature sinnvoll einsetzten lässt ohne die Grafikkarte zu blockieren. Das es fälle gibt wo es sinn macht wurde ja schon mit der opengl Extension nachgewiesen. es aber so einfach mal in einen bestehende Engine einzubauen dürfte nicht immer ganz einfach sein.

[Quasar]

Ah ja, also im Normalfall höchstens bei Engines/Games, die gerade im Entstehen sind...

Thx für die Auskunft. :)

[aths]

Die faule Entwickler-Bande soll lieber zusehen, endlich mal PixelShader vernünftig einzusetzen. Das kann doch nicht so schwer sein.

[Unregistered]

Der Einsatz von PS ist imo kein Frage der Schwierigkeit.
Man hat halt durch jahrelange Gewöhnung daran die 'altbewährte' konventionelle Multitexturing Technik noch besser im Griff.

[Quasar]

Originally posted by aths
Die faule Entwickler-Bande soll lieber zusehen, endlich mal PixelShader vernünftig einzusetzen. Das kann doch nicht so schwer sein.
Die warten doch bloss auf die HLSL, damit ihnen die Material-Shader schon vorgegeben werden.

[aths]

Originally posted by Quasar
Die warten doch bloss auf die HLSL, damit ihnen die Material-Shader schon vorgegeben werden. Für richtigen Materialshader-Einsatz würde die Power der heutigen DX8-Karten auch kaum reichen. DX8-Pixelshader könnten aber imo für ausgefallenere Beleuchtungsmodelle verwendet werden, auch gerade in Bezug auf (am besten prozedurales) Bumpmapping.