PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Pixelfüllrate bei Fury X


Digidi
2015-06-24, 18:41:56
mal eine Frage wieso ist den die Pixelfüllrate / rops bei Fury X um 30% kleiner als bei Nvidia? Hat das irgendwelche Auswirkungen? Die Fury x hat ja viele shader mit wieviel gp/s können denn die Shader die Rops füttern?

Matthias2304
2015-06-30, 13:42:19
Die Beiden fokusieren auf unterschiedliche Strategien.
67 GP/s liefert die Fury X. Die 980 Ti 92GP/s. Das sind sogar rund 38% mehr. Die Pixelfüllrate ist heute aber meistens nur noch zweitrangig. Durch Dx9 wurden die Streamingprozessoren eingeführt. Diese sind vorallem in Shaderlastigen Spielen wichtig. Da hat Fury X mehr. Aber sie bringt ihre Rohpower nur unzureichend aufs Parkett. Denke das liegt an den vielen Neuerungen HBM etc. Vielleicht kann die nächste Generation oder ein Roundup mit neuer Rev Besserung bringen.

iuno
2015-06-30, 15:19:01
Wie wäre es eigentlich mal mit einer Sammlung der FAQ bzgl. Grafikkarten? Dort könnte man einige Grundbegriffe erkären, bestimmte Bauteile beschreiben und wofür man sie braucht ROPs, SP, Frond-Backend), oder Zahlen wie Speicherbandbreite, Takt, Pixelfüllrate, FLOPs usw. erklären.
Das sollte ja genau solche Fragen beantworten und wäre mal eine nette Übersicht ;)

Hübie
2015-07-15, 00:48:34
Grundsätzlich keine üble Idee, aber du hast keine Ahnung wie wahnsinnig komplex das werden kann und wie wenig doch an Informationen vorhanden sind ;)
Aber zur Übersicht sicher nicht verkehrt. Wenn ich Zeit habe mache ich gerne mit. Aber die Pflege muss jemand anders übernehmen.

Gipsel
2015-07-15, 01:36:34
mal eine Frage wieso ist den die Pixelfüllrate / rops bei Fury X um 30% kleiner als bei Nvidia?GM200 hat einfach 50% mehr ROPs als eine Fury (oder auch Hawaii). Die Fähigkeiten unterscheiden sich allerdings etwas. So hat z.B. mit 4xFP16 (oder auch 4xFP32) Farbformat (HDR) eine Fury trotz weniger ROPs eine höhere Füllrate. Mit Blending trifft das dann zusätzlich auch auf 3xFP10 und 1xFP32 Rendertargets zu. In dem Bereich können die Radeon-ROPs einfach mehr (fullrate-Blending mit 4xInt8, 3xFP10, 1xFP32 und 4xFP16, 1:4 Rate mit 4xFP32; nV hat dagegen fullrate-Blending nur für 4xInt8, nur halfrate für 3xFP10 und 4xFP16, 1xFP32 ist 1:4, 4xFP32 sogar nur 1:16). Die Füllrate pro ROP ist bei der Fury also tendentiell höher (teilweise deutlich). Dafür besitzen die nV-ROPs traditionell Vorteile bei Z-Tests.

z3ck3
2015-07-15, 02:25:39
Gäbe es eigentlich irgend eine Möglichkeit bestimmte Einheiten einer GPU teilweise temporär zu deaktivieren, z.B. per BIOS Mod? Alternativ per Software einen bestimmten Teil eines Chips zu belasten. Mich würd z.b. mal interessieren ob die ROPs wirklich so zweitrangig sind wie es oft dar gestellt wird. Seit DX9 könnte man schon fast den Eindruck gewinnen das man die auch weg lassen könnte. ;)

Gerade bei der Fury scheinen ja die Shader zwar im Überfluss vorhanden zu sein, an kommt davon aber nicht mehr viel. Und bei der Fury wurde u.a. hier, an den ROPs gespart (390X hat 64, Fury ebenso).

