Jammer-Thread

[dot]

Ok, da hab ich mich etwas falsch ausgedrückt. Let me rephrase: Ich bezweifle dass eine GPU irgendwas in Richtung Clipping auf Geometrieebene durchführt. Das "Clipping" passiert implizit beim Rasterisieren, die Information über die "geclippten" Primitive existiert zu keinem Zeitpunkt explizit...

[eXile]

Oder: Gäb's heutzutage Larrabee, hätten wir das Problem nicht.

[dot]

Welches Problem? Für Larrabee war doch ein Software Rasterizer vorgesehen? ;)

[eXile]

Genau deswegen hätten wir das Problem nicht. Wenn man da auf etwas nicht Zugriff hat, schreibt man einfach den Rasterizer um.

[dot]

Naja, dann müsstest du Clipping aber erst wieder selber implementieren, weil eine normale Grafikpipeline sowas heutzutage einfach nicht macht. Zumindest afaik wird ein moderner Rasterizer in der Regel wohl direkt in homogenen Koordinaten arbeiten (siehe verlinktes Paper) und braucht daher kein Geometrieclipping...

[eXile]

Welche Graphikfunktionalität hätte man auf Larrabee selbst implementieren müssen/können? Alle.

Mit Larrabee wäre es klar gewesen, dass man für Forschungszwecke alles selber macht. So ein kleiner w-Clip da drin wär' vom Aufwand vollkommen wurscht. Außerdem kann man seine Geometrie mit genug Aufwand an fast jeder Pipeline-Stufe clippen.

[dot]

Ich will die von meiner GPU fertig geclippte Geometrie. Jetzt sofort! :(

Also ich interpretiere das so, dass er eben genau nicht alles selber machen will... ;)

[eXile]

Hätte ich die Auswahl zwischen einer normalen GPU, dessen halbe Funktionalität eine Black-Box ist, an dessen Innereien man nicht rumspielen kann, oder eine Larrabee, für die es von Intel vorgefertigte quelloffene Algorithmen-Sets für Entwickler geben würde; ich weiß, worauf ich meinen GPU-Raytracer bauen würde. Hinweis: Es ist nicht die GPU. ;)

Ich hab' mir mal dein PDF reingepfiffen und auch den letzten Algorithmus zur Larrabee-Rasterisierung. Im Endeffekt kommt es auf folgenden Unterschied an:

• Clipping der Dreiecksvertices: Das wird normalerweise gemacht. Weil man es vor der homogenen Division macht, gibt es keine externen Dreiecke, und man muss nur die drei Punkte an den sechs Hyperebenen \($\pm x - w = 0$\), \($\pm y - w = 0$\) und \($\pm z - w = 0$\) clippen, d.h. deren Koordinaten verschieben. Da das vor der homogenen Division passiert, braucht man auch keinen \($w = \pm \varepsilon$\)-Clip, was tatsächlich teuer wäre (da man dann ein Dreieck in zwei Dreiecke aufteilen müsste). Dann wird durch \($w$\) geteilt.
• Clipping der Dreieckspixel: Das wird im PDF gemacht, und ebenso wie im ersten Fall vor der homogenen Division. Es wird gar nichts geclippt (schnell). Bei dem Rastern eines Pixels wird gecheckt, ob alle Kantenfunktionen positiv sind; insbesondere ist man in einem externen Dreieck, wenn alle Kantenfunktionen negativ sind.

Das Problem am zweiten Ansatz ist nun, dass das mit einem Parallel-Ansatz wie Larrabee nicht gut skaliert. Die externen Dreiecke neigen gerne dazu, große Teile des Bildschirms auszufüllen; damit ist eine early rejection an den 16×16- bzw. 4×4-Kacheln bei der Rasterisierung nicht häufig der Fall, sondern läuft ins Leere. Um allerdings herauszufinden, ob ein Pixel zu einem solchen externen Dreieck gehört, muss man ihn tatsächlich rasterisieren, d.h. die Kantenfunktionen an der Pixelposition auswerten. Da führe ich lieber vorher ein Clipping durch, um nachher schnelle Tile-basierte rejection zu haben.

