FSAA? Multisampling?
-
hellihjb schrieb:
cachemisses hast du wie gesagt nicht, alle speicheranfragen sind vorhersehbar
Die Reihenfolge ist aufgrund des Indexbuffers zwar bekannt, aber das Streaming der Vertex-Daten in den Pre-T&L-Cache unterliegt dabei der Groesse der Cache-Line. Es wird also zwangslaeufig nicht nur der Vertex des naechsten Index uebertragen sondern die darauffolgenden "n" Vertices.
es geht nicht darum wieviele vertices auf einmal reinpassen, sondern wie gross die latenz ist um alle daten fuer einen vertex einzulesen.
hast du einen buffer, hast du (besonders mit vertex reordering entsprechend den indices) eine recht sequentielle lesereihenfolge, darauf ist die hardware optimiert.
hast du 8 streams, musst du 8mal switchen (selbst wenn du 8vertices bei jedem durchgang wegen der cacheline groesse gelesen hast).
verglichen mit dem eigentlichen datentransfer ist der erste zugriff extrem teuer. das kann man sich wie mit dem streamen von cd/DVD vorstellen, liegen alle daten hintereinander und liest man sie so, kann man selbst bei 75% redundanzdaten schneller sein als wenn man die optimale datenmenge lesen wuerde, dafuer aber jedesmal seekt.Darum ist der Pre-T&L-Cache verhaeltnismaessig gross ausgelegt um hier unnoetigen Speichertraffic zu vermeiden.
der puffer ist relativ klein, weil
1. es keinen sinn macht vor dem VS einen grossen cache zu haben, den legt man eher dahinter an
2. es nur ein streampuffer ist, die sind sehr winzig, weil davon ausgegangen wird, dass die daten nur einmal benutzt werden (was mit den caches danach auch zu 80% so ist). das heisst, die caches mit der funktionsweise von cpu caches wuerden ueberhaupt nur 20% der zugriffe auffangen muessen, diese 20% sind zudem so extrem vorhersehbar dass man sie reinstreamen kann bevor es soweit ist.
grosse caches wuerden nur was bringen bei sehr schlechten daten, also wenig, vertices, dafuer aber extrem verstreut und oft wiederverwendet.
doch genau das umgeht man mit der softwareseitigen optimierung.Ein "Cache-Miss" (Daten die im Cache erwartet werden sind noch nicht da weil "falsche" Daten uebertragen worden sind) kommt also durchaus vor.
ich weiss nicht genau was du mit 'falsche daten uebertragen worden sind' meinst. es werden genau die uebertragen die 'bald' benutzt werden, spekulativ werden keine daten geladen, sie koennen also nicht falsch sein. (deswegen denk ich du meinst was anderes?)
mit steigender anzahl buffer hast du spruenge im speicher
Bei "n" Buffern muessen zunaechst auch "n" Cache-Lines gelesen werden (dafuer sind damit auch entsprechend mehr Vertices "da"). Da die Latenz beim Rendercall ohnehin riesig ist, bezweifle ich dass man das irgendwie erfassen koennte.
ich meine verschiedene buffer in einem drawcall aus denen gestreamt wird, statt einen vertexbuffer.
-
Es wird niemals ein einzelner Vertex eingelesen sondern immer eine gesamte Cache-Line (deren Groesse ist mir nicht bekannt, beinhaltet aber *mehrere* Vertices).
Das Einlesen der Vertices orientiert sich also nicht ausschliesslich an den Indizes, sondern es landen zwangslaeufig zusaetzliche Vertices im Cache wenn das Indexing nicht strikt sequenziell verlaeuft.
Aus diesem Grund ist der Pre-T&L-Cache sehr gross (im Megabyte-Bereich) - auch wenn Du mir das partou nicht glauben moechtest
-
hellihjb schrieb:
... auch wenn Du mir das partou nicht glauben moechtest
mit moechten hat das nicht viel zu tun. auch wenn ich es 100% weiss, hab ich gerade in den hardware manuals die ich von den wichtigsten gpus habe nachgesehen, laut denen ist es ein bruchteil von dem was eine normale cpu als L1 cache hat. (tut mir leid, genaue zahlen darf ich nicht sagen).
wenn man kurz sucht, findet man auch an anderen stellen aussagen dass der cache relativ klein ist: z.b.
wenn der cache gross waere, waere es einem egal wie das allignment von den vertices ist, weil im sram random zugriffe egal sind, da muss man sich nicht um cachelines sorgen. wenn zugriffe aber cachekritisch sind, muss man das schon, und jeder gpu hersteller sagt, dass man 32byte allignen soll, damit man den cache besser ausnutzt. das haette wenig sinn wenn der cache gross waere.
-
rapso schrieb:
und jeder gpu hersteller sagt, dass man 32byte allignen soll, damit man den cache besser ausnutzt. das haette wenig sinn wenn der cache gross waere.
moment mal. 32 BYTE? oder doch bit?
-
Azrael, il Meraz schrieb:
rapso schrieb:
und jeder gpu hersteller sagt, dass man 32byte allignen soll, damit man den cache besser ausnutzt. das haette wenig sinn wenn der cache gross waere.
moment mal. 32 BYTE? oder doch bit?
byte
kleiner als 32bit koenntest du garnicht allignen, das muesste man also nicht explizit nennen
-
gilt das jetzt für interleavte buffer oder allgemein?
-
hab ich gerade in den hardware manuals die ich von den wichtigsten gpus habe nachgesehen, laut denen ist es ein bruchteil von dem was eine normale cpu als L1 cache hat
In den Unterlagen vom XDK (XBox1 wohlbemerkt) wird die Groesse mit 4kB beziffert.
Fuer aktuelle GPUs findet man wenig konkretes aber haeufig dieses:Pre T&L cache:
– Much larger than post T&L cache:
– On GeForce FX 3000: ~8,000 vertices
– On GeForce FX 6800: ~64,000 vertices
-
Argh - mein vertex ist 36 byte groß. Lohnt sich da eine aufstockung auf 64 byte?
-
hellihjb schrieb:
hab ich gerade in den hardware manuals die ich von den wichtigsten gpus habe nachgesehen, laut denen ist es ein bruchteil von dem was eine normale cpu als L1 cache hat
In den Unterlagen vom XDK (XBox1 wohlbemerkt) wird die Groesse mit 4kB beziffert.
nett dass du an NDA informationen freigibst
und 128 vertices find ich schon recht winzig und du wuerdest erstaunt sein wie wenig sich dieser wert veraendert hat.Fuer aktuelle GPUs findet man wenig konkretes aber haeufig dieses:
Pre T&L cache:
– Much larger than post T&L cache:
– On GeForce FX 3000: ~8,000 vertices
– On GeForce FX 6800: ~64,000 verticesvon ati gibt es wohl irgendwo public informationen dass es 32kb sind bei den allerneusten karten.
wie gesagt, das sind winzige caches, verglichen mit der groesse die ein normales mesh hat und sie dienen nur dem streming, entsprechend sieht du sicher auch in deinem nda papern dass sie anders organisiert sind. das sind gerade mal 16 zugriffe von einem vertexshader-array mit 8units.
die zahlen mit 64000vertices, also 2MB (bei 32byte/vertex) hat kein streaming chip.
-
Argh - mein vertex ist 36 byte groß. Lohnt sich da eine aufstockung auf 64 byte?
Nein. Aber eine Verkleinerung auf 32.
-
Azrael, il Meraz schrieb:
Argh - mein vertex ist 36 byte groß. Lohnt sich da eine aufstockung auf 64 byte?
mach 32byte daraus.
.
.
.
doch das geht!
-
hellihjb schrieb:
das paper ist sehr suspekt
die messen nur framerates von 60 30 20 15... vsync?
ihre quadro4 soll 60MTri/s theoretisch schaffen und sie haben 57fps bei 1MTri
im ogl forum gab es einige die fast die wirkliche theoretische leistung von (wenn ich mich recht entsinne) um die 128Mio/s erreichten.
deren zahlen wuerd ich nicht so ganz vertrauen was vertexcache angeht.
-
eh ja und wie geht das? ^^
ich hab ein vertex, welches so aussieht:
typedef struct { AL_byte red; AL_byte green; AL_byte blue; AL_byte alpha; float tu; float tv; float nx; float ny; float nz; float x; float y; float z; } AL_ilvdVertex;welches 4 bytes soll ich denn rausschmeißen?
die vertexfarbe?
-
texturcoordinate aus zwei shorts.
-
wie ist denn der zusammenhang?
hab mal kurzerhand das hier versucht:
vertices[i].tu = mesh->getUVCoordPointer()[i].tu*65535; vertices[i].tv = mesh->getUVCoordPointer()[i].tv*65535;Ist natürlich falsch...
Irgednwie habe ich das gefühl dass die fixed pipeline auch bei short versucht werte zwischen 0 und 1 zu nehmen. zumindest sieht das so aus :). muss man das mit einem Shader regeln? Das wäre nicht so toll denn unsere Schulcomputer können keine Shader "^^. Und ich hatte vor die Engine in der Schule zu verwenden...