Warum gibt es Performanceunterschiede zwischen OGSSAA und SGSSAA [Split]?

[aufkrawall]

Ist auch mal die Frage, ob bei 1080p 4xSGSSAA die 7970 GE überhaupt noch schneller als eine 680 ist.

[robbitop]

Warum nicht? Das Pixel/Geometrieverhältnis ändert sich doch genauso wie bei hohen Auflösungen. Das sollte der Radeon generell zu gute kommen (SGSSAA).

[boxleitnerb]

Sollte, aber die GCN-Radeons büßen mit SGSSAA im Vergleich zu Geforces mehr Performance ein, teils deutlich. Gibt ein paar Ausnahmen, aber in den meisten Benches, die ich bei Computerbase oder hier im Forum gesehen habe, ist es so.

[Raff]

Yop, seit Kepler schneidet Nvidia mit SGSSAA prozentual besser ab.

MfG,
Raff

[robbitop]

Bei höheren Auflösungen hingegen nicht. Kann mal ein Experte erklären, warum das so sein könnte? Coda, Demi, Skysnake, Gipsel, RLZ, aplha..? Anyone? :)

[fondness]

Bei höheren Auflösungen hingegen nicht. Kann mal ein Experte erklären, warum das so sein könnte? Coda, Demi, Skysnake, Gipsel, RLZ, aplha..? Anyone? :)

Weil es ein Unterschied ist ob du ein Dreieck mit höherer Auflösung berechnest oder ein Dreieck x-mal berechnest. Im ersteren Fall reduziert sich der Verschnitt bei AMD stärker als bei NV.

[Skysnake]

Bei höheren Auflösungen hingegen nicht. Kann mal ein Experte erklären, warum das so sein könnte? Coda, Demi, Skysnake, Gipsel, RLZ, aplha..? Anyone? :)
Puh... Da kanns unglaublich viele Gründe für geben :ugly:

Am ehesten würde ich aber auf eine effizientere Treiberimplementierung bei nVidia tippen. Das ist aber nur ein Tip! Ich kann dazu nicht wirklich etwas sagen, da mir jetzt die genauen Unterschiede auch nicht 100% klar sind. Ist halt ein Bauchgefühl von mir.

[Gipsel]

Weil es ein Unterschied ist ob du ein Dreieck mit höherer Auflösung berechnest oder ein Dreieck x-mal berechnest. Im ersteren Fall reduziert sich der Verschnitt bei AMD stärker als bei NV.Ja, das stimmt. Das wirft natürlich die Frage auf, ob man mit entsprechender Optimierung nicht auch die mit gedrehter (oder bei höheren AA-Modi auch beliebiger) Samplemaske erzeugten Fragments direkt ohne Performanceverlust in die Wavefront einsortieren könnte, so daß der Effizienzvorteil von mehr Fragments pro Dreieck voll erhalten bleibt. Das würde ein wenig Rumtricksen an den Rasterizern und entsprechend auch beim Export zu den ROPs sowie bei der Interpolation erfordern. Keine Ahnung, warum das AMD offenbar nicht macht. Aber vermutlich hat das auch noch ein oder zwei Nebeneffekte, an die ich im Moment nicht denke und durch die das dann komplizierter wird.

[PCGH_Carsten]

Da untypischerweise die Performanceschere zwischen Geforce und Radeon beim Schritt von 4x auf 8x bei Supersampling weiter zugunsten der Geforce aufgeht - beim Multisampling ist es normalerweise anders herum - ist meine Vermutung, dass die Radeon unter Supersample-AA Effizienz beim HSR einbüßt oder es komplett verliert.

Eine Möglichkeit wäre auch, dass die Z-Kompression nicht oder nur schlecht arbeitet. Aufgrund meiner Messungen würde ich das allerdings für voll komprimierbare Tiles (evtl. Fragmente) ausschließen wollen. In Synthies die reinen Z-Durchsatz ohne Color-Buffer messen, tritt das nämlich kaum auf, wohl aber in realen, d.h. normal texturierten Szenen.

Es gibt auch Unterschiede zwischen Außen- und Innenabschnitten, in ersteren erzielt die Geforce einen höheren Vorsprung bei dem was ich gemessen habe. Hier spielt das Level-HSR (Portalling, wenn die UE sowas nutzt) dann wieder eine Rolle. Leider sind meine Werte knapp ein Jahr alt und nicht vollständig, hatte keine Zeit, das zu Ende zu testen.