Im Endeffekt können wir hier nur herumraten, was die GPU macht. Da man an die Daten eh nicht drankommt, ist es müßig, zu diskutieren, ob die Daten generiert werden oder nicht. Vermutlich benutzen deine und meine GPU eh ganz andere Verfahren, die tief in den Schatzkammern im Keller von nVidia und AMD vergraben sind. ;)

[CodingCat]

Bei dem Paper zu homogener 2D-Rasterisierung bin ich heute stehen geblieben. Eventuell werde ich morgen mal versuchen, das zu implementieren. Im Moment ist mir noch nicht ganz klar, wie ich ohne Clipping rausfinde, wo ich anfangen muss mit scannen, bzw. am liebsten würde ich gar nicht groß scannen, sondern direkt Zeile für Zeile über die richtigen inneren Pixel laufen. Interessant ist in diesem Zusammenhang auch noch die Arbeit zu 3D Rasterization (2 Veröffentlichungen, der wesentlich ältere Tech Report enthält im Anhang etwas mehr Details).

Schlussendlich suche ich nach einer Möglichkeit, zum einen konservative Rasterisierung effizient implementieren zu können, ohne dafür die vierfache Dreiecksmenge (und ekelhaftes Clippinggehacke) in Kauf nehmen zu müssen, und zum anderen selbst die Abarbeitung von Dreieckspixeln steuern zu können, um so eventuell mehr Ablaufkohärenz bei sehr unterschiedlich langen Pixelverarbeitungszeiten schaffen zu können.

[Krishty]

das Fused-Multiply-Add ist in letzten Sekunde aus dem AVX-Standard geflogen (obwohl es noch in der offiziellen Intel-Doku drin ist, aber es gibt in Visual Studio keine Intrinsics für FMA)

Fantastisch – ist ja nicht so, als dass ich mich drauf gefreut hätte. Außerdem werden wir ja schon seit jeher nur mit den allerwichtigsten Intrinsics versorgt, da hat so ein hochspezialisierter Mist wie FMA nichts in meiner kostbaren Prozessorlogik verloren!

[CodingCat]

Manchmal ist die Umkehrung der Y-Achse bei der Projektion in den Bildraum alles, was noch fehlt (über 3 Tage hinweg :evil: ).

Als nächstes muss ich wohl bei der konservativen Rasterisierung noch mal ran, und dann beginnt die Optimierung.

[CodingCat]

Oh, und falls sich jemand fragt, wozu der ganze Aufwand für eine billige planare Spiegelung, folgendes geht natürlich auch und ist das eigentliche Ziel:

Und ja, es ist etwas ungeschickt, dass momentan wirklich alles spiegelt.

Nachtrag: Das Ganze hat nichts mit Path Tracing zu tun, wie der veraltete Fenstertitel suggeriert. Um damit Path Tracing betreiben zu können, müssen wohl noch etliche GPU-Generationen ins Land ziehen, also denkt euch das „Path” einfach weg.
Bzgl. Echtzeit: Das Rendering läuft mit reinen Dreieckssuppen ohne Beschleunigungsstrukturen, insofern bin ich auf die 1 FPS schon stolz. :P Leider ist die Sache alles andere als straight-forward, Erläuterungen kommen später, wenn es sich überhaupt lohnt. :|

[eXile]

Sind das im letzten Bild die Pfade \($\mathbf{LDSE}$\)? Wenn ja, kommt es mir noch etwas komisch vor, warum du in der Szenenposition überhaupt die blauen/grünen/roten Tücher auf dem Bodenreflexion siehst; aber ich kann mich auch gerade irren. Sieht schon gut aus! ;)

[CodingCat]

Das liegt daran, dass alles reflektiert, und die Verrechnung der Reflexion im Moment einfach eine stupide Addition der reflektierten Szenenfarben ist. Wenn du genau hinschaust, siehst du, dass das, was wie die echten Tücher aussieht, in Wirklichkeit nur deren Reflexion auf der Wand ist. Die echten Tücher hingegen reflektieren selbst auch und sind der Addition wegen nur ganz blass zu erkennen.

[eXile]