Was mich auch interessieren würde wäre, in wie weit der L2 Cache mit eine Ursache des Performance Problems sein könnte. Dieser ist so weit ich weiß gleich groß und schnell wie bei der 390X. Also bringt evt. die reichlich vorhandene Bandbreite des HBM Speichers nicht so viel, da der Cache limitiert? Ich bezweifel das bei der 290X "zu viele" dieser Einheiten verbaut worden sind, was dann eben dazu führen könnte das u.a. die Shader Däumchen drehen. Generell hatte ich den Eindruck bei AMD schon immer, quasi einfach eine möglichst hohe Anzahl an Shader als Marketing Argument, ob man sie braucht oder nicht, egal. In diesem Fall halt noch zusätzlich die Problematik das AMD keinen Platz mehr auf dem Chip hatte, irgendwas musste man weglassen, aber bitte nicht an den Shadern sparen... ^^

Gipsel
2015-07-16, 16:26:31
Was mich auch interessieren würde wäre, in wie weit der L2 Cache mit eine Ursache des Performance Problems sein könnte. Dieser ist so weit ich weiß gleich groß und schnell wie bei der 390X.Nein. Fiji hat 2MB L2 (32 Tiles zu je 64 kB), doppelt so viel wie Hawaii (16 Tiles zu je 64kB *). Die Anzahl der L2-Tiles skaliert mit der Größe des Speicherinterfaces (pro Kanal des Speicherinterfaces ein Tile, Hawaii hat 16 Kanäle zu je 32Bit, Fiji 32 Kanäle zu je 128Bit). Und bei GCN hat jeder L2-Tile eine Bandbreite von 64 Byte (512Bit = 1 Cacheline) pro Takt. Hawaii hat also etwa 1 TB/s L2-Bandbreite, Fiji hat ~2 TB/s.
Das Ganze läuft über eine beinahe schon monströs zu nennende Crossbar, der 32 L2-Tiles, 64 L1-vD$, 16 L1-I$ und 16 L1-sD$ verbindet (jeweils mit 64Byte/Takt Bandbreite, also insgesamt 128 Clients mit je 512 Datenleitungen :freak:). Die L2-Tiles sowie die vD$ und sD$ können in beide Richtungen über die Crossbar kommunizieren, die L1-I$ sind read-only Clients an der Crossbar. Die ROPs haben noch extra-Caches und eine eigene Export-Crossbar von den CUs. Das läuft also nicht über die L1-L2-Struktur.

*):
Alle GCN-GPUs haben entweder 64kB oder 128kB pro L2-Tile. Außer der Kapazität ändert sich aber sonst nichts (also weder Geschwindigkeit noch Assoziativität).

Lemon Wolf
2015-07-16, 16:36:33
@Gipsel Das klingt wirklich sehr intressant.Leider habe ich nur einen Teil vom dem verstanden was du da geschrieben hast. Vielleicht könntest du ja so ein FAQ schreiben? Das Wissen hast du ja definitiv.

Novum
2015-07-16, 16:40:33
Das Ganze läuft über eine beinahe schon monströs zu nennende Crossbar, der 32 L2-Tiles, 64 L1-vD$, 16 L1-I$ und 16 L1-sD$ verbindet (jeweils mit 64Byte/Takt Bandbreite, also insgesamt 128 Clients mit je 512 Datenleitungen :freak:). Die L2-Tiles sowie die vD$ und sD$ können in beide Richtungen über die Crossbar kommunizieren, die L1-I$ sind read-only Clients an der Crossbar. Die ROPs haben noch extra-Caches und eine eigene Export-Crossbar von den CUs. Das läuft also nicht über die L1-L2-Struktur.
Bist du sicher, dass das eine volle Crossbar ist?

Ich bin mir nicht so sicher, ob es da nicht doch einen Zusammenhang zwischen CU-Clustern und ROPs gibt. Kann ja auch einfach sein, dass nur für den Normalfall die volle Bandbreite da ist, sonst weniger. Aber dunno.

Nakai
2015-07-16, 16:49:45
Bist du sicher, dass das eine volle Crossbar ist?

Ich bin mir nicht so sicher, ob es da nicht doch einen Zusammenhang zwischen CU-Clustern und ROPs gibt. Kann ja auch einfach sein, dass nur für den Normalfall die volle Bandbreite da ist, sonst weniger. Aber dunno.