[del_4901]

Vllt. ist es auch einfach nur eine geringere ROP-Export Bandbreite die GCN zu schaffen macht? Z-Kompression habe ich auch ueberlegt, die muesste bei hoehrerer Aufloesung eigentlich besser arbeiten, da man ja weniger Dreiecke pro Flaeche hat. Aber vllt. ist es aber auch einfach nur der OnChip Speicher fuer HiZ der dann einfach nicht mehr ausreicht?

[Skysnake]

Oder eben schlicht der Treiber. Der Umstieg VLIW -> SIMD ist kein kleiner. Man hat ja an dem "Wundertreiber" gesehen, wie viel Potenzial noch in der Architektur steckt.

nVidia arbeitet schon seid zich Jahren mit SIMD. Ich möchte wirklich nicht wissen, was da noch an ungenutzem Potenzial steckt, wenn selbst bei so "0815" Bereichen noch so viel raus zu holen ist. Um SSAA usw wird man sich wohl erst intensiv kümmern, wenn die 0815 Sachen anständig performen.

[del_4901]

Oder eben schlicht der Treiber. Der Umstieg VLIW -> SIMD ist kein kleiner. Man hat ja an dem "Wundertreiber" gesehen, wie viel Potenzial noch in der Architektur steckt.

nVidia arbeitet schon seid zich Jahren mit SIMD. Ich möchte wirklich nicht wissen, was da noch an ungenutzem Potenzial steckt, wenn selbst bei so "0815" Bereichen noch so viel raus zu holen ist. Um SSAA usw wird man sich wohl erst intensiv kümmern, wenn die 0815 Sachen anständig performen.
Der Treiber, rly? Erklaeung bitte.

[PCGH_Carsten]

Wie ich es auch drehe und wende, mir fällt nichts sinnvolles ein, was bei Multisample-AA noch gut funktioniert, aber bei Supersample-AA dann versagen müsste. Auch die nur halbe ROP-MC-Crossbar in Tahiti dürfte da nicht so extrem limitieren.

[Skysnake]

Der Treiber, rly? Erklaeung bitte.
Naja, du musst das ja irgendwie auf die Hardware mappen. Wenn man da die Aufgaben scheise verteilt auf die Hardwareressourcen kann man die Caches nicht effektiv nutzen. Da gibts also durchaus genug Möglichkeiten Leistung zu verblasen.

Ansonsten weiß man bei den beiden auch NIE, ob Sie nicht ziemlich bösartig in die Trickkiste greifen, und irgendwelchen fancy Scheis veranstalten, der auf böses gecheate raus läuft, was man aber in 99,9999% der Fälle halt nicht sieht...

Ich glaub mir müssen uns nicht an die Exzesse erinnern die beide zeitweise betrieben haben...

[robbitop]

Weil es ein Unterschied ist ob du ein Dreieck mit höherer Auflösung berechnest oder ein Dreieck x-mal berechnest. Im ersteren Fall reduziert sich der Verschnitt bei AMD stärker als bei NV.
Das habe ich mir auch schon fast gedacht. Und danke an alle, die so schnell geantwortet haben. :up:

Es liegt ja sehr nahe. Aber auch da frage ich nochmal ganz naiv: warum?

Muss ich für jedes Sample auf einem Dreieck noch mal rastern und transformieren? Da liegt doch der Flaschenhals von Tahiti oder?

Vieleicht kann jemand nochmal ein wenig genauer auf diesen Unterschied (siehe Fondues) eingehen? :)

[OgrEGT]

Man sollte aber anstatt pauschal etwas zu unterstellen besser Ross und Reiter nennen bevor man dies tut und auch nur wenn man begründeten Verdacht dazu hat. In diesem Fall was könnten diese Treiber Optimierungen sein? Dass man statt 2xSSAA vorsätzlich nur "1,5" SSAA berechnet? Das müsste man doch nachweisen können oder?

[Spasstiger]

@OgrEGT: Es geht um SGSSAA, nicht Downsampling.

