Despotist hat geschrieben:Du nennst Installation und Verwendung einer proprietären 3d Party Software einfach?
Gefällt mir ja auch nicht, dass es proprietär ist – aber ein kostenloses, seit fast einem Jahrzehnt für genau diesen Zweck optimiertes Tool zu installieren sollte über den Daumen gepeilt 1000× einfacher als sich DirectWrite-Anbindung, Screenshot-Funktion und sogar Online-Videoaufnahme selber zu schreiben – in
allen Anwendungen; nicht nur in meinen eigenen, sondern auch, wenn mir mal jemand was zum testen rüberschickt. Ist ja auch nichts, was der Endbenutzer unbedingt haben muss – ich wollte nur mal kurzes Feedback über die Framerate; das hier ist ein Forum voller Grafikprogrammierer und da hätte ich das (oder ein vergleichbares Tool) so selbstverständlich erwartet wie die aktuelle DirectX-Laufzeitbibliothek. Habe mich geirrt und wenn du es nicht drauf hast, musst du es auch nicht extra für mich installieren. Wollte halt nur einen Überblick, was welche Hardware leistet.
Despotist hat geschrieben:Außerdem ist es nicht möglich oder gar wahrscheinlich dass Fraps das Ergebnis beeinflusst?
Als ich das letzte Mal D3DX für Font-Rendering benutzt habe, verursachte deren Kram tausend Mal mehr Unkosten – und wenn das Anzeigen von drei Zahlen in der Bildschirmecke merkliche Auswirkung auf die Leistung von zwölf 2D-Fourier-Transformationen auf 4096² Punkten hätte, wäre das schon sehr seltsam :) Das Ding braucht ja nicht umsonst Admin-Rechte; das ballert direkt in die Puffer von Windows’ Desktopkomposition. Wenn ich exakte Werte haben wollte, würde ich eh selber in kontrollierter Umgebung messen. (Nicht, dass ich euch das nicht zutrauen würde, aber ich kann unmöglich erwarten, dass jemand Aero und seinen Browser abschaltet, nur, damit ich 1 % exaktere Ergebnisse kriege.)
Ab nächstem Mal schreibt ein Druck auf die Print-Taste die Framerate ins Log. Obwohl das auch wieder scheiße ist weil die Hälfte hier keine Zeilenumbrüche ohne Carriage-Return anzeigen kann … :roll:
————
Übrigens habe ich auch mal mit der Pufferlösung experimentiert. Also, statt Texturen. Weil das ja durch den Treiber optimiert wird. Und habe gleich den Bock verloren.
Die lineare Speicherauslegung ist kacke. Ganz einfach, weil sie viel zu architekturspezifisch ist. Klar: es ist großartig, dass man seine Daten jetzt endlich wie auf der CPU verarbeiten kann. Ein Array, super. Gibt auch viele eindimensionale Anwendungsfälle, wo sowas von Vorteil ist. Aber dafür kann man jetzt mit all dem Scheiß anfangen wie: Belegung der Speicherbänke, Breite der Speicherkanäle, Burst-Writes – und alles entsprechend der Wavefront-Größe. (Für Leute, die noch nie mit GPGPU gearbeitet haben: Wenn eurer Bild 1026 Pixel breit ist statt 1024, dann habt ihr 250 fps statt 6. Ich habe dort
keine Null vergessen; es geht hier tatsächlich um Leistungsunterschiede von 50:1 wegen einzelner Pixel.) Und dieser ganze räudige Müll ist dann auf anderer Hardware – egal, ob nächsthöhere Klasse, Konkurrenzprodukt oder in ferner Zukunft befindlicher Prototyp – unbrauchbar und alles ist dort noch langsamer als vorher. Totaler Bullshit. Über Jahrzehnte haben GPUs (zum Glück!) ein abstraktes Speichermodell entwickelt, das man zwar mal besser, mal schlechter ausreizen konnte, auf dessen grobe Eigenschaften man sich aber Hersteller- und Modellunabhängig verlassen konnte. Das ist jetzt
weg. Die ganzen GPGPU-APIs geben volle Kontrolle, damit man in Präsentationsfolien 5 % mehr Leistung zeigen kann und es dafür auf 99 % der Hardware langsamer ist als je zuvor.
Unter Optimierung verstehe ich
nicht, dass der Compiler keine Schreiboperationen anpackt
weil ich die ja absichtlich so angeordnet haben könnte damit die Hardware vier Schreibzugriffe zweier Threads zu einem bündelt – unter Optimierung verstehe ich z.B., mitteilen zu können, dass in einem Datenfeld alles nur
ein Mal gelesen und dann überschrieben wird und die Hardware deshalb auf alle Synchronisationsmechanismen inklusive Cache-Kohärenz verzichten kann. Aber nein, Optimierung muss ja immer gleichbedeutend mit Low-Level sein. Da kriege ich das Kotzen.
Aber endlich Speicher zu sparen war geil. Wer einen Blick in die Log-Datei riskiert hat, hat gesehen, dass allein der Glare 295 MiB VRAM verbraucht –
trotz Downsampling auf halbe Seitenlänge. Das ist exklusiv der Tatsache geschuldet, dass die wenigen RW-Datenstrukturen so hoffnungslos schlecht implementiert sind (jetzt nicht theoretisch, sondern konkret im Treiber) und ich deshalb auf nur-schreiben und nur-lesen ausweichen musste, inklusive Unkosten zum Vorhalten der Zwischenergebnisse. Zu sehen, dass man auch mit der Hälfte auskommt, war schön.
Ich verzichte aber dankend. Ich pumpe da jetzt nicht noch mehr Lebenszeit rein, damit die Leistungscharakteristik von
„generell mittelschlecht“ zu
„hochperformant auf Radeon HD 5000-Architektur; speicherlimitiert auf Radeon ab HD 6000; auf GeForce GT 450-470 ausgeglichen falls kleiner Input und Branch-lastig bei großem Input; auf GeForce GT >600 unbrauchbar“ wechselt. Wer das will, kann mich mal.