Bis zu Hawaii war das eine vollständige Crossbar. Zu Fiji könnte etwas zu Hotchips kommen. Ich gehe davon aus, dass es eine vollständige Crossbar ist. Außerdem wäre es komisch, wenn bestimmte Backend-Ressourcen nur "mies" angesprochen werden können. Ein Teil der Backend-Ressourcen wurden ja seit Hawaii innerhalb der ShaderEngines verlagert, siehe die Lage der RBEs.

Gipsel
2015-07-16, 17:34:37
Bist du sicher, dass das eine volle Crossbar ist?

Ich bin mir nicht so sicher, ob es da nicht doch einen Zusammenhang zwischen CU-Clustern und ROPs gibt. Kann ja auch einfach sein, dass nur für den Normalfall die volle Bandbreite da ist, sonst weniger. Aber dunno.Die L1-L2-Geschichten muß eine volle Crossbar sein, das geht nicht anders (wenn man keine zwei Level einführen will, also zwischen L2 und Speichercontroller noch mal Crossbars einziehen will [wodurch es dann effektiv eine volle wird], momentan ist das direkt gemappt [deswegen auch die Übereinstimmung der Anzahl der L2-Tiles mit den Speicherkanälen]).
Aber bei den ROPs kann man gegebenenfalls etwas sparen. Hier dürfte es aber zumindest innerhalb jeder Shader-Engine jeweils eine Export-Crossbar zwischen allen CUs und den dazugehörigen RBEs geben (also bei Fiji 4 Engines, jede mit einer Crossbar, die 16 CUs und 4 RBEs als Clients verbindet). Zwischen den RBEs und den Speichercontrollern gibt es dann gegebenenfalls das nächste Crossbar-Level (höchstwahrscheinlich ebenfalls nicht voll, sondern mehrere kleinere parallel). Hier kann man davon profitieren, daß das Layout der Rendertargets im Speicher entsprechend klug gewählt werden kann, so daß nicht jede CU unbedingt an alle Speicheradressen einen Export durchführen können muß. Das geht bei der L1-L2-Struktur nicht. Jede CU muß jede beliebige Adresse lesen (und über vector und scalar memory Instruktionen auch schreiben) können. Diese laufen über die L1-L2-Struktur, nicht über die ROPs.

Digidi
2015-07-16, 18:21:47
Was ja bei FIJI auch immer wieder bemängelt wird, ist die Geometrie- und Tessellation- Leistung. Vielleicht mangelt es Fury X daran. Aber dann verstehe ich nicht wie die Pixelfüllrate dann so hoch sein kann wenn ja keine Polygonen in Pixel umgesetzt werden?

Gipsel
2015-07-16, 20:06:01
Aber dann verstehe ich nicht wie die Pixelfüllrate dann so hoch sein kann wenn ja keine Polygonen in Pixel umgesetzt werden?
Du brauchst lediglich größere Dreiecke, also welche mit mehr Pixel pro Dreieck ;).

Digidi
2015-07-16, 20:30:13
Danke erst mal Gipsel für die ganzen Infos. Wäre das hier Facebook hättest du bestimmt schon 1.000.000 likes :-)

Wie ist das eigentlich mit den Polygonen? AMD kann 2,3 Gigapolygonen/s im schlechtesten fall auswerfen.
Siehe Test:
http://techreport.com/review/28513/amd-radeon-r9-fury-x-graphics-card-reviewed/4

Der Worst case ist ja wenn das Polygon so groß ist wie ein Pixel. (Mehr bringt ja nichts für die Auflösung und die die Polygonen die verdeckt sind werden ja rausgerechnet) Das heißt es gibt dann 8,3 Millionen Polygonen. Bei derLeistung von 2,3 Gigapolygonen/s könnte FIJI ja dann immer noch 230 FPS auswerfen.

Screemer
2015-07-16, 21:16:49
dazu mal ein quote, der mir immer gut gefällt wenn die diskussion um übermäßige tesselation startet