SGSSAA funktioniert aus Treibersicht imo wie MSAA, nur dass eben für jedes Fragment der Farbwert bestimmt wird. Es ist einfach nur der mittlere Rechenaufwand pro Fragment erhöht.
Eine schlechte SGSSAA-Implementierung müsste auch an einer schlechten MSAA-Performance erkennbar sein.
Dass GCN durch hohe Auflösungen im Vergleich zu Kepler weniger stark einbricht als durch SGSSAA, ist nicht verwunderlich, da eben durch SGSSAA die Dreieckgröße NICHT ansteigt und der Rasteraufwand pro Pixel NICHT sinkt. Hohe Auflösungen dagegen bedeuten größere Dreiecke, damit ein reduzierter Rasteraufwand pro Pixel und damit eine Lastverschiebung in Richtung Rechenwerke. Diese Lastverschiebung lässt GCN im Vergleich zu Kepler etwas besser aussehen.

Effizienter ist übrigens trotz allem SGSSAA, auch bei GCN. D.h. bei vergleichbarer Bildqualität (LOD-Bias-Anpassung berücksichtigt, Postprocessing-Unschärfe außen vor) liefert SGSSAA die höheren Frameraten.

[OgrEGT]

@OgrEGT: Es geht um SSAA, nicht Downsampling.

SGSSAA funktioniert aus Treibersicht imo wie MSAA, nur dass eben für jedes Fragment der Farbwert bestimmt wird. Es ist einfach nur der mittlere Rechenaufwand pro Fragment erhöht.
Eine schlechte SGSSAA-Implementierung müsste auch an einer schlechten MSAA-Performance erkennbar sein.
Dass GCN durch hohe Auflösungen im Vergleich zu Kepler weniger stark einbricht als durch SGSSAA, ist nicht verwunderlich, da eben durch SGSSAA die Dreieckgröße NICHT ansteigt und der Rasteraufwand pro Pixel NICHT sinkt. Hohe Auflösungen dagegen bedeuten größere Dreiecke, damit ein reduzierter Rasteraufwand pro Pixel und damit eine Lastverschiebung in Richtung Rechenwerke. Diese Lastverschiebung lässt GCN im Vergleich zu Kepler etwas besser aussehen.

Effizienter ist übrigens trotz allem SGSSAA, auch bei GCN. D.h. bei vergleichbarer Bildqualität liefert SGSSAA die höheren Frameraten.
War ja nur ein Beispiel... Mit "1,5" meinte ich einfach dass nicht die vorgeschriebene Anzahl an Samples berechnet wird...

[Skysnake]

Das meinte ich jetzt nicht mal.

Man kann sich ja aber Gedanken machen, wie man jetzt die Samples verteilt, und in welcher Reihenfolge, und ob man nicht vielleicht doch Samples einsparen kann, weil man weiß, das man Sie nicht braucht usw usw.

Oder schon allein, wie man eben die Samples berechnet, also wie man das auf die Hardware mapped. Je nachdem kann man es eben geschickt oder ungeschickt machen, was dann eben die Caches flushed, oder halt unnötige Zugriffe generiert.

An einen "Flaschenhals" der sich da plötzlich auftut, glaub ich eher weniger.

[OgrEGT]

Das meinte ich jetzt nicht mal.

Man kann sich ja aber Gedanken machen, wie man jetzt die Samples verteilt, und in welcher Reihenfolge, und ob man nicht vielleicht doch Samples einsparen kann, weil man weiß, das man Sie nicht braucht usw usw.

Oder schon allein, wie man eben die Samples berechnet, also wie man das auf die Hardware mapped. Je nachdem kann man es eben geschickt oder ungeschickt machen, was dann eben die Caches flushed, oder halt unnötige Zugriffe generiert.

An einen "Flaschenhals" der sich da plötzlich auftut, glaub ich eher weniger.

Das würde ich aber nicht als "cheaten" verstehen...

[fondness]

Es liegt ja sehr nahe. Aber auch da frage ich nochmal ganz naiv: warum?


Der Punkt ist die Warp-Größe. AMD hat 8x8 Pixel (64 Pixel) Warps, NV 4x8 Pixel (32 Pixel). Dh bei sehr kleinen Dreiecken sind bei AMD ein Großteil der Warps/Threads leer. Erhöhe ich jetzt die Pixel pro Dreieck durch eine höhere Auflösung, steigt die Auslastung speziell bei AMD natürlich deutlich an, der Verschnitt reduziert sich viel stärker als bei NV die deutlich feingranularer Abtasten. Wenn ich mehr Texel pro Pixel berechne wie bei SGSSAA ist das natürlich nicht der Fall, die Pixel pro Dreieck bleiben konstant, es muss nur jedes Dreieck x-mal berechnet werden.

