Es tut mir leid, ich wüte schon wieder mit ahnungslos und mit ganzem Eifer hier im Forum rum. Man möge es mir verzeihen... Zu meiner Frage... Angenommen ich würde ein grafisch anspruchsvolles Computerspiel auf einem PC mit integrierter Grafikeinheit spielen. (Die meisten aktuellen Desktop-Prozessoren besitzen ja einen integrierten Grafikkern, der die Grafiksignale an die Display-Anschlüsse weiterleitet) Wie sieht denn nun eigentlich die Arbeitsteilung zwischen GPU und CPU aus, wenn ich in diesen Rechner plötzlich eine dedizierte Grafikkarte in einen freien PCIe-Slot stecke? Ich habe war ja nicht ganz tatenlos und habe mich natürlich auch selbst ein bisschen schlau gemacht. Ich habe z. B. in dem Buch Blender 2.7 von Thomas Beck gelesen, dass GPU-Rendering sich nur für kleine Szenen eignet, weil ja die Grafikkarte aufgrund ihres relativ geringen Speicherplatzes früher oder später auf den langsamen Hauptspeicher zugreifen müsse. (Die Ausgabe ist von 2015!) Die Aussage irritiert mich irgendwie. Ich dachte, dass die dedizierte Grafikkarte vor allem das Rendering übernimmt.
Torben S. schrieb: > relativ geringen Speicherplatzes https://geizhals.at/?cat=gra16_512&xf=132_16384 > (Die Ausgabe ist von 2015!) Seit dem ist ja die Entwickung stecken geblieben. leo
Du solltest eventuell ma unterscheiden die GPU als Teil der Grafikkarte um das (Live) bild auszugeben und der GPU als Hilfsmittel (Co-Pocessor) für irgendwelche Berechnungen (die so garnicht direkt auf dem Bildschirm ausgegeben werden). Deim Buch dürfte sich auf letzteres beziehen. z.B.: https://de.wikipedia.org/wiki/CUDA
Graphikkarten haben heute teilweise mehrere Gigabyte an Graphikspeicher. Ein Graphikprozessor kann halt sehr viele einfache gleiche Berechnungen parallel bearbeitet. Wenn zum Beispiel die Helligkeit von Objekten berechnet werden soll, muss für sehr viele kleine Oberflächen das einfallende Licht berücksichtigt und daraus die Helligkeit berechnet werden.
@Irgend W. diesen Unterschied habe ich auch im Hinterkopf gehabt, aber ich wollte diesen nicht auch noch in die Frage einbauen. Das Thema heißt deshalb Zusammenspiel zwischen CPU und GPU.
Danke für die Antworten. Wenn man ich mir jetzt aber das Zusammenspiel zwischen CPU und GPU anschauen möchte, wie sieht das konkret aus? Wie kann daraus ein Bottleneck entstehen? Also konkret: Wer erstellt die Frames, Was gehört alles zum Frame, wer übernimmt das Rendern, wer sendet die Daten an die Display-Anschlüsse?
:
Bearbeitet durch User
Das Zusammenspiel von CPU und GPU ist bei interner und extern GPU ähnlich - das Programm legt fest, was von wem abgearbeitet wird. Der Unterschied liegt hauptsächlich beim Speicherzugriff: der ist der Flaschenhals - die Bandbreite reicht bereits für die CPU nicht aus (deswegen die vielen Caches), muß bei der internen GPU aber mit dieser noch geteilt werden. Die externe GPU hat spezialisierten lokalen Speicher und kann darauf volle Kalosche rumwüten, ohne die CPU zu auszubremsen. Allerdings muss die CPU die Daten auch erstmal in deren lokalen Speicher kopieren, was zusätzliche Arbeit bedeutet ... Was die Aussagen des Blender-Buchs betrifft hat irgendwer schon kommentiert.
Früher gab es sogar noch Software-FPUs. In so manchem Szenario wurde ein "mathematischer Co-Prozessor" als Voraussetzung gefordert. Die Übergabe der Daten ist ganz ähnlich wie bei den Co-Prozessoren. Bei denen läd man ein paar Variablen in den Speicher, und anschließend landen die auf dem Rechen-Stack der FPU. Die eigentlich interessante (Neben-)Frage könnte sein, warum waren die AMDs typischerweise so schwach auf der FPU? Wie genau jetzt die Übergabe bei den Grafikkarten ist, ist neuerdings gar nicht mehr gut dokumentiert bzw. ist auch ziemlich kompliziert geworden. So ganz grob geht das aber genauso wie bei der FPU. Man läd Variablen in die Kartenpuffer und dann rechnen die, bzw. ballern die los (auf den Bildschirm). Auch noch interessant ist das Zusammenspiel zwischen der CPU-Grafik und Steckkarten-Grafik. Mit zunehmender Zeit kam zusätzliche Software (u.a. Treiber) dazu, welche das Zusammenspiel handlen kann (Directx, Cuda, Nuveau z.B.). ( https://de.wikipedia.org/wiki/Shader )
rbx schrieb: > Die eigentlich interessante (Neben-)Frage könnte sein, warum waren die > AMDs typischerweise so schwach auf der FPU? Das ist aber schon lange her. Weil FPUs lange Zeit ein Nischenthema waren. Bis 486 kamen viele Leute ganz gut ohne FPU aus. Die integrierte FPU vom K6 war an sich recht gut für Mischeinsatz Integer/Fliesskomma in normalen Programmen geeignet, ohne Pipelining, aber mit kurzen Latenzen. Pech für AMD war, dass sich justament zum K6 die Zeiten änderten und Anwendungen in der Breite aufkamen, die massive hochoptimierte Fliesskommarechnung ab Pentium nutzten. Und dafür war der K6 einfach nicht konzipiert. Ab K7 sah es dann anders aus.
:
Bearbeitet durch User
Wenn man mit Blender, ein primitives 3D-Modell mit Meshes erstellt, wird da die Grafikkarte irgendwie beansprucht?
:
Bearbeitet durch User
Torben S. schrieb: > Wie sieht denn nun eigentlich die Arbeitsteilung zwischen GPU und CPU > aus, wenn ich in diesen Rechner plötzlich eine dedizierte Grafikkarte in > einen freien PCIe-Slot stecke? Im Prinzip genauso wie vorher. Nur daß jetzt nicht mehr die integrierte GPU verwendet wird, sondern die auf der Grafikkarte. Naja, sofern du im BIOS und/oder Betriebssystem festgelegt hast, daß die Grafikkarte überhaupt verwendet werden soll. Und natürlich können (werden) sich die beiden GPU hinsichtlich ihrer Fähigkeiten unterscheiden. Weswegen sich die Arbeitsteilung im Detail unterscheiden wird. Aber von allein macht eine GPU erstmal gar nichts. > Ich habe z. B. in dem Buch Blender 2.7 von Thomas Beck gelesen, dass > GPU-Rendering sich nur für kleine Szenen eignet, weil ja die Grafikkarte > aufgrund ihres relativ geringen Speicherplatzes früher oder später auf > den langsamen Hauptspeicher zugreifen müsse. (Die Ausgabe ist von 2015!) Ja, damals hatten Grafikkarten noch wenig Speicher. > Die Aussage irritiert mich irgendwie. Ich dachte, dass die dedizierte > Grafikkarte vor allem das Rendering übernimmt. Äpfel und Birnen. Blender rendert Frames für Filme/Animationen. Die primäre Aufgabe der Grafikkarte ist das Rendern von Frames, um sie anzuzeigen. Und zwar ausschließlich, um sie anzuzeigen. Blender hingegen dumpt jeden fertigen Frame als Bitmap raus und jagt den Krempel nachher durch einen MPEG oder AVC Encoder.
Axel S. schrieb: > Äpfel und Birnen. Blender rendert Frames für Filme/Animationen. Die > primäre Aufgabe der Grafikkarte ist das Rendern von Frames, um sie > anzuzeigen. Danke für die Antwort. Woher weiß man sowas!? Respekt! Aber das muss ich erstmal verstehen. Einfach gesagt heißt das, dass Blender beim Rendern ja den Film erstellt und kodiert, die Graka aber in Echtzeit permanent Frames rendert?
Torben S. schrieb: > Danke für die Antwort. Woher weiß man sowas!? Ein Hinweis könnte sein dass du deinen Monitor in die Grafikkarte einsteckst. Das könnte in dir den Gedanken aufkommen lassen, die Graka ist dazu da Bilder auf eben diesen Monitor zu bringen.
Torben S. schrieb: > Wenn man mit Blender, ein primitives 3D-Modell mit Meshes erstellt, wird > da die Grafikkarte irgendwie beansprucht? Auch da kannst Du die Cycles Render Preview anschalten, z.B. für realistisches Licht oder Schatten.
Ich habe eine Szene erstellt aus Polygonnetzen, also eine geometrische Beschreibung eines dreidimensionalen Raumes. In Blender kann ich meine Perspektive auf die Szene ändern. Ich frage mich aber, ob in dieser Rohform meine Graka schon irgendwas tut, außer die Bildausgabe. Muss sie das 3D-Modell schon irgendwie verarbeiten und speichern oder macht das noch die CPU? Ich weiß ich stelle komische Fragen. Warum soll das einer wissen wollen könnte man denken.
Grundsätzlich ist der PCIe Bus für die Kommunikation großer Datenmenge viel zu langsam. Deswegen wird ein möglichst großer Teil der Levelgeometrie, aller Meshs von Objektne und alle notwendigen Texturen und sonstigen zum Rendern notwendigen Daten in das RAM der GPU geladen. Das passiert alles noch bevor überhaupt etwas gerendert wird. Stell es dir als den Zeitabschnitt vor, bei dem du bei einem Game den Ladebalken siehst. Wenn das getan ist, werden zwischen CPU und GPU jetzt nur noch möglichst kleine Datenmengen übertragen. Z.B. wo an welcher Stelle sich die Kamera befindet, in welche Richtung die schaut und wenn sich die Position von Objekten geändert hat, werden auch deren Position und Orientierung im 3d Raum upgedated, die Meshs der Ojekte liegen schon längst im RAM der GPU. Die Menge der Daten muss man hier klein halten, weil der PCIe Bus arschlangsam ist, vergleichen mit den Transferraten zwischen GPU und RAM bzw. CPU und RAM. Die CPU berechnet wo sich was hinbewegt, wie es sich drehen soll usw., aber die CPU berechnet nicht die Eckpunkte des gedrehten und bewegten Objekts, denn das macht die GPU. Die CPU gibt somit eigentlich nur die Anweisung. Nehmen wir mal an, wir haben im Spiel eine Statue aus 10000 Eckpunkten. Dann muss die CPU nur wissen, wie ist die Lage im Raum, wie soll das Gesamtobjekt gedreht werden und wo soll die neue Lage im Raum sein usw.. Die eigentliche Berechung aller dieser 100000 Eckpunkte macht dann die GPU. Die Hauptlast der Berechnungen trägt somit die GPU, aber das kann sie gut, da man das gut paralellisieren kann. Was man auch noch wissen sollte, damit ein Objekt im 3d Raum um den eigenen Mittelpunkt gedreht werden kann, muss es zuerst an Position 0,0,0 im X, Z, Y transformiert werden, dann kann man es drehen und dann wird es mit der neuen Information an gedrehten Eckpunkten wieder zurücktransformiert. Das gilt für alle Einzelobjekte. Den Job macht die GPU. Die CPU ist quasi nur Zuständig für die Anweisungen. Allerdings muss sie für die Kollisionserkennung trotzdem wissen, wie sich ein 3d Objekt im Raum befindet. Deswegen rechnet diese oftmals nicht mit den komplexen geometrischen Objekten, sondern mit vereinfachten Kollisionsboxen. Bei denen ist es dann die CPU, die die Vertexe aller Eckpunkte dder Kollisionsboxen berechnet. Deren Anzahl ist überschaubar, das kriegt die CPU noch hin, solange es nicht zu viele Objekte werden. Oben habe ich gesagt, dass ein möglichst großer Teil der Levelgeometrie in das RAM der GPU geladen wird. Das ist bedingt richtig, es muss halt ins RAM passen. Allerdings gibt's auch größere Spielwelten, die da nicht komplett reinpassen. Deswegen zerlegt man deren Levelgeometrie in kleine Häppchen und überträgt die Häppchen dann Häppchenweise vom RAM der CPU über den PCIx BUS in das RAM der GPU. Das wird bei Spielen wie bspw. Fallout 3 und Skyrim so gemacht. Die Laden diese Häppchen sogar von der Festplatte/SSD nach. Die eigentlichen Objekte wie Häuser, Brotkorbe, Tische, Bootstege, Bäume usw. der Parzellen sind da aber meist nur genererisch und liegen im RAM bereits vor, die wurden am Anfang da reingeladen. Deswegen muss die CPU nicht alle Meshs zur GPU schicken, sondern nur das Mesh mit den "Landdaten", sowie Informationen wie, da ist ein generischer Baum vom Typ XY mit der und der Drehrichtung, da ein Haus Typ Z usw.. mit der und der Drehrichtung und Lage. Die GPU nutzt somit die Meshdaten der Objekte, die sie schon im RAM hat mehrmals, die werden nicht ständig neu upgedated, sondern höchstens, wenn Platz geschaffen werden muss und ne Wüste keine Bäumne enthält, sondern Kakteen, ab und zu mal ausgetauscht. Während eine Parzelle geladen wird, wird eine alte, die hinter dir weiter hinten liegt, aus dem RAM der GPU wieder entfernt. Grundsätzlich kann man sagen, die CPU sagt wo sich ein Objekt im Raum befindet und wie er im Raum liegen muss und die GPU berechnet dann alle neuen Eckpunkte des 3d Drahtgittermodells dieses Objekts die sich aus den Anweisungen Drehe, Bewege usw. von der CPU ergeben. Da das Updaten von Positions- und Lagedaten von Objekten in einer Spielwelt von der CPU gemacht wird und die Updates über den lahmen PCIe Bus kommen, bevorzugt man es für alles mögliche statische Objekte zu verwenden, die sind dann fest in das Landschaftsbild eingearbeitet und lassen sich im Spiel somit nicht bewegen. Die wenigen Objekte, die das nicht sind, das sind die, die beweglich sein sollen und da muss die CPU dann Schwertsarbeit leisten. Das gilt erst Recht, wenn noch Physik im Spiel ist und die Objekte voneinander abhängig sind. Deswegen versucht man deren Menge möglichst gering zu halten. Die GPU rendert somit eigentlich nur statische Szenen. Inwieweit sich das durch Physikkarten bzw. die Implementierung von Physikeinheiten in GPUs bzw. die Generalisierung deren Vertextshader geändert hat, weiß ich momentan nicht. Mein Wissen basiert noch auf der vor OpenGL 2.0 Ära und da gab es noch so etwas wie ne DisplayList, heute wird das aber mithilfe der Shader ein bisschen anders gemacht. Und zu deiner Frage, wie man das lernt. Nun, ganz einfach. Man lernt wie die 3d APIs, wie Direct3D oder OpenGL arbeiten, dann kriegt man das mit. Ein tiefes Verständnis über die GPU kann ebenfalls helfen. Manches erkennt man auch einfach anhand von Beobachtung. Bei der ganzen Geschichte geht es jetzt übrigens nur um die 3d Drahtgitterdaten. Das draufkaltschen von Texturen auf Flächen, sowie die Berechnung der Beleuchtung erledigt die GPU. Und mit Shadern geht das alles wesentlich flexibler. Die CPU berechnet höchstens, wo sich die Lichtquellen befinden, mit welchem Kegel die in welche Richtung scheinen soll usw.. Das ist dann z.b. notwendig, wenn das Spiel über einen Tag und Nacht Rythmus verfügt. Dann müssen die Lichtquellen auch noch ab und zu upgedated werden. Und was Blender betrifft, das rendert die Szenen nicht in Echtzeit, sondern im Hintergrund und kann sich für einen Frame daher auch wesentlich mehr Zeit lassen. Außerdem gibt's da noch andere Methoden, wie Raytracing, welches es für die Echtzeitrenderingtechniken erst seit kurzer Zeit mit GPU Unterstützung gibt und das auch nur stark vereinfacht. Das was du in Blender in Echzeit im Programm siehst, ist ne ganz normale Rendertechnik, wie sie auch bei Spielen zum Einsatz kommen. Und wenn du dir das anguckst, dann sieht das auch alles wesentlich einfacher und schlichter aus, als ein Frame, das mit komplexen Renderalgorithmen mit großem Aufwand berechnt wurde. Damit ein Computer die Physik und Bewegungsdaten von noch viel mehr einzelen Objekten in Echtzeit berechnet werden kann, muss somit die Anbindung zwischen GPU und CPU besser werden. Optimal wäre, wenn GPU und CPU sich auf einem Die befinden würden und die Anbindung des RAM noch viel breitbandiger erfolgt. Quasi so, wie bspw. das GPU Ram bei einer dedizierten GPU angebunden ist. Da man heutzustage aber noch in Memory DIMMs denkt, wird das vorerst nicht passieren. Außerdem ist die Anzahl der Pins einer CPU schon jetzt stark begrenzt. Eine Lösung wäre vielleicht, wenn man wieder CPU Slots, statt Sockel einführt. Dann könnte man das RAM viel breitbandiger auslegen, müsste es aber auch fest auf die Platine des CPU Slots löten. Die Besten Chancen für so etwas haben wohl die Konsolen. Bis dahin wird die Schnittstelle zwischen CPU und GPU das Bottleleg bleiben und die Spielenentwickler müssen sich an die Begrenzungen dieses Bottleleg halten und um diese Gegebenenheiten eben herumprogrammieren.
Ach noch etwas. Das defomieren von Meshobjekten ist auch keine einfache Sache. Für die CPU wäre das sehr viel Rechenaufwand. Mit den modernen Vertexshader der GPU dürfte das etwas besser gehen.
Nano schrieb: > Grundsätzlich ist der PCIe Bus für die Kommunikation großer Datenmenge > viel zu langsam. Am Beispiel einer der zur Zeit leistungsstärksten GPUs für HPC, werden extreme sichtbar. https://www.nvidia.com/de-de/data-center/a100/ Aus dem Datenblatt: Speicherbandbreite GPU-Ram: 1600GB/s Interlink zwischen mehreren GPUs: 600GB/s PCIe: 64GB/s Damit ist PCIe hier um den Faktor 25 langsamer als der Grafikram.
:
Bearbeitet durch User
Torben S. schrieb: > Axel S. schrieb: >> ...Die primäre Aufgabe der Grafikkarte ist das Rendern von Frames, um sie anzuzeigen. > Das gilt Heutzutage so höchsten nur für Spiele. z.B. im Bereich CAD/3D-Rendering usw. ist die Anzeige eher nebensächlich und die Berechnung erheblich wichtiger. Da kann es pro "Frame" auch mal eine paar Minuten dauern. Oder z.B. beim Vidio-Encoding kann es auch gut sein das die GPU hier mehrere hundert Frames pro sekunde umwandelt oder aber auch viel weniger als die für die Anzeige benötigte Framerate. Das läuft alles im Hintergrund und es wird ggf. in der Zeit was ganz anderes angezeit oder aber nur Teilmengen als Preview davon usw. Das Display-Interface/Display-Controller/Framebuffer ist in der Regel nur noch ein (kleiner) Teil der Funktionen auf so einem Chip. Der große Teil sind eher die verschiedenen Berechnungseinheiten die bei Bedarf auch unabhängig genutzt werden können. Je nachdem wie die Software programmiert ist kann es durchaus sein das auf dem Bildschirm ein primitives "Bitte Warten" vor sich hin blickt während der Rest der GPU unter den Berechnungen "glüht" und das Ergebnis lediglich an den CPU kondolierten Programmteil zurück gibt. Oder aber z.B. auch wie von Nano erwähnt kann es sein der die GPU für die Bildausgabe schon mal ein vereinfachtes "Preview" erzeugt während andere Teile der GPU zusammen mit der CPU im Hintergrund das eigentliche Ergebnis berechnen. Allgemein gibt es den immer gleichen Ablauf bei der Zusammenarbeit CPU/GPU nicht. Das ist alles von der konkreten Software (und auch innerhalb dieser kann verschiedenes vorkommen je nach dem was gerade genau gemacht werden soll) und das ggf. auch noch abhängig davon das die konkrete Hardware an Möglichkeiten bereitstellt. Als Beispiel mal anschauen was so alles an Funktionsblöcken vorhanden ist: https://de.wikipedia.org/wiki/Grafikprozessor (schon etwas arg vereinfacht diese Darstellung) https://www.extremetech.com/gaming/288132-intel-details-changes-to-gen-11-graphics-architecture https://software.intel.com/sites/default/files/managed/db/88/The-Architecture-of-Intel-Processor-Graphics-Gen11_R1new.pdf
Ich muss hier mal ein paar Worte loswerden. Ich habe es noch nie erlebt, dass einem in einem Forum so gut geholfen wird wie hier und da bin ich nicht der Einzige, der so denkt. Es zeugt von sehr viel Hilfsbereitschaft. Ich kenne mitlerweile viele aus meiner BBS-Klasse, die hier regelmäßig Hilfe suchen. Leider kann ich nicht mehr sagen als danke.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.