Man muss dabei aber erwähnen, dass die sichtbaren Unterschiede ab Faktor 16 mit der Lupe zu suchen sind - mit Faktor 64 sind die Polygone kleiner als ein Pixel, wenn man kein vernünftiges LOD implementiert, was dann natürlich Performanceverschwendung pur ist. Für Hairworks (und die meisten anderen tessellierten Objekte) hätte daher auch Faktor 16 gereicht. Nvidia nutzt aber dennoch praktisch immer Faktor 64 weil ...... darüber darf sich jetzt jeder selbst eine Meinung bilden. ob das allerdings so ist oder nicht kann ich nicht beurteilen. sollte dem so sein halte ich x64 als tessfaktor für totalen quark.

AwesomeSauce
2015-07-16, 22:18:57
mit Faktor 64 sind die Polygone kleiner als ein Pixel
Absoluter Quark, natürlich kommt es auf die Auflösung des Ausgangsmesh an und wie nah man am Mesh dran ist...

EDIT: Weiss jemand, ob das mittlerweile in GPUs umgesetzt ist? http://graphics.stanford.edu/papers/fragmerging/shade_sig10.pdf

Digidi
2015-07-16, 22:29:33
So unrecht hat er nicht. Wenn ein Weit entferntes Objekt mit 64x tesselliert wird macht das keinen sin. Es macht dan auch keinen Sin überhaupt was an dem weit entfernten Objekt zu berechnen wenn das Objekt nur als Pixel erscheint. Genau das soll ja das LOD aussortieren. Aber das macht Nvidia gerade nicht mit Gameworks da Nvidia hier Hardwaremäßig genug Leistung bringt um auch weitentfernte Objekte zu tessellieren. Da AMD weniger Tesselationleistung hat verlieren die hier im sehr großen Umfang.

Im übrigen meint 64x Tessellation das ein Polygon noch mal in 64 kleinere Polygone unterteilt wird.

AwesomeSauce
2015-07-16, 22:39:31
Das hat mir Hairworks wenig zu tun, wohl eher mit der Implementierung von CDPR. HW 1.1 hat auf jeden fall ein LOD:
http://abload.de/img/hworkskhqyf.png (http://abload.de/image.php?img=hworkskhqyf.png)

Im übrigen meint 64x Tessellation das ein Polygon noch mal in 64 kleinere Polygone unterteilt wird.
Was hat das mit der Grösse der Dreiecke zu tun, die dann am Ende rauskommen?

Digidi
2015-07-16, 22:43:31
Kommt von der CPU ein großes Dreieck werden diese nur ein mittlere Dreiecke zerlegt. Kommt von der CPU ein kleines Dreieck dann wird das Dreieck in sehr kleine Dreiecke unterteilt. Je kleiner das Dreieck ist welches auf Pixel umgelegt werden soll, desto ineffizienter ist das. Bei kleinen Polygonen die schon fast Pixelgröße haben noch mal eine Aufteilung auf 64 kleiner Polygonen zu machen ist also hier überflüssig.

Auf deinem Bild erkennt man gut das Übertessellieren. Die Polygonen sind schon kleiner als ein Pixel. Man erkennt sie nicht mehr und das ist sehr ineffizient.

AwesomeSauce
2015-07-16, 22:45:16
Schon klar, ich wollte einfach darauf hinaus, dass ein Faktor von 64 nicht zwangsweise zu Mikrodreiecken (also solche die weniger als 4 Pixel beinhalten) führt, auch abgesehen von HairWorks. Man muss da differenzieren. Ob Tesselation überhaupt benutzt werden sollte für Haare, ist natürlich eine andere Frage.

Ravenhearth
2015-07-16, 22:52:06
Dass Fiji so schlecht skaliert, könnte ganz einfach an der Zahl der Shader-Engines liegen. Die sind vergleichbar mit den SMX bei Nvidia, aber mit dem Unterschied, dass sie intern nochmal etwas feiner in CUs aufgeteilt sind.
Tahiti, Tonga, Hawaii und Fiji haben alle 4 Shader-Engines, aber die Zahl der CUs pro Shader-Engine ist unterschiedlich: Tahiti und Tonga kommen auf 8, Hawaii auf 11, Fiji auf 16. Je mehr da sind, desto schwieriger wird es, die Leistung abzurufen.
Wenn ich Mist erzähle, möge man mich korrigieren.

Novum
2015-07-16, 22:54:13
Absoluter Quark, natürlich kommt es auf die Auflösung des Ausgangsmesh an und wie nah man am Mesh dran ist...