Das muss nicht und wird auch wohl nicht der einzige Grund sein, aber es erklärt warum AMD von hohen Auflösungen profitiert im Vergleich zu NV. Warum AMD allerdings bei SGSSAA meist mehr Leistung einbüßt wie NV erklärt das nicht.

[aufkrawall]

War ja nur ein Beispiel... Mit "1,5" meinte ich einfach dass nicht die vorgeschriebene Anzahl an Samples berechnet wird...
Das sähe man ja. Tut man aber nicht, zumindest nicht, wenn man den Bug von AMDs AA nicht böswillig biased in diese Kategorie einordnet. :freak:
Die Texturfilterung müsste dann ja auch eine Art adaptive LOD-Verschiebung haben, damit es nicht zu Unterfilterung kommt.
Glaube kaum, dass der Aufwand, so etwas zu realisieren, sofern überhaupt möglich, irgendeinen Performancevorteil wert ist.
AMD scheißt ja selbst trotz offiziellem SGSSAA auf eine saubere LOD-Verschiebung. imho kein Indikator für ganz ausgeklügeltes AA...

[robbitop]

@OgrEGT: Es geht um SGSSAA, nicht Downsampling.

SGSSAA funktioniert aus Treibersicht imo wie MSAA, nur dass eben für jedes Fragment der Farbwert bestimmt wird. Es ist einfach nur der mittlere Rechenaufwand pro Fragment erhöht.
Eine schlechte SGSSAA-Implementierung müsste auch an einer schlechten MSAA-Performance erkennbar sein.
Dass GCN durch hohe Auflösungen im Vergleich zu Kepler weniger stark einbricht als durch SGSSAA, ist nicht verwunderlich, da eben durch SGSSAA die Dreieckgröße NICHT ansteigt und der Rasteraufwand pro Pixel NICHT sinkt. Hohe Auflösungen dagegen bedeuten größere Dreiecke, damit ein reduzierter Rasteraufwand pro Pixel und damit eine Lastverschiebung in Richtung Rechenwerke. Diese Lastverschiebung lässt GCN im Vergleich zu Kepler etwas besser aussehen.

Effizienter ist übrigens trotz allem SGSSAA, auch bei GCN. D.h. bei vergleichbarer Bildqualität (LOD-Bias-Anpassung berücksichtigt, Postprocessing-Unschärfe außen vor) liefert SGSSAA die höheren Frameraten.

Danke für das Auf-den-Punkt-bringen! :up: so in etwa habe ich mir das auch ungefähr vorgestellt. War aber nicht sicher.

In welcher Größenordnung meint ihr, ist im Tahiti noch Potenzial, wenn dieser Front-End-Flaschenhals nicht wäre? Wie aufwändig, wäre das, den zu lösen? Vieleicht analog zu NV Lösung? Würde das viel Fläche/Transistoren kosten?

[Nakai]

In welcher Größenordnung meint ihr, ist im Tahiti noch Potenzial, wenn dieser Front-End-Flaschenhals nicht wäre? Wie aufwändig, wäre das, den zu lösen? Vieleicht analog zu NV Lösung? Würde das viel Fläche/Transistoren kosten?

Keine Ahnung. Pitcairn und Cape Verde skalieren sehr gut. Bei Rohleistungsvergleiche brauchen sich Pitcairn und Cape Verde gegenüber der NV-Konkurrenz nicht verstecken. Siehe HD7770 gegen GTX650Ti. Beide sind in etwa gleichauf, beide haben auch ähnliche Leistungsdaten. Bei Tahiti wirds interessanter. Da hat man trotz höherer Rohleistung(+~20% mehr FLOPs) keinen starken Vorteil gegenüber der NV-Konkurrenz.

AMDs Frontend ist sowieso sehr mickrig und schon fast lächerlich. Da ist noch viel Optimierungspotential.
Tahiti wäre ohne Probleme 20% schneller, imo. Je nach Vergleichslage. Nimmt man Cape Verde als Vergleichsbasis her, müsste Tahiti etwa 33% schneller sein(bei 1:1-Skalierung der SPs und Rohleistung). Bei Pitcairn sind es noch 20%.

IMO würde ein optimierter Tahiti mit Quad-Frontend(Träumerei; je 8 CUs an einem Frontend) und höherem Takt(1,2 GHz), schon locker 20 bis 30% schneller sein. Damit würde man sogar in die Schlagreichweite vom GK110 kommen(Topdog eher nicht).