Habt niemals Flash offen, wenn ihr mit UAVs arbeitet und die Nvidia 300er Treiber habt. Manchmal hängt sich das System so stark auf, dass noch nicht einmal der WDDM TDR Watchdog mehr etwas ausrichten kann (Vermutung: Kernel-Treiber reagiert noch auf Watchdog, aber auf nichts anderes mehr).

[Biolunar]

Habt niemals Flash offen. wenn ihr mit UAVs arbeitet und die Nvidia 300er Treiber habt. Manchmal hängt sich das System so stark auf, dass noch nicht einmal der WDDM TDR Watchdog mehr etwas ausrichten kann (Vermutung: Kernel-Treiber reagiert noch auf Watchdog, aber auf nichts anderes mehr).

FTFY

Hintergrund: Scheinbar braucht man heutzutage viel mehr Ressourcen (CPU, RAM, …) um die selben Dinge wie vor 3 oder 4 Jahren zu machen, ohne dass das System total am krepieren ist. Hab auf meinem Laptop ein 720p Video auf Youtube schauen wollen, doch nach gut 5 minuten ging fast gar nichts mehr. RAM voll. 1GiB voll. (lol noob alta 1gb ist doch nix ey) Interessant, dass ich die selbe aktivität vor 3 oder 4 Jahren locker machen konnte.
Ich hoffe, dass es sich nur um ein Memleak handelt, denn mein wertvolles RAM füllt sich auch enorm auf Websiten mit viel Flash, z.B. Werbung.

[glassbear]

Ich hoffe, dass es sich nur um ein Memleak handelt, denn mein wertvolles RAM füllt sich auch enorm auf Websiten mit viel Flash, z.B. Werbung.

Adblock und Flashgot ftw! :ugeek: :ugeek: :roll:

[Schrompf]

Boah, die angeblich schlichte Übernehme des Fluid-Codes wächst sich mehr und mehr aus. Ich habe heute, nach etwa 15 Jahren der C++-Programmierung, gelernt, dass die Funktion "void TuWas( int bla[2])" eben NICHT auf einer Kopie zweier Ints arbeitet, sondern auf dem orginalen Array. Das hat mich so richtig in die Pfanne gehauen, zumal der ursprüngliche Autor diese Art der Referenzierung hier und da mit tatsächlichen Fehlern mischt - da legt er ein lokales Array aus zwei doubles an, berechnet darin irgendwas, und schmeißt dann das Ergebnis weg.

Was tut er da? Und warum funktioniert das Ding trotzdem? Dieses bunte Mischen aus Kopien, Referenzen und Referenzen, die aber nie wirklich geändert werden, macht mich wahnsinnig. Der ganze Code STINKT nach einem Java-Programmierer, der durch die Umstände zu C++ gezwungen wurde. Herden von Speicherlecks inklusive.

[Alexander Kornrumpf]

Wie jetzt? Ist das nicht die ganz normale "Arrays sind Zeiger auf das erste Element" C-Logik?

[Matthias Gubisch]

Wie jetzt? Ist das nicht die ganz normale "Arrays sind Zeiger auf das erste Element" C-Logik?

Das hab ich mich auch gerade gefragt.

void TuWas(int* bla) sollte (mehr oder weniger) auf das gleiche hinauslaufen, oder täusch ich mich da jezt gewaltig

[Schrompf]

Ja, es läuft auf's gleiche hinaus. Spezielle Freude gibt es dann aber z.b. wieder bei sowas:

Code: Alles auswählen

char blubb[20] = "Texty";
printf( "%s", blubb);

...wo der Compiler plötzlich wieder das ganze Array anstatt nur den Zeiger auf den Stack haut. Mich hat die ganze Erfahrung jedenfalls nur darin bestärkt, kleine Arrays einfach nicht als Funktionsparameter zu benutzen.

[dot]

Arrays sind keine Zeiger, Arrays sind Arrays und sind lediglich implizit in Zeiger auf das erste Element umwandelbar (Beweis: sizeof(int[100]) != sizeof(int*)). Für Funktionsparameter gibt's eine explizite Ausnahmeregelung, die hier greift:

After determining the type of each parameter, any parameter of type “array of T” or “function returning T” is adjusted to be “pointer to T” or “pointer to function returning T,” respectively.

void bla(int bli[5]) ist also per Definition gleichwertig mit void bla(int* bli), während int bli[5] an sich etwas völlig anderes ist als int* bli.

[Matthias Gubisch]

@dot:

klar das ist bekannt, aber es ging ja um den Fall des Funktionsparameters, und da wird ein Array halt wie ein Pointer übergeben :)

[dot]

klar das ist bekannt, aber es ging ja um den Fall des Funktionsparameters, und da wird ein Array halt wie ein Pointer übergeben :)

Ja. Den Grund dafür hab ich ja oben erläuert. Die Aussage dass Arrays Pointer sind, ist dennoch falsch. Arrays sind immer Arrays. Im Falle eines Funktionsparameters gibt es jedoch die extra Regelung, dass der Typ der Parameters von Array auf Pointer geändert wird. Genaugenommen wird also nicht einfach ein Array "wie ein Pointer übergeben", sondern ein Arraydeklarator deklaiert in einer Parameterliste einen Pointer.

Code: Alles auswählen

void blub(int array[42]);

Der Typ von array ist hier nicht "Array aus 42 int" sondern "Pointer auf int".

Natürlich kann man aber z.B. das Array in ein struct packen:

Code: Alles auswählen

struct stuff
{
  int array[42];
};

void blub(stuff bli);

oder einfach std::array benutzen...

[Alexander Kornrumpf]

Genaugenommen wird also nicht einfach ein Array "wie ein Pointer übergeben", sondern ein Arraydeklarator deklaiert in einer Parameterliste einen Pointer.

Mein Fehler. Aber trotzdem ist das in C auch so, soweit ich mich erinnere.

[dot]

Ja, ist in C genauso. Es ging mir nicht drum, einfach auf irgendwelche formalen Fehler hinzuweisen, sondern ich wollt etwas Klarheit drüber verschaffen wie die Sachen exakt definiert sind, da ich den Eindruck hatte, dass es hier einige Unsicherheiten drüber gab, unter welchen Umständen jetzt genau was passiert (ich war mir da selber lange Zeit nicht so sicher, was da mit Array Parametern nun eigentlich wirklich genau abgeht) ;)

[Helmut]

Ja, es läuft auf's gleiche hinaus. Spezielle Freude gibt es dann aber z.b. wieder bei sowas:

Code: Alles auswählen

char blubb[20] = "Texty";
printf( "%s", blubb);

...wo der Compiler plötzlich wieder das ganze Array anstatt nur den Zeiger auf den Stack haut. Mich hat die ganze Erfahrung jedenfalls nur darin bestärkt, kleine Arrays einfach nicht als Funktionsparameter zu benutzen.

Auch bei printf wird nur der Zeiger auf der erste Element übergeben. Die selbe Regel wie bei anderen Funktionen auch, die ja dot schon sehr schön erläutert hat.

[Schrompf]

Ja, es läuft auf's gleiche hinaus. Spezielle Freude gibt es dann aber z.b. wieder bei sowas:

Code: Alles auswählen

char blubb[20] = "Texty";
printf( "%s", blubb);

...wo der Compiler plötzlich wieder das ganze Array anstatt nur den Zeiger auf den Stack haut. Mich hat die ganze Erfahrung jedenfalls nur darin bestärkt, kleine Arrays einfach nicht als Funktionsparameter zu benutzen.

Auch bei printf wird nur der Zeiger auf der erste Element übergeben. Die selbe Regel wie bei anderen Funktionen auch, die ja dot schon sehr schön erläutert hat.

Probier's aus und lass Dich überraschen.

[CodingCat]

Probier's aus und lass Dich überraschen.

Worauf willst du hinaus? http://ideone.com/Uq9Hr

[dot]

Genaugenommen greift bei printf() eine andere Ausnahmeregelung, da es sich um eine variadische Funktion handelt, sodass kein entsprechender Parameter deklariert ist. In dem Fall wird für ein übergebenes Array beim Aufruf der Funktion die Array to Pointer Konvertierung durchgeführt...