EDIT: Weiss jemand, ob das mittlerweile in GPUs umgesetzt ist? http://graphics.stanford.edu/papers/fragmerging/shade_sig10.pdf
Soweit ich weiß nicht. GCN macht es jedenfalls nicht. Würde wohl auch gegen die API-Specs verstoßen. Und es erzeugt auch jede Menge unkontrollierbares Verhalten, weil die Buffer nur endlich groß sein können. Wenn Dreiecke im Index-Buffer nahe zusammen sind würden sie zusammen gerastert, sonst nicht. Ich will das gar nicht haben.

Deferred Shading löst das Problem zu einem guten Stück, weil das Shading eben deferred ist und nicht beim eigentlichen Dreiecks-Zeichnen gemacht wird.

Troyan
2015-07-17, 00:35:19
TressFX benutzt ebenfalls Polygone, die kleiner als ein Pixel sind.
Was man nicht alles aus dem PDF innerhalb des Ordners alles herauslesen kann. :freak:

Ob Tesselation überhaupt benutzt werden sollte für Haare, ist natürlich eine andere Frage.

Vergleiche doch einfach den Hairworks 1.1 Viewer mit TressFX 2.2. In vielen Bereichen ist Hairworks TressFX überlegen:
Bessere Leistung bei gleicher Anzahl an Haaren, wesentlich flexibler und deutlich weniger Speicherverbrauch (das SDK genehmigt sich 2GB! in 1440p...)

/edit: Ha, in 5K reichen die 6GB für TressFX2.2 nicht mehr, um die Buffer bzw. die PerPixelLinkList zu erstellen. In 4K braucht das SDK schon 4GB...

Gipsel
2015-07-17, 00:50:57
EDIT: Weiss jemand, ob das mittlerweile in GPUs umgesetzt ist? http://graphics.stanford.edu/papers/fragmerging/shade_sig10.pdfIst es nicht.
Das geht auch nicht so einfach, weil das Ergebnis anders aussieht. Ist zwar meist nah dran, es gibt aber Artefakte. Also kann man das nicht einfach mal so machen.
Im übrigen meint 64x Tessellation das ein Polygon noch mal in 64 kleinere Polygone unterteilt wird.Nee, das sind viel mehr. Die Tessfaktoren geben an, wie oft die Kanten des Dreiecks (oder des Quads) unterteilt werden. Die Details sind etwas tricky (man kann für jede Kante einzeln einen Faktor angeben sowie noch einen bzw. zwei für das Innere, also man benötigt 4 Faktoren für ein Dreieck und 6 Faktoren für ein Quad), aber grob skaliert die Anzahl der resultierenden Dreiecke quadratisch mit den Tessfaktoren (für Quad-Domain, ganzzahligen Faktoren und alle 6 Faktoren identisch, paßt es genau mit quadratisch). Es kommen also viel mehr Dreiecke bei hohen Faktoren heraus, nicht nur 64 mal so viele. Tessfaktor 4 heißt also 16 mal so viele Dreiecke, Tessfaktor 8 heißt bereits 64 mal so viele Dreiecke und so weiter bis zu etwa 4000 mal so viele bei den höchsten Faktoren.

Digidi
2015-07-17, 01:22:41
Danke Gipsel für die Info.

Das heißt dann Grob:
Bei einem Spiel mit 10.000 Polygonen von der CPU hätte man dann 40 Millionen Polygonen nach 64x Tesselation. Das wäre 4 Fach kleiner Dreiecke als ein Pixel bei UHD Auflösung und deshalb ist 64x Tesselation sinnlos.



Wie ist das eigentlich mit den Polygonen? AMD kann 2,3 Gigapolygonen/s im schlechtesten fall auswerfen.
Siehe Test:
http://techreport.com/review/28513/amd-radeon-r9-fury-x-graphics-card-reviewed/4

Der Worst case ist ja wenn das Polygon so groß ist wie ein Pixel. (Mehr bringt ja nichts für die Auflösung und die die Polygonen die verdeckt sind werden ja rausgerechnet) Das heißt es gibt dann 8,3 Millionen Polygonen. Bei derLeistung von 2,3 Gigapolygonen/s könnte FIJI ja dann immer noch 230 FPS auswerfen.
Lieg ich eigentlich hiermit richtig Gipsel?

