Rendercontext des OS für OpenGL zur Verfügung stellen, was passiert da genau?
-
Wenn ich auf dem Windows XP Desktop eine OpenGL Anwendung laufen lassen möchte, dann wird ja für diese erstmal ein Fenster bereit gestellt, also ein 2d Fläche bereitgestellt, irgendwas mit HDC (Handle) gefummelt, ein DC (Device Context) bereitgestellt und für das Fenster kann dann OpenGL einen Rendercontext erstellen und in diesen Hardwarebeschleunigt reinrendern.
Aber wie muß ich mir das auf dem Framebuffer der direkt zum Monitor geht vorstellen?
Sagt Windows, im Rechteck xy1 bis xy2 greift die GPU in den Framebuffer und der Rest drumerhum ist normales 2d Software Rendering ohne GPU Beschleunigung oder wie muß man sich das vorstellen?
Die Frage zielt auf WinXP ab, aber ich würde auch gerne wissen wie es bei Windows 7, daß ja schon einen 3d Desktop hat und bei Linux unter z.B. KDE4 der Fall ist.
Zumal ja Windows 7 sicher Direct3d zum rendern des Desktops verwendet. Wie paßt das also mit OpenGL zusammen, wenn plötzlich zwei 3d APIs die Hardware in Beschlag nehmen?
-
sdf schrieb:
Zumal ja Windows 7 sicher Direct3d zum rendern des Desktops verwendet.
Ja
sdf schrieb:
Wie paßt das also mit OpenGL zusammen, wenn plötzlich zwei 3d APIs die Hardware in Beschlag nehmen?
Wo liegt das Problem, am Ende landet doch sowieso alles beim Grafiktreiber!? Über welche API du mit dem Treiber redest is doch egal...
-
dot schrieb:
Wo liegt das Problem, am Ende landet doch sowieso alles beim Grafiktreiber!? Über welche API du mit dem Treiber redest is doch egal...
Ok, da hast du auch wieder recht.
Ich bin halt davon ausgegangen, daß Direct3d das ganze Device in Beschlag nimmt.Also ähnlich wie damals bei Linux als OSS noch der Stand der Dinge war und die Soundkarte von einer einzigen Anwendung komplett in Beschlag genommen wurde.
Für ALSA hat man dann einen Softwaremixer geschrieben bzw. wurde für OSS dazu ein Soundemon/server wie z.B. ESD oder Arts verwendet.Ganz ähnlich stelle ich mir das halt vor, wenn Direct3d und OpenGL gleichzeitig die Karte nutzen wollen.
Immerhin wird auf der GPU ja auch RAM belegt. Wie sieht's da aus, wenn die Grafikkarte z.b. 1 GB hat und die Direct3d und OpenGL Anwendung davon jeweils die Hälfte belegen? Wer löst da die enstehenden Konflikte auf, der Treiber?
Deinen Worten zufolge müßte das so sein, richtig?Aber das war jetzt nur ein Nebenthema, viel wichtiger war mir das mit dem Rendercontext, wie das eigentlich unter der Haube so richtig vonstatten geht.
-
sdf schrieb:
Ok, da hast du auch wieder recht.
Ich bin halt davon ausgegangen, daß Direct3d das ganze Device in Beschlag nimmt.Ganz ähnlich stelle ich mir das halt vor, wenn Direct3d und OpenGL gleichzeitig die Karte nutzen wollen.
Immerhin wird auf der GPU ja auch RAM belegt. Wie sieht's da aus, wenn die Grafikkarte z.b. 1 GB hat und die Direct3d und OpenGL Anwendung davon jeweils die Hälfte belegen? Wer löst da die enstehenden Konflikte auf, der Treiber?
Deinen Worten zufolge müßte das so sein, richtig?Naja, früher (in Zeiten von XP/D3D9) war das afaik tatsächlich so dass Anwendungen quasi nacheinander Zugriff auf die Grafikkarte bekommen haben. In D3D9 musste die Anwendung entsprechend sich daraus ergebende Probleme selbst behandeln (daher die ominösen Lost-Devices). In OpenGL musste sich wohl der Treiber drum kümmern (ich würde mal vermuten dass die damals schon einfach sowas Ähnliches gemacht haben wie das Folgende). Aber heutzutage ist das nichtmehr so. Mit Vista wurde ein neues Display-Driver-Model (WDDM) eingeführt. Wenn ich das richtig im Kopf hab funktioniert das so dass der Grafiktreiber aus einem Usermode- und einem Kernelmode-Part besteht. Deine Anwendung redet (über D3D oder OGL) mit dem Usermode-Driver und dieser füllt entsprechend Command-Buffer. Diese Command-Buffer werden dann an den Kernelmode-Driver übergeben und der kümmert sich zusammen mit dem OS darum die Command-Buffer aller Anwendungen zu schedulen. Der Grafikspeicher wird komplett vom Betriebssystem virtualisiert und so können beliebig viele Anwendungen gleichzeitig die Grafikkarte benutzen.
sdf schrieb:
Aber das war jetzt nur ein Nebenthema, viel wichtiger war mir das mit dem Rendercontext, wie das eigentlich unter der Haube so richtig vonstatten geht.
Der GL-Context ist im Prinzip ja nur ein Speicherbereich wo der Treiber den zum jeweiligen Thread gehörenden OpenGL-State und was er sonst noch so braucht (z.B. nen Command-Buffer ;)) ablegen kann. Wenn (ab Vista) Compositing aktiviert ist dann hat jedes Fenster im Prinzip sein eigenes Rendertarget. Ohne Compositing kümmern sich eben System und Treiber drum dass nur in den Bereich des jeweiligen Fensters gemalt wird (manche Treiber unterstützen da die witzigsten Optimierungen, wie z.B. intern ein großer Buffer für alle Anwendungen deren Fenster sich nicht überlappen). Allerdings verwendet ja am Ende wohl auch Windows selbst den Grafiktreiber um sein "normales 2d Software Rendering ohne GPU Beschleunigung" zu machen. Wenn du diese Dinge genau wissen willst schau mal ins WDK, da ist die Schnittstelle zwischen dem System und einem Grafiktreiber natürlich genau dokumentiert.
