Seht das mal als FollowUp von diesem Thred.

Ich hab nochn kleines Verständnisproblem bezüglich dem Rendern in den Framebuffer.

Der Framebuffer ... befindet der Sich auf der GraKa?

Wenn ja, dann macht doch der Videocapturer folgendes:

Warten bis alles in Framebuffer is (CPU -->BUS-->GraKaSpeicher) dann
FrameBufferinhalt in ein BMP rendern (GraKaSpeicher -->BUS --> RAM)
BMP in AVIStream schreiben (RAM --> RAM)

Also sind am Rendervorgang beteiligt:

CPU: Managed den eigentlichen Rendering ablauf, Ruft Grafikbefehle auf
GraKa(GPU): Verarbeitet Vertexdaten, Schreibt diese in FrameBuffer
BUS: Verbindet beide einheiten.

Wenn man maximale Leistung will, braucht man also einen möglichst fetten Bus, ne Schnelle GraKa und ne möglichst schnelle CPU. Wobei wohl der Bus (da unsymetrisch) das Nadelöhr darstellen wird.

Sind diese annahmen so richtig?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Im Groben ja. Videorendering ist immer gleich Readback von der Grafikkarte über den BUS, was auch IMMER bedeutet dass CPU und GPU synchronisiert werden müssen. Leider ist der AGP-Bus für Readbacks von der Grafikkarte sehr ungeeignet und selbst schnelle Karten schaffen nen Readback von ~200 MByte/s. Mit der GF6-Reihe wurde das zwar auf 600 MByte/s verbessert, und mit PCIe auf ~1 GByte, allerdings ist dann immernoch die Synchronität zwischen CPU und GPU die Readbacks von der Graka benötigen.

Und beim Rendern in ein Video kommen noch andere wichtige Faktoren hinzu : Rendert man unkomprimiert in eine AVI-Datei, so ist das totaler Stress für die Festplatte, da man dort pro 10s Video >100 MByte an Daten schreiben muss. Komprimiert man, ist das Stress für die CPU, die aber durch das Rendering bereits beansprucht wird. Man muss hier also abwägen zwischen Größe der AVI-Aufnahme (640x480 ist übrigens im Normalfall das Maximum, bedingt durch den Codec) und der Kompressionsmethode (DivX mit 640x480 während des Renderns auf Platte speichern schafft wohl kaum ein Rechner bei brauchbaren Frameraten). In deiner Auflistung oben (schneller BUS, schnelle CPU und schnelle Graka) hast du also noch "schnelle HD" vergessen.

P.S. : Schau dir mal eine ältere FRAPS-Version an, die ich auch manchmal nutze im Videos meiner 3D-Anwendungen zu capturen. Da kannst du dir ganz schnell nen Überblick über die Performance des Systems im Bezug auf Echtzeit-Capturing machen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Echtzeit ist gar nicht sooooo wichtig. Da ich ja Frame für Frame capture und dann in die Datei schreibe, ist die Zeichengeschwindigkeit nicht so wichtig. Allerdings würde ich halt schon gern in endlicher Zeit Videos rendern, nicht unbedingt so langsam wie bei 3DS Max.

Die Atom Animationen können ruhig auch mal über nacht rendern, wenn man so 3 Min Video (25*180 = 4500 Bilder) oder auch mal 5 min(7500 Bilder) brauch.

_________________
Blog: kevin-fleischer.de und fbaingermany.com