AwesomeSauce
2015-07-17, 09:33:53
Das wäre 4 Fach kleiner Dreiecke als ein Pixel bei UHD Auflösung und deshalb ist 64x Tesselation sinnlos.
Meine Güte, ich habs doch oben schon gepostet. Du musst die Auflösung des Ausgangsmesh berücksichtigen.

Ich habe in Büchern bereits gelesen, dass selbst 64x tess manchmal zu wenig ist, um anständiges Displacement Mapping zu machen. Das sture "64x tess ist sinnlos" muss aufhören.



EDIT:
Hier siehst du, was ich meine: Auch mit 64x tess sind die Dreiecke nahe am Viewer immer noch sehr gross.

http://abload.de/thumb/tesspqpe6.png (http://abload.de/image.php?img=tesspqpe6.png)

Achill
2015-07-17, 10:57:57
Ich habe nur wenig Ahnung von den aktuellen Details, vor Jahren habe ich mal Snake mit OpenGL 1.2 umgesetzt und mit viel Staunen die Dinge auf http://www.humus.name verfolgt ... bin also schon etwas raus ... :D

Mit meinen 'gesunden Menschenverstand' würde ich behaupten, dass es hier natürlich ein LOD geben muss, was über den Grade der Tessellation in Abhängigkeit der Distanz des Betrachters / der Größe des sichtbaren Dreiecke entscheidet, vielleicht sowas http://victorbush.com/2015/01/tessellated-terrain/?

@AwesomeSauce, ist hier nicht der Detail-Grad der Displacement Map in der Nähe zu gering?

=> Leienhaft würde ich behaupten, dass mehr Tess nicht autom. den Informationsgehalt erhöhen kann, da diese von der Displacement Map zur Verfügung gestellt wird. Die Displacement Map benötigt also eine höher Auflösung bzw. es müssen mehr Displacement Maps kombiniert verwendet werden?

=> Der Informationsgehalt ist auch Begrenzt bzgl. der kleinst möglichen Darstellung oder?, alles was kleiner als ein Pixel ist, kann doch gar nicht mehr auf unseren Monitor dargestellt werden.

=> Würden nicht Subpixel-Strukturen zu Flimmern in der Bewegung führen Aufgrund der hohen Frequenz und dem Raster-Prozess?

StefanV
2015-07-17, 11:09:58
Ich habe in Büchern bereits gelesen, dass selbst 64x tess manchmal zu wenig ist, um anständiges Displacement Mapping zu machen. Das sture "64x tess ist sinnlos" muss aufhören.Und weil das irgendwer mal irgendwo auf Papier gebracht hat, muss es die Ultimative Wahrheit sein?!

Und nach den Ausführungen von Gipsel würde ich auch nicht gerade deinen Standpunkt unterstützen wollen, ganz im Gegenteil!

Kurz:
64x Tesselation ist völliger Bullshit!
Und für Haare macht es gleich mal -50 Sinn, das haben schon einige Leute mehrfach gesagt...

So muss man dir dann doch unterstellen, dass du hier einfach nur ein Fähnchen schwingen möchtest...
Denn irgendwelche Argumente oder Fakten hast du bisher ja auch nicht gebracht, nur irgendwelche unbelegten Behauptungen aufgestellt.

AwesomeSauce
2015-07-17, 11:17:56
Mit meinen 'gesunden Menschenverstand' würde ich behaupten, dass es hier natürlich ein LOD geben muss, was über den Grade der Tessellation in Abhängigkeit der Distanz des Betrachters / der Größe des sichtbaren Dreiecke entscheidet

Natürlich, und es ist ja auch ein LOD eingebaut, sowohl in HairWorks, als auch in der TerrainTess Demo von vorhin. Da kann man sogar direkt einstellen, wie viele Pixel ein Dreieck im Screen-Space umfassen darf. Der Tess-Grad wird dann automatisch angepasst. Ich wollte nur zeigen, dass ein 64er Faktor eben nicht sinnlos ist.


@AwesomeSauce, ist hier nicht der Detail-Grad der Displacement Map in der Nähe zu gering?

