Forum: PC Hard- und Software Zusammenspiel CPU und GPU


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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.

von leo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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
von foobar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 )

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man mit Blender, ein primitives 3D-Modell mit Meshes erstellt, wird 
da die Grafikkarte irgendwie beansprucht?

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. M. (elmo64)


Bewertung
0 lesenswert
nicht lesenswert
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
von Irgend W. (Firma: egal) (irgendwer)


Bewertung
0 lesenswert
nicht lesenswert
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

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.