OpenGL/OpenCL: glDrawPixels
-
dot schrieb:
Skysnake schrieb:
Das glPixelDraw ist noch im OpenGL drin
Nicht in aktuellen Versionen von OpenGL. Natürlich wird es aus Gründen der Abwärtskompatibilität noch unterstützt.
Also ist es noch drin :ugly:
Ich kann es verwenden, in der aktuellsten Version, also ist es noch drin.
Skysnake schrieb:
Wenn ich das Ding aber in ne Textur speichere, dann kann ich nicht mehr beliebig drauf zugreifen. Das ist scheise.
Was genau meinst du damit?
Du kannst in einem OpenCL kernel entweder lesend, oder schreibend auf ein Image zugreifen, aber nicht beides. Das ist schlecht, wobei es hier sogar noch gehen würde in der aktuellen Implementierung, die ich verwende. Wenn ich dann aber zu einer anderen Methode wechsle, dann muss ich ein LGS lösen, und dann hilft mir das kein Stück weiter.
Aber nochmal kurz zu glDrawPixels. Was könnte ich denn ansonsten noch verwenden? Klar ne Textur, aber würde das einen Performanceunterschied machen, wenn ich da so oft die Textur ändern muss?
Wäre wirklich gut zu wissen, wie man das elegant und performant lösen kann. Die >>100 FPS sind zwar ok, aber mehr ist immer besser
EDIT:
Andreas XXL schrieb:
Du kanst ein OpenGL Texturobjekt auch mit OpenCL verwenden (vorher umwandeln).
Dann kanst du die Textur mit OpenCl bearbeiten und mit OpenGL einfach mit den üblichen Mechanismen zum Zeichnen von Texturen darstellen.Dann brauchst du kein extrem langsames Pixeldraw.
Du brauchst die Ergebnisse nicht mal über den Bus schicken.
Mir kommt gerade ne Idee
Ich baue mir ein nur GPU Game of Life
Btw. das umwandeln geht nicht -.- laut der OpenCL DeviceInfo wird diese Erweiterung von meiner 5870 nicht unterstützt. Ich sollte aber diese Woche zum programmieren/testen ne 7970 bekommen. Vielleicht kann die das dann.
Wobei ich mich schon frag, in wie weit das am Ende alles noch schneller ist.
-
Skysnake schrieb:
dot schrieb:
Skysnake schrieb:
Das glPixelDraw ist noch im OpenGL drin
Nicht in aktuellen Versionen von OpenGL. Natürlich wird es aus Gründen der Abwärtskompatibilität noch unterstützt.
Also ist es noch drin :ugly:
Ich kann es verwenden, in der aktuellsten Version, also ist es noch drin.
Im Compatibility Profile wird es noch unterstützt. Im Core Profile ist es nichtmehr drin und auf einem entsprechenden OpenGL Context ist es damit auch nichtmehr verfügbar. glDrawPixels() ist seit OpenGL 3.0 deprecated und mit OpenGL 3.2 offiziell removed (eine aktuelle OpenGL Version wäre 3.3 bzw. 4.2, was in etwa Direct3D 10 bzw. 11 entspricht).
Skysnake schrieb:
Skysnake schrieb:
Wenn ich das Ding aber in ne Textur speichere, dann kann ich nicht mehr beliebig drauf zugreifen. Das ist scheise.
Was genau meinst du damit?
Du kannst in einem OpenCL kernel entweder lesend, oder schreibend auf ein Image zugreifen, aber nicht beides. Das ist schlecht, wobei es hier sogar noch gehen würde in der aktuellen Implementierung, die ich verwende. Wenn ich dann aber zu einer anderen Methode wechsle, dann muss ich ein LGS lösen, und dann hilft mir das kein Stück weiter.
Ich weiß nicht was genau du da machen möchtest, aber wäre vielleicht Double Buffering eine Lösung? Also zwei Buffer, wobei in jeder Iteration eben immer aus einem Werte gelesen, in den anderen Werte geschrieben und dann die Buffer geswapped werden?
Skysnake schrieb:
Aber nochmal kurz zu glDrawPixels. Was könnte ich denn ansonsten noch verwenden? Klar ne Textur, aber würde das einen Performanceunterschied machen, wenn ich da so oft die Textur ändern muss?
Der einzige Weg um das sicher rauszufinden ist, es auszuprobieren. Ich kann dir nur sagen dass der moderne Weg afaik ein Fullscreen Quad mit Textur drauf ist.
-
Danke für die Info.
Für die Studenten ist das mit dem glDrawPixels halt recht schön und anschaulich, wie ich finde. Daher lass ich es dafür wahrscheinlich drin.
Wie sähe denn die Version mit der Textur aus? Kannste da kurz paar Codeschnipsel hin schreiben bzgl allocation, befüllen und Darstellung?
Das mit dem Double-Buffer kannste knicken, weil dem Lösen eines LGS machste das normal inPlace.
Wäre auch sinnfrei so was in eine Textur zu packen, einfach weil der Sinn dahinter ja nicht mehr stimmt, und auch die Form eine ganz andere ist. Das sind ja teils nur noch Bandmatrizen.
Wichtig ist, das ich zumindest schon mal was hab, was läuft und recht einfach zu verwenden ist.
Montag schreib ich dann mal den Writer für 24Bit Farbtiefe BMPs und dann muss ich mal schauen, ob ich das noch auf die anderen möglichen BMP Farbtiefen beim einlesen erweitere.
Falls es interessiert, kann ich ja auch mal paar Screens hoch laden. Sagt einfach Bescheid.
Btw. mit Glut sollte man doch Textfeld und Buttons auch erstellen können. Kannt das sein, dass das in der ganz normalen GLUT nicht drin ist? Hab mal danach gesucht aber nichts gefunden.
-
Ok, wenn ich das recht verstehe hast du folgenden Ablauf:
- Zeug auf die Graka laden
- Gleichungssystem lösen
- Darstellen
Dann arbeit in OpenCL einfach mit normalen Buffern, kopier das Ergebnis am Ende in eine OpenGL Textur und render die.
Dazu müssen deine Daten die Graka nie verlassen. Du hast deine OpenGL Texture, baust dir per clCreateFromGLTexture2D() ein OpenCL Image dazu und kopierst dann per clEnqueueCopyBufferToImage() die Daten auf der Grafikkarte.
Das ist auf jeden Fall effizienter als die Daten von der Grafikkarte in den RAM zu kopieren, nur um sie dann von dort wieder zurück auf die Grafikkarte zu kopieren...
-
Muss ich aber im Moment aber leider eh machen
Wie gesagt, laut dem clDeviceInfo unterstützt meine 5870 nicht den Extension für CL/GL Interoperabilität -.-
Also zumindest sagt mir die Abfrage, dass die Karte das nicht kann. Ich sollte es vielleicht doch einfach noch mal testen.
Muss ich eventuell irgendwelche Compilerflags angeben um das zu nutzen?
-
Du kannst in einem OpenCL kernel entweder lesend, oder schreibend auf ein Image zugreifen, aber nicht beides.
Dann übergib das Image einfach zweimal an den Kernel.
Einmal lesend und einmal schreibend. Das funktioniert. Habs gerade ausprobiert.
-
MisterX schrieb:
Du kannst in einem OpenCL kernel entweder lesend, oder schreibend auf ein Image zugreifen, aber nicht beides.
Dann übergib das Image einfach zweimal an den Kernel.
Einmal lesend und einmal schreibend. Das funktioniert. Habs gerade ausprobiert.Dann hast du Glück gehabt, denn das ist laut OpenCL Spezifikation undefiniert....
-
Dann mach halt nen zweiertausch.
Textur (A) lesend. Textur (B) schreibend.
Dann textur (B) lesend und Textur (A) schreibend.
usw.Das ist dann definiert.
-
Genau darüber haben wir hier aber schon auf der letzten Seite diskutiert oder so...
-
Ja, aber für was den Heck Meck machen, wenn man einfach ganz stink normale Buffer verwenden kann, auf denen man auch ganz stink normal rechnet.
Images sind manchmal ganz nett, aber das wars auch.