Ich bin mir nicht ganz sicher, was du meinst. Die Grösse der Dreiecke hängt ja nicht von der Displacement Map ab. Eher bestimmt der Tess-Faktor, ob die Displ. Map detailgetreu abgebildet werden kann.

Langsam bin ich mir nicht mehr sicher, ob das On Topic ist :confused:

EDIT:
Und weil das irgendwer mal irgendwo auf Papier gebracht hat, muss es die Ultimative Wahrheit sein?!
Ja, GPU Pro 3 Artikel sollte man nicht für voll nehmen
http://abload.de/img/tess2etr1p.png (http://abload.de/image.php?img=tess2etr1p.png)

So muss man dir dann doch unterstellen, dass du hier einfach nur ein Fähnchen schwingen möchtest...
Denn irgendwelche Argumente oder Fakten hast du bisher ja auch nicht gebracht, nur irgendwelche unbelegten Behauptungen aufgestellt.
Soso, Artikel und Bilder die genau das belegen, was ich sage, sind keine Argumente.

Achill
2015-07-17, 11:44:47
...
Ich bin mir nicht ganz sicher, was du meinst. Die Grösse der Dreiecke hängt ja nicht von der Displacement Map ab. Eher bestimmt der Tess-Faktor, ob die Displ. Map detailgetreu abgebildet werden kann.

Langsam bin ich mir nicht mehr sicher, ob das On Topic ist :confused:
...


Basierend auf Wikipedia / Displacement_Mapping (https://de.wikipedia.org/wiki/Displacement_Mapping) meine ich, dass jeder Pixel der Height-Map einen Informationsgehalt hat. Dieser ist insgesamt begrenzt durch die Auflösung der Textur. Mein Behauptung war, dass wenn jeder Punkt den Punkten der Tesselationsdreiecke entspricht, dann eine höhere Tesselation kein sinn mehr macht.

Will man mehr Details, so muss man eine höhere Auflösung der Height-Map nehmen oder diese nebeneinander Kombinieren (k.a. ob das ohne weiteres geht).

Ich bezog mich dabei auf das von dir gepostete Bild und den "wenigen" Dreicken im Vordergrund: Bild (http://abload.de/image.php?img=tesspqpe6.png) ... meine Annahme ist, dass die dort zu sehende Oberfläche natürlich mit einer Height-Map erzeugt wird und diese nur einer begrenzten Auflösung hat. Dies kann in der nähe zu "großen" Dreicken führen da man bezogen auf die Pixel der Map nah ist.

OT: Ja wahrscheinlich...

Digidi
2015-07-17, 12:54:42
Meine Güte, ich habs doch oben schon gepostet. Du musst die Auflösung des Ausgangsmesh berücksichtigen.

Ich habe in Büchern bereits gelesen, dass selbst 64x tess manchmal zu wenig ist, um anständiges Displacement Mapping zu machen. Das sture "64x tess ist sinnlos" muss aufhören.



EDIT:
Hier siehst du, was ich meine: Auch mit 64x tess sind die Dreiecke nahe am Viewer immer noch sehr gross.

http://abload.de/thumb/tesspqpe6.png (http://abload.de/image.php?img=tesspqpe6.png)

Dein Bild ist der Inbegriff von über Tessellation. Schau Dir nur die ganz schwarzen stellen auf dem Bild an. Das ist total über tesseliert. An der Front könnte es wirklich ein paar Dreiecke dafür mehr haben. Spricht für ein schlechtes LOD

AwesomeSauce
2015-07-17, 13:10:15
Es ist doch offensichtlich, dass da kein LOD aktiviert war? Das waren harte 64x überall. Mit aktiviertem LOD kann man die gewünschte Grösse für Dreiecke einstellen. An der Front kannst du aber nicht mehr Dreiecke haben, eben weil das einen Faktor > 64 benötigte...

z3ck3
2015-07-17, 14:17:27
Meine technische Unwissenheit sagt mir:

Wenn ich ein Dreieck oder Quadrat habe das den halben Bildschirm füllt, dann ist Faktor 64 in der Tat zu niedrig um dieses in ein naürlich wirkenden Terrain zu "zerteilen". Das Ausgangsmaterial ist also schon bescheiden ;) Ich glaube hier ging es aber mehr um Hairworks, nicht um große Flächen. ^^


P.s: @Gipsel Danke für die Info, hatte irrtümlicherweise im Hinterkopf das Hawaii bereits 2MB L2 hatte, sind aber ja nur 1MB ^^

Novum
2015-07-17, 14:30:45
64x Tesselation ist völliger Bullshit!
Wenige Sachen wofür alle 3 IHVs und Microsoft stimmen um sie in den DirectX-Standard aufzunehmen sind "völliger Bullshit".

Mr. Lolman
2015-07-17, 17:35:16
64x Tessellation sind per se sicher nicht unnötig. Wir sind uns aber hoffentlich einig, dass sowas einfach nur idiotisch ist, oder?

http://www.extremetech.com/extreme/173511-nvidias-gameworks-program-usurps-power-from-developers-end-users-and-amd/2

http://abload.de/thumb/benchmarkwireframe-grvzuhd.jpg (http://abload.de/image.php?img=benchmarkwireframe-grvzuhd.jpg)
http://abload.de/thumb/cape-benchmark-standao4o5q.jpg (http://abload.de/image.php?img=cape-benchmark-standao4o5q.jpg)

http://techreport.com/review/21404/crysis-2-tessellation-too-much-of-a-good-thing/2

http://abload.de/thumb/newbarrier-meshewqt3.jpg (http://abload.de/image.php?img=newbarrier-meshewqt3.jpg)

IYL07c74Jr4

AwesomeSauce
2015-07-17, 19:18:11
Absolut :) Es gibt ja LOD Systeme in den Samples. Ich weiss nicht, warum das (anscheinend oft) nicht genutzt wird.