[Gipsel]

Gerade erst gesehen, daß die Diskussion ja noch weiterging. Dann versuche ich das mal, etwas ausführlicher als im ersten Post (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9647072#post9647072) aus meiner Sicht zu schildern (evtl. muß ich noch ein paar kleine Bildchen malen, falls es nicht verständlich wird).

Die Zutaten haben wir im Prinzip ja schon hier im Thread erwähnt: Rasterizer, Warp-Größe, Verschnitt, ROPs, Kompression. Was spielt wann eine Rolle?

Fangen wir mal vorne an, am Rasterizer (alles davor weiß vom SSAA ja nichts). Worin unterscheiden sich SGSSAA und OGSSAA (bzw. schlicht höhere Auflösung)? Natürlich in der Anordnung der Samples. Bei der höheren Auflösung (Downsampling/OGSSAA) bleiben die Samples an der Pixelmaske der Ausgabe ausgerichtet, es gibt genau ein Sample einen Pixel weiter rechts und ein anderes Sample einen Pixel weiter unten. Die Folge ist, daß man sie wunderbar in die Quads (2x2 Pixel, die wesentliche Grundlage der Verarbeitung bei GPUs ist) einsortieren kann.

@fondness: Jedes Dreieck belegt nur mindestens ein Quad, nicht eine ganze Wavefront. Man kann in eine Wavefront bis zu 16 Dreiecke packen, wenn das alles Dreiecke sind, die keine Quadgrenzen überschreiten. Ein Rasterizer (Tahiti und Pitcairn haben bekanntlich zwei, CapeVerde einen) spuckt also als kleinste Einheit Quads aus und zwar maximal 4 Quads pro Takt (alles aus einem Dreieck) und minimal 1 Quad (kleines Dreieck, was keine Quadgrenze überschreitet). Echter Verschnitt sind also ungenutzte Pixel bzw. Fragments in Quads. Eine Wavefront wird eigentlich immer mit Quads gefüllt, solange noch Dreiecke da sind, für die der Pixelshader ausgeführt werden muß. Verschiedene Dreiecke (sogar aus unterschiedlichen Bildschirmbereichen) in eine Wavefront zu mixen, ergibt keine Probleme. Das ISA-Manual für SI klärt sogar, warum das funktioniert (im Abschnitt für die Parameter-Interpolation).

Die Adressierung von Texeln in Texturen hat traditionell ein paar Optimierungen eingebaut. So werden z.B. die Gradienten, aus denen sich das Textur-LOD oder auch der AF-Grad ergibt, nur einmal pro Quad berechnet und zwar einfach durch Differenzbildung der Texturkoordinaten in x- und y-Richtung. Damit das funktioniert, müssen aber die Fragments in den Quads natürlich auch genau auf die Pixelmaske ausgerichtet sein, also genau so, wie man das bei OGSSAA hat. Für SGSSAA würde das so nicht mehr funktionieren, wenn man Samples in ein Quad packen würde, die nicht genau entlang der x- bzw. y- Bildschirmachse ausgerichtet sind und noch unterschiedliche Abstände haben. Bei MSAA hat man das Problem so erstmal nicht, da nur ein Textursample pro Pixel genommen wird (man nimmt nur mehrere Coverage-/Z-Samples), das Textursampling/Gradienten-/LOD-Berechnung aber wie im Fall ohne AA abläuft.

Wie löst man das jetzt im Fall von SGSSAA? Nun, der Rasterizer kreiert mehrere Quads mit Samples in Bildschirmauflösung. Im Prinzip gibt es jetzt für jedes SGSSAA-Sample ein Quad, was leicht gegenüber den jeweils anderen verschoben ist. Im Prinzip entspricht es (wie fondness ganz am Anfang richtig sagte) dem mehrfachen Rastern jeden Dreiecks in Bildschirmauflösung statt dem Rastern in höherer Auflösung. Und dies macht einen Unterschied beim Verschnitt. Größere Dreiecke produzieren weniger Verschnitt als kleinere (irgendwo hier im Techforum wurde das schon bis zur Vergasung diskutiert). Wenn man jetzt vier oder gar 8 mal ein kleines Dreieck rendert, produziert das natürlich mehr Verschnitt als einmal ein großes mit 4 oder 8 mal so vielen Pixeln.http://www.ixbt.com/video3/images/barts/tess2.jpg
Vergleicht man AMD- und nV-GPUs und den Leistungseinbruch durch verschiedene AA-Varianten, spielen mehrere Faktoren hinein. So ist bekannterweise die Framebufferkompression bei AMD etwas effizienter als bei nV (kleinere Blöcke und granularer, berücksichtigt mehr Fälle), allerdings funktioniert die natürlich nur bei MSAA, aber nicht bei SSAA (weil jedes Sample praktisch immer eine etwas andere Farbe hat [weil jedes Sample durch den Pixelshader läuft], bei MSAA nur, wenn es zu einem anderen Dreieck gehört). Eventuelle Effizienzvorteile in diesem Bereich bei MSAA fallen bei SSAA einfach weg.

Ab jetzt komme ich in den unsicheren Bereich, da (zumindest mir) nicht klar ist, wie die Rasterizer das genau handhaben. Und hier können eben auch noch Unterschiede zwischen nV und AMD bestehen, die den beobachteten Performanceunterschied (zusätzlich zum erwähnten Verlust des MSAA-Framebufferkompressions-Vorteils) verschieben.

Worst case: Es gibt tatsächlich mehrere Rasterdurchläufe pro Dreieck, d.h. der Rasterdurchsatz verringert sich z.B. mit 4xSGSSAA auf nur noch 1 Dreieck alle 4 Takte (pro Takt wieder 1-4 Quads). Dies kann man natürlich verbessern.

Eine Optimierung könnte daraus bestehen, daß im Fall von SGSSAA direkt die etwas verschobenen Quad-Duplikate im gleichen Takt generiert werden. Dies würde bedeuten, daß (wieder bei 4x SGSSAA) immer direkt 4 Quads erzeugt werden können, der Rasterizer also praktisch immer am Anschlag läuft (solange Dreiecke da sind). Bei 8xSGSAA benötigt man dann immer (mindestens) 2 Takte pro Dreieck (statt immer mindestens 8). NV's kleinere Rasterizer (maximal 2 Quads/8 Pixel pro Takt) wären natürlich schon mit 2x SGSAA immer ohne "Verluste" unterwegs.

Die beste Lösung wäre aber, daß man um den quadbasierten Verschnitt herumkommt und mit SGSSAA sich dem geringeren Verschnitt von OGSSAA annähert. Dazu muß man nicht nur die Rasterizer entsprechend anpassen, sondern hauptsächlich alles, was fest auf der rechtwinkligen, äquidistanten x-y-Ausrichtung der Quads basiert entsprechend anpassen, so daß z.B. bei der Gradienten-/LOD-Berechnung kein Blödsinn rauskommt. Im Prinzip sollte für die relativ einfachen 2x/4x-SG-Samplemuster so eine Anpassung mit überschaubarem Aufwand möglich sein (ist zumindest meine Meinung). Dann könnte man bei 4xSGSSAA ein Quad direkt mit den 4 Subsamples befüllen und der Verschnitt sinkt auf das Level von OGSSAA. Kann aber das Samplemuster frei gewählt werden, wird das natürlich deutlich aufwendiger und es sind Fälle möglich, in denen die Sache entartet, also z.B. keine Gradientenberechnung mit den Samples in einem Quad möglich wäre. Aber eine Umsetzung wäre als Optimierung für die Standard-Samplemuster natürlich trotzdem möglich (ansonsten wird es eben langsamer).

Daneben gibt es wie üblich immer noch ein paar Details, an denen man unter Umständen feilen könnte (z.B. ob sich die verschiedenen SGSSAA-Sample-Quads die zu interpolierenden Attribute teilen können, oder ob die im LDS dupliziert werden müssen [also in diesem Zusammenhang als neues Dreieck zählt wie im Worst-Case], was natürlich dort Platz, Bandbreite und auch ein wenig Zeit für den Transfer kosten kann; es sind immerhin 48Bytes pro Dreieck [für jedes Dreieck werden immer die Werte an allen 3 Vertices mitgenommen, auch wenn sich benachbarte Dreiecke oft 2 Vertices teilen, aber damit gehen eben auch mehrere nicht zusammenhängende Dreiecke pro Wavefront] und Attribut und DX11 unterstützt iirc bis zu 32 Attribute, sind also maximal 1,5kB pro Dreieck oder 24kB pro Wavefront!). Und vermutlich noch ein Dutzend mehr, auf die ich jetzt nicht komme.