Guis ohne externe Lib
-
tkausl schrieb:
Edit: Die gleiche Frage könnte ich genauso für OpenGL stellen: Glut, glew, ..., aber im Endeffekt müssen die ja auch auf OpenGL zugreifen, also muss es doch auch eine direkte Möglichkeit geben, OpenGL anzusprechen, ohne solche Libarys. Vieleicht kann da auch jemand was zu sagen
OpenGL ist eine Schnittstelle. Das heißt, im OpenGL Standard ist definiert, man muss diese und jene Funktionen anbieten, dann darf man das eine OpenGL-Implementierung nennen. Solch eine Implementierung muss nicht unbedingt die Grafikkarte des Systems nutzen oder den Monitor/Videospeicher als Ziel haben. Es gibt zum Beispiel viele hochwertige Softwarerenderer, mit denen professionelle Grafiken erstellt werden, die eine OpenGL-Schnittstelle anbieten. Ich glaube, deine Frage ist eher, wie du direkt die OpenGL-Implementierung des Grafiktreibers nutzen kannst.
Dieses ganze low-level Zeugs ist aber sicher nicht das, was du suchst, wenn du es möglichst simpel haben möchtest. Bibliotheken mit höherer Abstraktion sind nicht nur dazu da, um Plattformunabhängigkeit zu erreichen, sie sollen es dem Anwender auch möglichst leicht machen, sein Ziel zu erreichen. Willst du dich wirklich damit herumschlagen, einen OpenGL-Context ohne Hilfe selber zu erstellen? Selbst die von dir genannten Frameworks benutzen oft nicht direkt die nativen OS-Schnittstellen für ihre Grafiken, sondern wiederum selbst einfachere Frameworks. GTK benutzt z.B. die Cairo-Bibliothek, die auch von vielen anderen Programmen (darunter auch einige ziemlich dicke Fische) genutzt wird, wenn sie einfache 2D-Grafiken rendern sollen. Vielleicht ist das ja was für dich? Die ist dann auch wieder plattformunabhängig.
-
@dot: Danke für die Links, die werde ich mir mal durchlesen.
SeppJ schrieb:
OpenGL ist eine Schnittstelle. Das heißt, im OpenGL Standard ist definiert, man muss diese und jene Funktionen anbieten, dann darf man das eine OpenGL-Implementierung nennen. Solch eine Implementierung muss nicht unbedingt die Grafikkarte des Systems nutzen oder den Monitor/Videospeicher als Ziel haben. Es gibt zum Beispiel viele hochwertige Softwarerenderer, mit denen professionelle Grafiken erstellt werden, die eine OpenGL-Schnittstelle anbieten. Ich glaube, deine Frage ist eher, wie du direkt die OpenGL-Implementierung des Grafiktreibers nutzen kannst.
Dass OpenGL nur ein Standard für eine Schnittstelle ist, war mir bewusst. Dass das ganze auch für Softwarerenderer zutrifft, nicht. Da glaubst du richtig, ich meinte tatsächlich die Schnittstelle die von der Grafikkarte angeboten wird, falls diese OpenGL unterstützt.
Was mir darüber noch eingefallen ist:
#1: Man muss den Treiber nutzen, richtig? D.H. Treiber selbst bieten eine Schnittstelle an? Andernfalls würde es nicht möglich sein, dass Treiber OpenGL-Bugs besitzen und auch beheben können.#2: Irgendwo hatte ich mal aufgeschnappt, dass OpenGL CPU<->GPU mit Sockets, fast wie bei einer "normalen" Server-Client Architektur arbeitet. Bin mir da aber nicht sicher.
SeppJ schrieb:
Dieses ganze low-level Zeugs ist aber sicher nicht das, was du suchst, wenn du es möglichst simpel haben möchtest. Bibliotheken mit höherer Abstraktion sind nicht nur dazu da, um Plattformunabhängigkeit zu erreichen, sie sollen es dem Anwender auch möglichst leicht machen, sein Ziel zu erreichen. Willst du dich wirklich damit herumschlagen, einen OpenGL-Context ohne Hilfe selber zu erstellen? Selbst die von dir genannten Frameworks benutzen oft nicht direkt die nativen OS-Schnittstellen für ihre Grafiken, sondern wiederum selbst einfachere Frameworks. GTK benutzt z.B. die Cairo-Bibliothek, die auch von vielen anderen Programmen (darunter auch einige ziemlich dicke Fische) genutzt wird, wenn sie einfache 2D-Grafiken rendern sollen. Vielleicht ist das ja was für dich? Die ist dann auch wieder plattformunabhängig.
Das ist schon richtig. Wirklich damit produktiv arbeiten will ich nicht. C++ ist nicht meine erste Sprache und dass Libs/Bibliotheken die Arbeit erleichtern habe ich lernen müssen (wollte anfangs alles selbst implementieren). Allerdings bin ich Süchtig nach Informationen und auch theoretischem Kram der andere Möglicherweise langweilt, daher muss (oder möchte) ich auch verstehen wie die Dinge wie Libs, Bibliotheken, Schnittstellen oder gar ganze Sprachen funktionieren, wenn ich diese nutze.
(Daher auch mein Beitrag im Assembler-Teil dieses Forums zum Linux-Kernel, obwohl ich nie im Sinn habe ein funktionierendes und sinnvolles Betriebsystem zu schreiben. Einzig und allein der Lerneffekt und das Wissen über low-level Zeugs ist das Ziel des ganzen.)Zu Cairo werde ich mich mal Schlau-googlen.
Vielen Dank für deine ausführliche Erklärung.
-
tkausl schrieb:
Allerdings bin ich Süchtig nach Informationen und auch theoretischem Kram der andere Möglicherweise langweilt, daher muss (oder möchte) ich auch verstehen wie die Dinge wie Libs, Bibliotheken, Schnittstellen oder gar ganze Sprachen funktionieren, wenn ich diese nutze.
Da muss man etwas aufpassen. Es gibt interessante Informationen, und die meisten erfahrenen Entwickler wollen auch genau wissen, wie die Bibliotheken, die sie benutzen genau funktionieren. Und es gibt langweilige Informationen, die keinen interessieren. Wie dein OpenGl Treiber mit deiner Grafikkarte kommuniziert wär z.B. völlig uninteressant.
-
Mechanics schrieb:
tkausl schrieb:
Allerdings bin ich Süchtig nach Informationen und auch theoretischem Kram der andere Möglicherweise langweilt, daher muss (oder möchte) ich auch verstehen wie die Dinge wie Libs, Bibliotheken, Schnittstellen oder gar ganze Sprachen funktionieren, wenn ich diese nutze.
Da muss man etwas aufpassen. Es gibt interessante Informationen, und die meisten erfahrenen Entwickler wollen auch genau wissen, wie die Bibliotheken, die sie benutzen genau funktionieren. Und es gibt langweilige Informationen, die keinen interessieren. Wie dein OpenGl Treiber mit deiner Grafikkarte kommuniziert wär z.B. völlig uninteressant.
- interessant oder nicht ist ja völlig subjektiv oder... ?
- mich würde das "low-level" zeug vonm opengl schon interessieren...
- man kann mit opengl auch viele interessante sachen machen... (rein theoretisch und praktisch bis jetzt auch schon
)- in meinen augen machte s aber keinen sinn "AUßER ZU LERNZWECKEN" eine GUI auf diese weise zu erstellen...
- meine empfehlung wäre, wenn du verstehen willst wie fenster unter windows "gebaut werden": kannst ja vll mal anfangen unter windows z.B. mit WinAPI direkt ein Fenster zu coden... ( nur zum lernen )
- das ist schon frikkelig genug... wenn du dann noch nicht genug hast würde ich erst den "nächsten schritt tiefer" gehen...
-
edit: mich würde gerade interessieren "WIE OPENGL MIT MEINER GRAFIKKARTE KOMMUNIZIERT" , das ist ja gerade das interessante wie ich finde
...
hatte ich eben vergessen...
-
edit2: vielleicht gibt es hier auch infos auf die opengl fragen:
- https://developer.nvidia.com/opengl
-
HalliHallo schrieb:
edit: mich würde gerade interessieren "WIE OPENGL MIT MEINER GRAFIKKARTE KOMMUNIZIERT" , das ist ja gerade das interessante wie ich finde
...
hatte ich eben vergessen...Im Falle einer dedizierten Grafikkarte: Über den PCI Bus
OpenGL ist implementiert im bzw. redet mit dem User-Mode Driver deiner Grafikkarte, welcher selbst über den Kernel-Mode Driver mit der Grafikkarte kommuniziert.
Wie Displaydriver beispielsweise in Windows funktionieren, ist hier dokumentiert: http://msdn.microsoft.com/en-us/library/windows/hardware/ff569513.aspx
Wie die Kommunikation mit der Karte an sich abläuft, hängt von der konkreten Karte ab und die Dokumentation ist in der Regel nicht öffentlich zugänglich. Von AMD und Intel wurde für einige GPU Serien das entsprechende Manual allerdings veröffentlicht:
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/R5xx_Acceleration_v1.5.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/evergreen_cayman_programming_guide.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/CIK_3D_registers_v2.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/si_programming_guide_v2.pdf
-
dot schrieb:
HalliHallo schrieb:
edit: mich würde gerade interessieren "WIE OPENGL MIT MEINER GRAFIKKARTE KOMMUNIZIERT" , das ist ja gerade das interessante wie ich finde
...
hatte ich eben vergessen...Im Falle einer dedizierten Grafikkarte: Über den PCI Bus
OpenGL ist implementiert im bzw. redet mit dem User-Mode Driver deiner Grafikkarte, welcher selbst über den Kernel-Mode Driver mit der Grafikkarte kommuniziert.
Wie Displaydriver beispielsweise in Windows funktionieren, ist hier dokumentiert: http://msdn.microsoft.com/en-us/library/windows/hardware/ff569513.aspx
Wie die Kommunikation mit der Karte an sich abläuft, hängt von der konkreten Karte ab und die Dokumentation ist in der Regel nicht öffentlich zugänglich. Von AMD und Intel wurde für einige GPU Serien das entsprechende Manual allerdings veröffentlicht:
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/R5xx_Acceleration_v1.5.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/evergreen_cayman_programming_guide.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/CIK_3D_registers_v2.pdf
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/si_programming_guide_v2.pdf- Was is denn nur PCI? und was ist eigentlich eine Grafikkarte?
- nein spaß...
PCI ist mir schon klar... aber ichmeinte eher auf software seite ...- danke
, interessante links dabei, ich schau mal drüber aber ichhab mich da vor einiger zeit auch schonmal informiert... [quote="dot"]
Wie die Kommunikation mit der Karte an sich abläuft, hängt von der konkreten Karte ab und die Dokumentation ist in der Regel nicht öffentlich zugänglich. Von AMD und Intel wurde für einige GPU Serien das entsprechende Manual allerdings veröffentlicht:
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/[quote]- gerade das ist interessant! das meinte ich...
-
HalliHallo schrieb:
- gerade das ist interessant! das meinte ich...
Warum? Interessant sind doch übertragbare, wiederverwendbare Konzepte. z.B., wie PCI funktioniert, wie hier die Treiberarchitektur ausschaut usw. Wie die konkrete Kommunikation zwischen Treiber und einer bestimmten Grafikkarte ausschaut, ist überhaupt nicht übertragbar. Bei dem einen Modell funktioniert es so, bei dem nächsten ganz anders. Mit den Infos kannst du auch nichts anfangen, weil dir sehr viele Informationen fehlen, die nur der Hersteller kennt und wirklich anfangen kannst du damit so oder so nichts.
-
Mechanics schrieb:
HalliHallo schrieb:
- gerade das ist interessant! das meinte ich...
Warum? Interessant sind doch übertragbare, wiederverwendbare Konzepte. z.B., wie PCI funktioniert, wie hier die Treiberarchitektur ausschaut usw. Wie die konkrete Kommunikation zwischen Treiber und einer bestimmten Grafikkarte ausschaut, ist überhaupt nicht übertragbar. Bei dem einen Modell funktioniert es so, bei dem nächsten ganz anders. Mit den Infos kannst du auch nichts anfangen, weil dir sehr viele Informationen fehlen, die nur der Hersteller kennt und wirklich anfangen kannst du damit so oder so nichts.
...
damit meinte ich alles um den treiber und dessen kommunikation mit der grafikkarte...
klar damit kannst grafikkarten treiber programmieren ...verstehe eig auch die disskussion nicht, ich find es interessant...
das ist subjektiv und kann sich von person zu person unterscheiden ...