Troyan
2015-07-17, 19:51:18
Und jetzt bitte ohne Wireframe-Bilder.

Gimmick
2015-07-18, 12:06:05
Und jetzt bitte ohne Wireframe-Bilder.

:|

Wie willst du ohne Wireframe sehen ob z.B. ebene Flächen aus edlichen Polygonen bestehen?

Troyan
2015-07-18, 19:52:11
Mit dem Wireframe-Modus siehst du alle Dreiecke - also auch die, die durch Hull-Shader und vor dem Rasterizing wegecullt werden.

Gimmick
2015-07-18, 20:42:25
Mit dem Wireframe-Modus siehst du alle Dreiecke - also auch die, die durch Hull-Shader und vor dem Rasterizing wegecullt werden.

Seh ich ein ist blöd, spielt aber hier jetzt keine große Rolle.
Es ändert ja nichts daran, dass (in Mr. Lolmans Post) plane Flächen sehr viele Polys aufweisen und es kein LOD gibt.

Ich glaube auch nicht, dass bei Batmans Umhang irgendwas geculled wird, das gäbe sicher Probleme mit der Darstellung wenn er sich bewegt.

Novum
2015-07-19, 13:19:08
Mit dem Wireframe-Modus siehst du alle Dreiecke - also auch die, die durch Hull-Shader und vor dem Rasterizing wegecullt werden.
Der Hull-Shader cullt nicht, der legt den Tesselationsgrad und die Tesselations-Parameter fest.

Wireframe ist sehr wohl ein sehr guter Indikator für die absurde Vertexlast die da anfällt.

Digidi
2015-07-27, 01:36:19
Mal eine Frage wenn die Polygonen so groß sind wie ein Pixel bei UHD sollte Fiji 1 Pixel pro Takt und rastrierter raushauen. Das wären bei 4 rasterizer und Takt von 1050MHz 4.200.000.000 Pixel. Bei UHD wären das dann ca. 400 fps. Selbst wenn es sich um ein schlechtes Verfahren handelt was die fps um die Hälfte halbiert wäre man immer noch bei 200 fps. Wieso sagt man dann das das Frontend limitiert?

Ravenhearth
2015-07-27, 01:52:01
Weil das Front-End nicht nur aus Rasterizern besteht.

Digidi
2015-07-27, 03:37:55
Mal eine Frage welches Polygonenformat wird den am meisten verwendet! List oder Strip:
http://techreport.com/review/28513/amd-radeon-r9-fury-x-graphics-card-reviewed/4