Kennt jemand zufällig ein Experimentalsystem oder auch ein käufliches System, mit dem es möglich ist HD-Video (full HD!) zu mischen und darin kleine Figuren einzublenden, die man selber programmieren kann? Ich habe dazu diesen alten thread von vor 6 Jahren gefunden, an den ich mich aber nicht dranhängen wollte. Beitrag "DSP Video Mischer Mixer bauen" Dort wird ausgeführt, dass die konventionellen DSPs zu langsam sein dürften, um Video zu mischen. Ich habe Erfahrungen mit kleineren Applikationen, z.B. Audio mit dsp-PIC und möchte das mit Video kombinieren. Es geht um die Anzeige von grafischen Symbolen, nach Auftreten von detektierten Signalen. Ich habe schon eine Ähnliche Anwendung gemacht, dabei ging es um eine Art von Musikdemonstration für Gehörlöse, war aber auch VGA, wie im Beitrag, den ich gelinkt habe.
Wozu DSP? Soll das Ganze echtzeitfähig sein? Ansonsten werden Videos ganz normal auf dem PC bearbeitet.
Mark B. schrieb: > Wozu DSP? Soll das Ganze echtzeitfähig sein? das könnte wohl sein, lieber Mark, denn er sucht ein ... "System, mit dem es möglich ist, HD-Video (full HD!) zu mischen" und "dass die konventionellen DSPs zu langsam sein dürften, um Video zu mischen." Was ich kenne: Es gibt Videomischplattformen fürs broadcasting, mit denen bis zu 4 Videos mit einem Gerät geschaltet werden können. Mehr Kanäle kriegt man über die Verkabelung. Die braucht man meistens aber nicht, weil sie dann eher umschalten, statt zu mischen. Die Quellen können beliebig sein: PCs, HD-Player, blue-RAY und was auch immer, weil die Formate konvertieren. Die arbeiten auf Video-DSP-Basis und haben teilweise ASICs drin, zum Skalieren und Drehen der Bilder. Damit kriegt man die Überblendungen und Einblendungen leicht hin, um Werbung und Texte anzuzeigen wie bei N24 oder um Geisterbilder zu produzieren und die Namen der Interviewpartner zu nennen. Die Geräte funktionieren mit DSP-Karten und Einschüben unterschiedlicher Hersteller. Da gibt es eine Reihe von Spezialisten, die aber meistens nur im Auftrag arbeiten und/oder an die TV-Anstalten und Videostudios liefern, die Rederanimationen machen. Die benutzen ganze Batterien von Ausstattung. Es gibt auch Systeme, die man frei programmieren kann und sogar Software zum Konfigurieren. Suche mal nach "Video-DSP-Mix-Farm"! Aber: Ich hatte da auch schon rankommen wollen, aber das, was man mir angeboten hatte, lag alles jenseits des Erschwinglichen. Die Kosten für alleine ein PC-System liegen da schon im 5-stelligen Bereich. In der Bucht gibt es teilweise immer mal wieder so eine ausrangierte Platine zu kaufen. Geht meistens für 1-2 Tausender weg, weil sich die einer unter den Nagel reisst, falls bei ihm ein altes System ausfällt. Die Dinger sind nämlich einer hohen Flutuation unterworfen und meistens schon 2 Jahre nach Erscheinen nicht mehr im Programm, weil sie technisch überholt sind und es was Neues gibt.
Videoonkel schrieb: > Aber: > > Ich hatte da auch schon rankommen wollen, aber das, was man mir > angeboten hatte, lag alles jenseits des Erschwinglichen. Die Kosten für > alleine ein PC-System liegen da schon im 5-stelligen Bereich. Ja eben. Wer sowas einsetzt, der betreibt wohl ohnehin professionelle TV- und Video-Produktion. Also zum Beispiel Fernsehsender, oder die Firmen die für die Sender Beiträge produzieren. Die haben dann natürlich auch das Geld für sowas. Mal eben so zum Basteln wird sich das keiner kaufen. Es sei denn man hat zu viel Geld ;-)
:
Bearbeitet durch User
Zuviel Geld habe ich sicher nicht, eher zu wenig, weil wir Informatiker als Krone der Schöpfung nach wie vor total unterbezahlt sind. Ich möchte aber eine Plattform haben, mit der ich eigene Video- und Grafikeffekte machen kann. Geht auch um meine Mannheimer Freundin, die Kunst studiert und da was vorhat. Ich mache zwar auch Elektronik, habe aber nicht das Wissen sowas selber zu entwickeln. Ich suche mal weiter.
Martin K. schrieb: > Ich möchte aber eine Plattform haben, mit der ich eigene Video- und > Grafikeffekte machen kann. Und nochmal die Frage: Wozu muss es echtzeitfähig sein? Das treibt den Preis enorm in die Höhe. Generell wäre es hilfreich, die Anforderungen mal konkret und vernünftig aufzuschreiben. Das sollte einem Informatiker doch leicht fallen.
:
Bearbeitet durch User
Ich schrieb: > https://www.blackmagicdesign.com/products/atemtelevisionstudio ist mit > unter 1000 Euro dabei. Das ist aber nur der Videoumschalter für bis zu 6 Kameras, wie es scheint. Soweit ich das sehe, kann der nur schalten und mischen - gesteuert vom PC oder der Konsole. Die netten Effekte, die noch beschrieben sind, werden dann wohl auf der digitalen Live-Konsole laufen, die links unten im Bild zu sehen ist und mit 5000,- Dollars notiert ist :-) Und frei programmierbar wird es auch nicht sein. Ich verweise auf diesen Beitrag hier, falls sich jemand beteiligen möchte: Beitrag "Re: Suche Mitwirkende für Universal-FPGA board"
Jürgen S. schrieb: > Das ist aber nur der Videoumschalter für bis zu 6 Kameras, wie es > scheint. Soweit ich das sehe, kann der nur schalten und mischen - > gesteuert vom PC oder der Konsole. Die netten Effekte, die noch > beschrieben sind, werden dann wohl auf der digitalen Live-Konsole > laufen, die links unten im Bild zu sehen ist und mit 5000,- Dollars > notiert ist :-) Soweit ich da verstehe, ist die kleine Kiste ein Umschalter mit ein paar einfachen Effekten, und das große Teil nur ein schickes Bedienpult dafür: "Now you can save thousands of dollars by eliminating external character generators! It’s simple to load up to 20 graphics for use with the two built in media player frame stores for exciting custom titles and logos! Use the included Photoshop plug-in to download graphics from Photoshop directly into the ATEM media pool. Now you can get titles and graphics on air in seconds!" Ich hatte das Teil mal als HDMI-Switch verwendet - ist meines Wissens die preiswerteste Kiste, die richtig mischt, wo also beim Umschalten der HDMI-Datenstrom nicht abreißt. Wenns für den TO ausreicht, wäre es halt bezahlbar und fertig entwickelt.
Martin K. schrieb: > Geht auch um meine Mannheimer Freundin, die Kunst studiert und da was > vorhat. Wenn es in Richtung Video-Installation als Kunstprojekt geht: Da gibt es fertige Software für. Zum Beispiel Resolume. https://resolume.com/ http://www.thepixelart.com/best-software-for-visual-performance-artist/ http://audiovisualacademy.com/blog/en/2012/11/09/vj-real-time-visual-performance-software-overview-1/
Hallo Martin, damit man dir bei deinem Projekt weiterhelfen kann, müsstest du mit etwas mehr Infos rausrücken: - Wieviele Videoquellen mit welcher jeweiligen Auflösung müssen gleichzeitig angezeigt werden können? Welche Bildwiederholraten sollen erreicht werden? - Wieviele Ausgänge soll das System haben? HDMI? Video? Netzwerk? - Welche Signale sollen erkannt werden? - Was soll eingeblendet werden? - Wieviel Verzögerung ist Zulässig zwischen Ein- und Ausgang - Welche weiteren Anforderungen gibt es? Strom? Baugröße? Wetterfestigkeit? Temperatur? ...? Wichtig wäre auch zu wissen, was absolutes muss ist und was wünschenswert wäre. Z.B. 1 gleichzeitiger HDMI Eingang ist muss, mehrere wären besser. Ich glaube wenn wir das haben, lässt sich hier deutlich zielgerichteter arbeiten. MfG EinMichael
Also wetterfest muss es nicht sein :-) Es muss aber programmierbar sein, d.h. ich muss die Software austauschen können und da habe ich bei den gekauften Lösungen eher schlechte Karten. Der Bildmischer ist nicht das Richtige. Ich möchte selber in Echtzeit Grafiken und Linien auf den Schirm zeichnen, so wie es auch mit dem PC geht. Es braucht also einen Bildschirmspeicher und einen Mischer. Ich habe das ja am PC entwickelt und am Laufen, aber der I7 ist mit Windows nicht dafür gemacht, schnell zu zeichnen. Zum Mischen: Eine Form ist z.B. das ich auf einen - sagen wir grünen Untergrund - male und der Video-DSP mischt dort, wo ich nichts male, ein Video rein, das von Aussen kommt. Videoquellen zunächst eine, optimal natürlich zwei. Auflösung full HD 1920 x 1080. Verzögerung Ein-Ausgang möglichst nur 1 Bild, also direkt drübergeblendet.
:
Bearbeitet durch User
Martin K. schrieb: > Ich habe das ja am PC entwickelt und am Laufen, aber der I7 ist mit > Windows nicht dafür gemacht, schnell zu zeichnen. Ja komisch, wie machen das dann die ganzen 3D-Spiele? ;-)
Die Nutzen die Grafikhardware. Viel Shading, Ausmalen und Drehen geht in Hardware. Vergleiche mal eine native Lib mit OpenGL bei jeweils mit und ohne HW-Support. Aber mit denen geht eben nicht alles.
Audiomann schrieb: > Die Nutzen die Grafikhardware. Viel Shading, Ausmalen und Drehen geht in > Hardware. Vergleiche mal eine native Lib mit OpenGL bei jeweils mit und > ohne HW-Support. > > Aber mit denen geht eben nicht alles. Schon recht. Einen handelsüblichen PC bekommt man heutzutage freilich so gut wie gar nicht ohne entsprechende 3D-fähige Grafikhardware, selbst wenn sie nicht separat ist sondern auf dem Mainboard oder auf dem CPU-Die integriert.
:
Bearbeitet durch User
Beim PC dürfte dass größte Problem sein das Videosignal möglichst latenzfrei in den RAM/VRAM zu bekommen. Das Mischen sollte selbst integrierte Grafikkarten nicht sonderlich ins schwitzen bringen. Ein Blick in die OpenCL-Ecke kann dabei bestimmt auch nicht schaden.
Von Blackmagic gibts die Decklink Quad mit 4 SDI-Ein/Ausgängen. Kostet frisch so 800-1000EUR, gebraucht mit Glück so 400EUR. Wenn man keine SDI-Quellen hat (Semiprofi-Kameras haben üblicherweise schon SDI), braucht man noch HDMI-SDI-Konverter, da tuns aber die billigen von Ebay (30-40EUR). Mit genügend PCIe-Slots könnte man auch die älteren HDMI-Capture-Karten von BM nehmen. Zur Verarbeitung dann noch eine Nvidia-Grafik-Karte rein und CasparCG installieren. Damit kann man dann problemlos die SDI-Eingänge skalieren/transformieren, überlagern, faden, farblich verändern, mit Videos und HTML-Seiten zusammenmischen etc pp. Braucht aber durchaus einige Einarbeitung, das ganze ist sehr komplex. Dafür hat es mit Quasi-Echtzeit keine Probleme und CasparCG hat ein schönes Steuer-Interface via telnet, über das man seine Abläufe scripten kann.
Nur zur Anregung, ob das deinen Kriterien entspricht, kann ich nicht genau beurteilen. - Div. Video-Boards von Lattice Semi mit dem ECP3. Der ECP3 ist für HDMI echt nett, aber man muss sich da recht einarbeiten oder sich die Cores einkaufen - Milkymist/Migen-Ansatz. Weiss nicht, wie's da mit HDMI steht. Grüsse, - Strubi
Kauf Dir am Besten einen HDMI-Framegrabber (mit 2 bzw. 4 Eingängen). Bei 4 Eingängen braucht es aber schon 16er-PCIe. Die Bilder können dann in die GraKa übertragen werden und per D3D bzw. OpenGL als Texture weiterverarbeitet und ausgegeben werden. Realzeitfähigkeit(?): je nach Progkenntnis und Fähigkeit läuft das ganze auf ein paar Frames Latenz hinaus.
Also wenn es wirklich nur darum geht Symbole einzublenden, dann ist das Hauptproblem HDMI. Nimm doch VGA oder Komponentensignale. Da kannst Du dann, je nach gewünschter Auflösung der darzustellenden Symbole sogar mit einem einfachen ATMega arbeiten. Werden dann halt nur Klötze.
Was soll dann denn genau gemacht werden? Martin K. schrieb: > Zum Mischen: Eine Form ist z.B. das ich auf einen - sagen wir grünen > Untergrund - male und der Video-DSP mischt dort, wo ich nichts male, ein > Video rein, das von Aussen kommt. Das müsste meines Erachtens sogar noch im PC mit SW+GraKa gehen.
> Das müsste meines Erachtens sogar noch im PC mit SW+GraKa gehen.
Kann CasparCG auch, kostet übrigens nichts und man muss nichts selber
programmieren.
Georg A. schrieb: >> Das müsste meines Erachtens sogar noch im PC mit SW+GraKa gehen. > > Kann CasparCG auch, kostet übrigens nichts und man muss nichts selber > programmieren. Fürs Mischen nicht, aber ich möchte eigene Kreationen machen. Dazumischen ist nur ein Teil des Themas.
Martin K. schrieb: > Fürs Mischen nicht, aber ich möchte eigene Kreationen machen. > Dazumischen ist nur ein Teil des Themas. Deine "eigenen Kreationen" kannst Du mit 'nem stinknormalen PC machen. Dessen HDMI-Ausgang schließt Du als eine der Signalquellen an Deinen Mischer, genauso wie Du es mit den Kameras oder whatever auch vorhast. Damit "reduziert" sich das Problem ausschließlich auf den Mischer. Der ist so schon kompliziert genug, weil es darum geht, mehrere völlig asynchrone Bildquellen zu synchronisieren. Da nämlich liegt der sprichwörtliche Hase im Pfeffer, das ist die Crux jeder Live-Video-Verarbeitung. Im professionellen Bereich werden Kameras verwendet, die einen externen Synchroneingang haben, so daß ein Bildsignal als Referenz für die Takterzeugung aller anderen verwendet werden kann, womit das Mischen recht einfach wird. Ohne so ein Referenztaktsystem aber ... ist das alles andere als trivial.
Rufus Τ. F. schrieb: > Ohne so ein Referenztaktsystem aber ... ist das alles andere als > trivial. Hmmm, ich habe am Decklink-Recorder keinen Referenztakt gefunden: https://www.blackmagicdesign.com/de/products/decklink/techspecs/W-DLK-06 http://www.da-x.de/de/blackmagic-decklink-mini-recorder.html ( < 150€ ) ?!
> Im professionellen Bereich werden Kameras > verwendet, die einen externen Synchroneingang haben, so daß ein > Bildsignal als Referenz für die Takterzeugung aller anderen verwendet > werden kann, womit das Mischen recht einfach wird. Wobei alle modernen Bildmischer (zB. alle Blackmagic ATEMs/TVS) auch ohne REF auskommen. Die haben ohnehin einen Framebuffer und wenn's zu sehr auseinanderdriftet, wird halt alle x Minuten ein Frame verdoppelt bzw. ausgelassen. Ist so oder so auch sinnvoll, professionelle Videofunkstrecken ala Teradek Bolt oder IDX haben nämlich beim Sender an der Kamera keinen REF Ausgang, d.h. die mobile Kamera läuft frei.
Martin K. schrieb: > Fürs Mischen nicht, aber ich möchte eigene Kreationen machen. > Dazumischen ist nur ein Teil des Themas. Nochmal und wie oben schon erwähnt: Schreibe alle Deine Anforderungen einmal sauber auf. Quasi ein Lastenheft. Danach siehst Du selbst klarer was Du eigentlich willst, und wir können Dir besser helfen.
:
Bearbeitet durch User
Mark B. schrieb: > Schreibe alle Deine Anforderungen einmal sauber auf. Quasi ein > Lastenheft. Ein Lastenheft für ein Hobbyprojekt ist wohl leicht verfehlt. Gleichwohl kann man selbstredend Anforderungen formulieren. Rufus ?. F. schrieb: > Deine "eigenen Kreationen" kannst Du mit 'nem stinknormalen PC machen. Ich hatte schon dazu geschrieben, dass eine PC-Plattform nicht reicht. Ich brauche gewissermaßen Zeichentrickfilm in Echtzeit. Sagen wir mindestens 15 Bilder die Sekunde mit jeweils 500.000 pixeln bestehend aus Umrissen und Ausfüllfunktionen. PC mit OpenGL und schneller Grafikarte bringen momentan maximal 2 Bilder die Sekunde. Habe mir zum Vergleich mal Furmark angesehen: Der mal so in etwa ein Viertel dessen, was ich möchte, bei 40 frames, allerdings nur 1280x1024. Bei full HD sind es es auch schon unter 10. Liegt also nicht an meiner Programmierung. Nehmen wir als Beispiel eine Figur, die eine Art Schlange darstellt, welche sich aus Kreisen zusammensetzen, die schräg auf den Betrachter zukriecht. Jeder Kreis muss einzelngezeichnet werden, damit sich die Hülle der Schlange ergibt. Konkret wäre es z.B. 1000 eng liegende Kreise mit jeweils 200 bis 1000 Punkten Durchmesser, je nach Umfang.
Martin K. schrieb: > Mark B. schrieb: >> Schreibe alle Deine Anforderungen einmal sauber auf. Quasi ein >> Lastenheft. > Ein Lastenheft für ein Hobbyprojekt ist wohl leicht verfehlt. Nein, ist es nicht. Es sagt ja keiner dass es formale DIN-Normen erfüllen muss. Trotzdem ist es sinnvoll ein halbwegs vernünftiges Dokument aufzusetzen. Selbst wenn es nur ein bis zwei Seiten hat (darf natürlich auch mehr sein). > Rufus ?. F. schrieb: >> Deine "eigenen Kreationen" kannst Du mit 'nem stinknormalen PC machen. > Ich hatte schon dazu geschrieben, dass eine PC-Plattform nicht reicht. > > Ich brauche gewissermaßen Zeichentrickfilm in Echtzeit. Sagen wir > mindestens 15 Bilder die Sekunde mit jeweils 500.000 pixeln bestehend > aus Umrissen und Ausfüllfunktionen. PC mit OpenGL und schneller > Grafikarte bringen momentan maximal 2 Bilder die Sekunde. Jedes 3D-Spiel auf dem Linux PC bietet wesentlich mehr Bilder pro Sekunde als das. Auch in entsprechend hoher Auflösung.
:
Bearbeitet durch User
Die 3D-Spiele nutzen aber sehr geringe Auflösungen und übertragen nur eine begrenzte Anzahl an Flächen an die Grafikarte, die diese an ausfüllt. Ich spiele ja selber viel auf LAN-Parties und habe im Gefühl, was da geht und was nicht. Auch Linux auf der X-Box hatte ich schon im Betrieb.
Hmmm... Tripple Full-HD sind bei VJ (Video Jockeys) heutzutage eher die Regel als die Ausnahme, das läuft auch alles flüssig auf PCs/Laptops. Häufig auch mit selbstgeschriebener Software oder mit Max/Jitter. In einem Theaterprojekt vor etwa 4 Jahren, wurde mit einer mit dem processing-framework geschriebenen Software 6xFull-HD + 1xXGA ausgegeben (jeder Ausgang eigener Content), inkl. eingebetetem Live Video (allerdings nicht HD), ansonsten nur echtzeitgenerierter Content (gesteuert per MIDI)! Das ganze lief auf einem Ubuntu System mit AMD-Prozessor und 4 Grafikkarten, ohne grosse Latenz und absolut ruckelfrei. P.S. ich war selber nur Operator, und habe die Software nicht geschrieben, kann darum leider keine Tipps geben. Fakt ist, es hat funktioniert.
Die Frage ist halt mit welcher Latenz was das für ein Content war. Einfach ein paar Farbverläufe sind keine Anforderung. Das ist es aber, was ich das meistens sehe.
Mark B. schrieb: > 500.000 pixeln Das wäre ja nur ca. 1/4 der Videoauflösung. Warum das? > PC mit OpenGL und schneller > Grafikarte bringen momentan maximal 2 Bilder die Sekunde. Bist Du sicher, dass Du das auch so implementiert hast, dass es überhaupt eine Chance hat schneller als 2fps zu laufen?
Die VJs benutzen meistens Objekt-Mapping. Will heissen: verschiedene weisse Objekte werden mit Beamern angestrahlt, und deren Form wird dann im Computer bekannt gemacht, damit es entsprechend seiner 3 dimensionalen Form als Projektionsfläche genutzt werden kann, mit entsprechend entzerrtem Bild. Schwierig zu erklären. Der Lichtdesigner von Bülent Ceylan zeigt das hier recht gut: https://www.youtube.com/watch?v=caBnCExlKGg wobei die Projektionsflächen normalerweise natürlich statisch sind. Dafür wird bei VJs der Content in Echtzeit erzeugt, passend zur gerade laufenden Musik halt, an einer Party lässt sich dann diese 3-Dimensionalität noch effektvoller nutzen. In kleineren Dimensionen als in diesem Video funktioniert das Tiptop mit handelsüblichen Rechnern.
Rasputin schrieb: > processing-framework Arg... Sorry, ich meinte openframeworks, ich verwechsle die zwei immer :( . Schau's dir mal an: http://openframeworks.cc/
Kontroller schrieb: > PC mit OpenGL und schneller > Grafikarte bringen momentan maximal 2 Bilder die Sekunde Dann machst Du wahrscheinlich was falsch. Es gibt schlicht Wenig Auf dieser Welt was schneller parallel rechnet als eine moderne Grafikkarte. So wie sich das liest müsste es auch ein Prozessor spielend schaffen. Hast du mal ein BeispielBild? Meine Vorstellung von dem was gemacht werden soll und deine Performance aussagen gehen stark auseinander. Der angesprochene Furmark ist ein synthetischer Benchmark der nur die gpu voll Auslasten soll. Das ist kein Maßstab für das was eine gpu darstellen kann.
Ja, zwei Bilder pro Sekunde kann definitiv nicht sein. Bei der Rate schlafen aktuelle CPUs und GPUs doch ein. ;-)
Mark B. schrieb: > Ja, zwei Bilder pro Sekunde kann definitiv nicht sein. Bei der Rate > schlafen aktuelle CPUs und GPUs doch ein. ;-) Mark, ich habe bereits Erfahrung mit der Programmierung von Grakas. Die Zahl der erreichbaren frames hängt vom Umfang der Aufgaben ab. Die Grafikarte steuert zwar bis zu 156fps, wenn ich am limit bin, was der Monitor schon nicht mehr mitmnacht, aber das Zeichnen der Bilder dauert. Rasputin schrieb: > Die VJs benutzen meistens Objekt-Mapping. Will heissen: verschiedene > weisse Objekte werden mit Beamern angestrahlt, und deren Form wird dann > im Computer bekannt gemacht, damit es entsprechend seiner 3 > dimensionalen Form als Projektionsfläche genutzt werden kann Das wäre unter anderem ein zu realisierender Punkt. Die dafür nötigen Stauchungen und Streckungen sind aber trivial und im PC leicht zu realisieren und kämen auch am Ende der Signalkette. Es geht mir momentan mehr um die echtzeitmässige Erzeugung des Inhaltes. Scheinen auch andere zu benötigen. Hier wurde schon mal was Ähnliches angedacht: Beitrag "frei programierbare DSP-Plattform über den PC"
Kontroller schrieb: > Das wäre ja nur ca. 1/4 der Videoauflösung. Warum das? Die 500k Pixel sind nur ein Beispiel. Natürlich wird nicht bei jedem Bild alles vollgeschrieben, also jeder Punkt belegt, aber es sind eben auch nicht nur ein paar hundert Pixel je Objekt. So durchschnittlich eine halbe Million Pixel müssen schon gezeichnet werden und es muss mitunter für mehrere Objekten erfolgen. Das heisst, es gibt komplexe Objekte, die mit Z-Buffering auf 2-dimensionale Objekte umgerechnet werden müssen und alleine schon soviele Rechenschritte erzeugen - ansonsten macht es auch einfach die Menge an Objekten. Ich möchte möglichst viel in einer Plattform machen. Dass ich davon dann mehrere nehmen und mischen kann, ist mir natürlich bewusst. Es ist beim Mischen aber so, dass nicht mehr alles geht, z.B. ist es schwierig, mit einem Bild den Inhalt eines anderen echt zu verdecken. Das Licht addiert sich ja. Das Beispiel von Bülent Ceylon ist auch nicht das, was meinem Bedarf nahekommt. Der Schwerpunkt dort liegt mehr darauf, dass der VJ dort die Projektionsflächen hoch und runterfährt und damit die Bilder in den Raum reinfährt. Ok, nicht schlecht, aber der Bildinhalt dort ist ja relativ statisch oder kommt vom Video. Mir geht es jetzt um die Erzeugung des Videos. Ist aber schon estaunlich, dass selbst die Komiker schon Videoeffekte nutzen. Kennt man ja sonst nur von den Musikern.
Martin K. schrieb: > Mark B. schrieb: >> Ja, zwei Bilder pro Sekunde kann definitiv nicht sein. Bei der Rate >> schlafen aktuelle CPUs und GPUs doch ein. ;-) > > Mark, ich habe bereits Erfahrung mit der Programmierung von Grakas. Die > Zahl der erreichbaren frames hängt vom Umfang der Aufgaben ab. Ja und eben dieser Aufwand kann durch paar Kreise zeichnen nicht so groß sein, als dass auf aktuellen (!) PC-Systemen am Ende nur eine Framerate von 2 Bildern pro Sekunde herauskommt. Das ist schlicht nicht plausibel. Überleg mal, wie viele Objekte in einem First Person Shooter gleichzeitig berechnet und dargestellt und ausgeleuchtet werden. Hältst Du diese Aufgabe für so viel weniger komplex als das, was Du vorhast?
Die Ego-Dinger sind rein 2D, als 2.5D gezeichnet. Ich habe komplexe 3D-Figuren zu berechnen, wie sie bei Filmen verwendet werden. Ich habe ja vorgerechnet, wieviele Operationen es sind.
Martin K. schrieb: > Die Ego-Dinger sind rein 2D, als 2.5D gezeichnet. Weiß nicht wie Du auf die Idee kommst. Die Modelle sind selbstverständlich dreidimensional und die Berechnungen auch, zumindest in vielen Spielen. Dass der Bildschirm am Ende doch nur zwei Dimensionen anzeigen kann ist klar, aber das ist nicht der Punkt.
:
Bearbeitet durch User
Martin K. schrieb: > Die Ego-Dinger sind rein 2D, als 2.5D gezeichnet. > > Ich habe komplexe 3D-Figuren zu berechnen, wie sie bei Filmen verwendet > werden. Also wenn das nicht 3D ist weiss ichs nicht: https://www.youtube.com/watch?v=-sMvKKuU0X4 (Witcher 3, um mal ein etwas schöneres Spiel als Beispiel zu nehmen)
Naja, das sind morphing Effekte, die auf vordefinierte Objekte und Strukturen angewendet werden. Vieles davon ist vorberechnet und gerendert und wird einfach nur eingeblendet. Wir wissen ja, wie gewaltig die Installationen solcher Spiele sind. Der Wind und das Wasser ist z.B. sichtbar geloopt und sicher nicht in Echtzeit gerechnet oder gar dynamisch beeinflussbar. Bei den Spielen kommt es gerade darauf an, dass man mit Grafiktricks einen bestimmen festgelegten optischen Effekt täuschend echt nachahmt, was bei dem Wind auch eindrucksvoll gelingt. Frei rendern mit variabelen Strukturen, Licht und echten parametrischen 3D-Modellen mit allem drum und dran ist schon eine andere Nummer! Wenn man sich vorstellt, jeden Grashalm einzeln modellieren und dessen Biegungen berechnen zu wollen, wird man kirre ;-) Da muss man sich nur mal ansehen, wie lange ein normaler 3D-Renderer wie Cinema, Rhino oder Maya für ein einziges Bild benötigt und auch die nutzen ja die Grafikbeschleunigung. Ein Polygonmodell für ein größeres Gerät, wie es aus dem 3D-Programm kommt, lässt sich oft nicht mal im Drahtgittermodell in Echtzeit drehen - trotz 3D-Beschleunigung, von shading oder gar echten Lichtreflexen ganz zu schweigen.
Rasputin schrieb: > Dafür wird bei VJs der Content in Echtzeit erzeugt, passend zur > gerade laufenden Musik halt Weißt Du ob und welche fertigen Systeme es dafür gibt? Geht das was automatisch oder ist das alles händisch erzeugt? Mark B. schrieb: > Die Modelle sind selbstverständlich dreidimensional und die > Berechnungen auch, zumindest in vielen Spielen. Hier stellt sich einfach die Frage, wieviele Objekte, wie schnell bewegen die sich und wie fein ist das aufgelöst. Die Bewegung in Spielen ist z.B. eher gering und erfordert nicht für alle Objekte eine update Rate von 60 fps. Besonders die Anforderung an die Genauigkeit der Platzierung ist nicht gegeben. Wen juckt es, wenn das Männlein ein paar mm im bild falsch läuft oder die Größe nicht zur scheinbaren Entfernungsänderung passt? In z.B. der Militärtechnik wird da einiges unternommen, um mehrdimensionales Objektverhalten im Raum zu modellieren und zu berechnen und da reichen Grafikchips definitiv nicht aus. Inzwischen werden da sogar Plattformen auf FPGA-Basis angeboten, die 3D-rendern können und mehr oder weniger frei programmierbar sind. Auf youtube gibt es da einiges. Zu dem Thema hier müssen jetzt aber mal Fakten auf den Tisch. Wie hoch ist die Anforderung an die Rechenkapazität? Welche Rechenreserve hat im Vergleich dazu eine Intel-CPU und welche effektive Bandbreite ergibt sich für die a) die RAM-Zugriffe beim Holen/Schreiben von Werten und Adressen sowie b) dem Transport in die Grafikarte und c) was kann eine Grafikkarte alleine, sobald sie von der CPUs Kommandos mit geringer Bandbreite bekommt? Bei den Spielen macht die Grafikkarte allein schon sehr viel, z.B. das Verschieben der Szene und Ausfüllen von Bereichen und die Spiele sind gezielt darauf abgestellt, genau die offerierten Effekte zu benutzen. Was die Grafikkarte kann, dürfte anders nicht besser zu realisieren sein. Das ist natürlich auch limitiert und es gibt Sachen, die die Karten nicht können, aber welche Rechenreserven und Bandbreiten hat dagegen ein spezialisierter DSP? - Ist da die Speicheranbindung besser? In der Regel nicht! Die Leistung solcher Systeme ergibt sich mithin auch und vor allem aus der Parallelisierung mehrerer Karten, die alle für sich Teile der Bilder einer Szene berechnen. Wenn man mehr will, muss man frei konfigurierbare Rechensysteme aufbauen und diese den Aufgaben anpassen, z.B. auf FPGA-Basis und diese mit den einschlägigen Entwurfsystemen wie DSP builder oder System-Generator optimieren. Nur wenn da vorgefertigte Algorithmen und stark konkretisierte pipelines drinstecken, ist man da technisch effektiver. Ansonsten bleibt das Thema Bandbreite, wenn die Software mit CPUs einfach ansolut nicht schnell genug ist, oder eine Parallelität gefordert ist, die die Grafikarten nicht bringen. Die haben ja auch einen Flaschenhals hin zur CPU. was das Laden der MACs limitiert. Da die gut ausgebauten Grafikarten aber heute den typischen Anforderungen der Spiele angepasst sind, werden damit die meisten Anwendungen aus der Grafikecke eigentlich erschlagen.
:
Bearbeitet durch User
Jürgen S. schrieb: > Frei rendern mit variabelen Strukturen, Licht und echten parametrischen > 3D-Modellen mit allem drum und dran ist schon eine andere Nummer! Also zumindest die Licht und Schatteneffekte in solchen Spielen sind schon lange dynamisch und werden in Echtzeit berechnet. Hier: https://unigine.com/en/products/benchmarks/heaven Ist kostenlos und schon viele Jahre alt, kann man selbst frei drin rumfliegen und die Tageszeit (Sonnenposition) einstellen. Da ist nix vorgerendert und bei den Szenen oben im Video von Witcher 3 auch nicht. > Der Wind und das Wasser Prinzpiell geht da einiges: https://www.youtube.com/watch?v=QrsRraVUuM0 ;-)
Klar, aber da wird u.a. shading und mapping verwendet, d.h. vordefinierte Funktionen werden z.T. komplett von der Karte berechnet. Die effektive Auflösung ist bei Weitem nicht der Bildgröße entsprechend und die frame rate ist auch gering. Lediglich einzelne Objekte werden schnell aktualisiert. Die Wellen dürften zudem generisch erzeugt werden und sind nicht die Folge der Lösung physikalischer Gleichungen. Dasselbe gilt für den Effekt der Lichtbrechung. Das alles ist also nicht "echt" erzeugt, sondern nur "fast wie echt gemalt" - so wie eben ein Maler ein Bild malt. Die Mechanismen und Methoden für die Erzeugung solcher pseudorealen Welten sind ja schon seit Bryce und anderen Tools von Kai Krause bekannt und das ist sogar schon 20 Jahre her. Vieles, was Bryce damals in einigen Sekunden an Baum- und Landschaftsbildern malen konnte, läuft heute auf x-mal schnelleren PCs auch seher flüssig durch - ganz ohne Grafikuntestützung. Das ist aber wie gesagt mehr Kunst, als Physik - daher werden heute auch für die Entwicklung solcher engines und Spiele vermehrt Grafiker eingestellt und nicht Programmierer. Um die physikalischen Fakten kommt man aber nicht herum. Wenn man z.B. schnelle Bewegungen auflösen will, dann braucht es eine hohe zeitliche Auflösung und da sind selbst 60Hz wie beim HD schon nicht so arg viel. 60Hz bei full HD an Pixelauflösung sind aber selber durchaus sehr viel, wenn man jeden Pixel individuell gestalten will und nicht ein einfaches shading drauflegen möchte. Wenn man sich mal ansieht, was eine CPU so packt, dann kommt man beim Lesen, Rechnen und Schreiben aufs RAM auf bestenfalls ein Drittel der effektiv verfügbaren Bandbreite als Nettowert für das, was maximal in die Karte gehen kann. Eine heutige CPU mit DDR4-RAM könnte bei den derzeitigen Modulen theoretisch weit über 400Gbps an maximaler Datenraten verarbeiten, tut es aber infolge interner Limits bei Weitem nicht. Wegen der Verwaltung und anderer Randbedigungen kommt man selbst bei linearen Zugriffen nicht auf mehr, als 20 GByte/s! und das auch nur im optimalen Fall. Beitrag "Re: Vergleich FPGA-DDR-Controller und PC-DDR-Controller" Mit einem DDR3-Controller an einem FPGA packt man so rund ein Zehntel - FPGAs umgehen aber den Flaschenhals, den die Busse im PC zum Speicher und zur Grafikarte darstellen. Packt man nämlich seine Daten in eine pipe mit voll ausgelasteten Block-RAMs, sieht das ganz anders aus. Mein einfacher VA-Synth benutzt allein in der pipeline z.B. 64BRAMs mit 32Bits, alle mit dualport read and write gleichzeitig. Das sind bei der benutzten Videofrequenz von 135MHz schon über 130 MByte/s. Hinzu kommen über 10.000 FFs und LUTs, die Filter und VCOs bilden und zusammen nochmal soviel Bandbreite erzeugen. Das ist bereits das 30-fache und der Chip kostet weniger, als eine Intel CPU! Eine derartige Rechenleistung ist allein schon von der Betrachtung her von einem PC nicht zu machen. Bei Weitem nicht. Ein vollausgelasteter Artix mit 297 MHz und komplett genutzten BRAMs sowie 40% seiner FlipFlops für parallele Rechnungen bringt es auf über 2000 GByte/s realer Bandbreite und es gibt nicht den Nachteil des Verlustes durch den random access beim DDRx. Um die gleiche Menge an Daten zu schauffeln, bräuchte man 100 CPUs mit angeflanschten DDR-Speichern!! Beim Rechnen in Grafikarten sieht es natürlich anders aus, weil diese echte parallele- und zum Rechnen optimierte Hardware haben. Allerdings muss auch dort Information durch einen Flaschenhals. Es kommt beim Grafikartenrechnen drauf an, dass die Karte möglichst 90% der Arbeit macht, also z.B. nur Parameter von z.B. Gleichungen und Voxel kriegt, die sie selber ausberechnet. Damit vervielfältigt sich der Informationsgehalt, der in die Karte hinfließt, um ein Vielfaches, bevor es ins Bild geht. Trotzdem sehe ich die FPGAs mit einem Faktor 10 vorn und eine Leiterplatte mit einem A7 kostet am Ende weniger, als eine gamer-Grafikkarte. Die Karte kann man halt kaufen und einfach programmieren.
. Eine CPU hat mehr SRAM (Cache) auf dem Chip als ein FPGA. Bei der GPU teils mit wahlweisen Zugriff. . Eine CPU läuft mit dem 10-fachen Takt und hat typischerweise 4-8 Kerne (Faktor 80). . CPU und GPU haben FPUs, der Artix nicht (ggf andere FPGAs). . An CPUs ist mehr Speicher anbindbar. An eine GPU ist mehr Speicher anbindbar. Beides ist bei vielen Applikationen relevant, zB 3D. . Bei genauen Berechnungen sind Rundungsfehler bereits auf der CPU mit 64 Bit FloatingPoint ein Thema und auf der Grafikkarte auch. . Eine CPU hat viele PCIe-Lanes des neuesten Standards. FPGAs liegen meist einen Standard dahinter und haben weniger PCIe-Lanes. Man muss sich bereits bemühen, um 20+x GBit an den FPGA anzubinden. Für die CPU kauft man im Handel. . Die GPU hat 16 PCIe Lanes . Die Kommunikation CPU<>GPU und GPU<>Hauptspeicher läuft über PCIe. . Dazu die typischen Nachteile: Mehr Entwicklungsaufand, weniger flexibel, schwieriger migrierbar. . Ein Artix sieht gegen eine GPU kein Land. Mit größeren FPGAs wird die FPGA-Lösung ganz schnell teurer. FPGAs haben andere Vorteile: . Echtzeit . Flexibilität an den IOs (zB 4x HDMI-in einfach so) . keine NDA bei typischer Nutzung . Mit Doku käuflich erwerbbar (GPUs sind es nicht) . Ohne Computer funktionsfähig (GPUs sind es nicht) . Kompakt, geringer Energiebedarf . Hohe Performance im Embedded-Segment . Temperatur grades . Toleranz gegenüber SEU und anderen realisierbar . Verfügbarkeit, Lebenszyklen der Bauteile Aus diesen Gründen werden FPGAs auch bei MIL und AERO verwendet. Mit der maximal erzielbaren Performance hat das typischerweise nichts zu tun.
:
Bearbeitet durch User
Nur das kein falscher Eindruck entsteht - ich kenne die Vorteile von FPGAs auch und muss da nicht überzeugt werden. Aber bei 3D-Grafikanwendungen sind GPUs klar im Vorteil da genau dafür gemacht. Wie Lars schön darstellt, haben FPGAs andere Vorteile und Einsatzgebiete. Lars R. schrieb: > Echtzeit Insbesondere ist eine sehr geringe Latenz erzielbar (bei GPUs kommen die Daten schlimmstenfalls erstmal aus dem CPU Hauptspeicher, gehen dann in den internen GDDRx Speicher und dann wieder zurück zur CPU - und das kann dauern egal wie breit der PCIe Bus ist. Beim FPGA ist sowas nicht immer nötig je nachdem was man macht (da kommen die flexiblen I/Os in Spiel). > Eine CPU läuft mit dem 10-fachen Takt und hat typischerweise > 4-8 Kerne (Faktor 80). Artix FPGAs gibts immerhin mit bis zu 740 DSP Slices die theoretisch mit max. 550 MHz takten können - mehrere davon kann man übrigens mit wenig Zusatzhardware auch für Floatingpoint mit anpassbarer Genauigkeit nutzen. Die kann man beliebig zu parallel arbeitenden Pipelines zusammenschalten. > Aus diesen Gründen werden FPGAs auch bei MIL und AERO verwendet. > In der Industrie natürlich auch (z.B. alles was mit Kameras zu tun hat ist ideal dafür). Jürgen S. schrieb: > Das alles ist also nicht "echt" > erzeugt, sondern nur "fast wie echt gemalt" - so wie eben ein Maler ein > Bild malt. Der TO schreibt was von einem Kunstprojekt ;-) Denke daher das "gemalt" da ausreicht?
Kontroller schrieb: >> Eine CPU läuft mit dem 10-fachen Takt und hat typischerweise >> 4-8 Kerne (Faktor 80). > > Artix FPGAs gibts immerhin mit bis zu 740 DSP Slices die theoretisch mit > max. 550 MHz takten können - mehrere davon kann man übrigens mit wenig > Zusatzhardware auch für Floatingpoint mit anpassbarer Genauigkeit > nutzen. > Die kann man beliebig zu parallel arbeitenden Pipelines > zusammenschalten. Es ist mühsam, mit nichts aussagenden Zahlen zu handieren. Eine einzelne Zelle auf der CPU kann vielleicht auch mit 10GHz takten. Wenn für physikalische Berechnungen hohe Genauigkeit erforderlich ist, die weiter oben den typischen GPU-Anwendungen in Abrede gestellt wurde, so ist die Frage, wieviele DP FPUs mit wie viel MHz und Durchsatz laufen. Wenn die Frage ist, wieviele 8-Bit-Fixedpoint-Operationen ausgeführt werden können, so liegt FPGA vorn, aber davon kann die CPU auch mehr als eine pro Takt.
Lars R. schrieb: > Es ist mühsam, mit nichts aussagenden Zahlen zu handieren. Das stimmt - bei CPUs und GPUs hat man das Problem allerdings auch. Die Recheneinheiten (SIMD ALUs/FPUs) werden da oft nicht 100% ausgelastet - einige liegen evtl. ganz brach weil sie sich je nach Anwendung nicht sinnvoll parallel mitnutzen lassen... kommt auf den Algorithmus an. Also die theoretischen Maximalwerte werden auch da selten erreicht.
Das kommt in beiden Fällen oben drauf. Typischerweise ist es jedoch für die CPU einfacher. Wenn es um DP-Performanz geht (so wie hier ursprünglich), so sind CPUs mit 8 Kernen mit DP FPUs @3.5GHz dennoch nicht mit 740 DSP slices @550MHz als Zahlenwerte vergleichbar, weil ein DSP slice für sich keine DP FP Funktionalität @550MHz realisiert. Eine solche Gegenüberstellung suggeriert Vorteile für den FPGA, wo tatsächlich eher Nachteile bestehen. Für den Kintex7 habe ich nun spontan nachgeschaut: http://www.xilinx.com/support/documentation/ip_documentation/ru/floating-point.html Bis zu 31kLUT und in einem anderen Fall bis zu 75DSP slices pro DP-Operation. Oder eben erheblich weniger bei reduzierter Funktionalität.
Die Diskussion über die Performance von CPU/GPU vs. FPGA oder DSP ist freilich müßig, solange der Themenersteller es nicht schafft klar darzustellen was er denn nun eigentlich braucht oder haben will.
Mark B. schrieb: > Die Diskussion über die Performance von CPU/GPU vs. FPGA oder DSP ist > freilich müßig, Ich sehe das als small talk und "kennen lernen" > solange der Themenersteller es nicht schafft klar > darzustellen was er denn nun eigentlich braucht oder haben will. Diesbezüglich möchte der TO, dass wir ihm das sagen. Vielleicht soll Gebärdensprache in Echtzeit in Full HD hineingerendert werden. Oder Augmented Reality...
Lars R. schrieb: > Diesbezüglich möchte der TO, dass wir ihm das sagen. Und ohne weitere Infos können wir das nicht. So einfach ist das. Ein paar Beispielbilder könnten sehr hilfreich sein. Grafik alleine mit Worten zu beschreiben ist schwierig.
:
Bearbeitet durch User
Lars R. schrieb: > Das kommt in beiden Fällen oben drauf. Typischerweise ist es jedoch für > die CPU einfacher. Nicht pauschal. Ein Multiplier oder Zähler im FPGA sind ein paar LUTs und FFs und eine einzige VHDL-Zeile. > Wenn es um DP-Performanz geht (so wie hier ursprünglich), so sind CPUs > mit 8 Kernen Ein Integrator im FPGA kann mit 300 MHz summieren. 100 Integratoren im FPGA können ebenfalls mit 300 MHz summieren. 100 Integratoren in der CPU laufen mit einem 1/100tel der 4 GHz. Merkst Du was? >Bei Floating-Point Das ist meistens nicht nötig, da man im FPGA ohne wesentlichen Performanceverlust beliebige Bitbreiten verwenden kann. Es ist auch bekannt, daß 48 Bit Integer genauer ist, als 32Bit Float und welche App benötigt schpn 64 Bit float? >740 DSP slices Laufen im FPGA mit durchschnittlich 200 MHz und führen 150G Operationen aus, holen und speichern ihre Werte voll parallel. Eine CPU kann auch mit 20 Kernen nicht soviel leisten und muss noch Werte holen und speichern. Bei geringeren Taktfrequenzen als 150MHz können die DSPs auch ohne resource sharing doppelt genutzt werden. Und: normale LUTs und RAMs können zum Rechnen herangezogen werden. In FPGAs kann man heute komplette Bilder ablegen und bearbeiten. >PCIe Der ist das Problem. Wieviele Daten gehen denn maximal über den PCIe-Bus? Dass einzelne Teilnehmer wie RAMs, GPU und auch CPU eine temporärere Spitzenleistung bringen, die um ein 100faches höher liegt, bringt nicht viel. Im FPGA kann jedes Element mehr oder weniger mit jedem anderen gleichzeitig reden, d.h. die Daten stehen beim nächsten Takt zur Verfügung. Beim PC müssen alle mehrdimensionallen Datenoperationen sequenziell ausgeführt werden. Ein Beispiel: Ein neuronales Netz aus 64 x 64 Knoten arbeitet auf 156.25MHz und alle Knoten haben im nächsten Takt alle Augänge aller Neuroelemente zur Verfügung. Das pipelining erfordert im Element beträgt 15 Takte. Das Netz arbeitet also mit einem loop von 10 MHz. In der CPU, mit der das Netz simuliert wurde, dauert das Berechnen eines Elementes fast 70 Takte. Das Berechnen aller 4096 Knoten dauerte mit 8 Kernen über 35000 Takte. Das Netz arbeitete also mit einer 100% ausgelasteten CPU mit optimiertem C-Code auf maximal 100kHz. Real war es mit MATLAB nicht mal 1kHz! Mit der GPU-Lösung des Diplomanden kam man immerhin auf 750kHz!
Weltbester FPGA-Pongo schrieb im Beitrag #4685027: > Lars R. schrieb: >> Wenn es um DP-Performanz geht (so wie hier ursprünglich), so sind CPUs >> mit 8 Kernen > Ein Integrator im FPGA kann mit 300 MHz summieren. > 100 Integratoren im FPGA können ebenfalls mit 300 MHz summieren. > 100 Integratoren in der CPU laufen mit einem 1/100tel der 4 GHz. > Merkst Du was? Ja. Dass Du meine Texte auseinander reist, um ihren Sinn zu entstellen. Das, was Du mir entgegnest, habe ich weiter oben selbst schon geschrieben. >>Bei Floating-Point > Das ist meistens nicht nötig, da man im FPGA ohne wesentlichen > Performanceverlust beliebige Bitbreiten verwenden kann. Es ist auch > bekannt, daß 48 Bit Integer genauer ist, als 32Bit Float und welche App > benötigt schpn 64 Bit float? Genaue physikalische Berechnungen Anwendungen, die auf einer GPU nicht genau genug laufen.
Martin K. schrieb: > Die Ego-Dinger sind rein 2D, als 2.5D gezeichnet. Bei Commander Keen, Castle Wolfenstein oder dem ersten DOOM stehengeblieben? > Ich habe komplexe 3D-Figuren zu berechnen, wie sie bei Filmen verwendet > werden. Das ging vor einem Vierteljahrhundert. In Echtzeit. Mit Realtime-Video-Stream. Auf 08/15 Hardware. Aber nur SD und nicht HD. Framegrabber schiebt den Video-Stream auf eine OpenGL-Textur, Grafikkarte macht den Rest, mit 3D-Berechnung, Z-Buffer usw. Das ging vor fast 10 Jahren auch mit HD-Auflösung und Video-Streams aus dem Netzwerk im Webbrowser (in VRML, wenn das noch jemanden was sagt) Wenn bei dir also nur 2 FPS rauskommen, dann machst du was grundlegend falsch. OpenGL in Software-Emulation? OpenGL rendert in Buffer, und du kopierst den Buffer per "for (x=0; x<1980; x++) for (y=0; ...) ... " auf den Videostream? > Ich habe ja vorgerechnet, wieviele Operationen es sind. 500000 gefüllte Pixel? Aktuelle High-End-Grafikkarten machen da mal nebenbei 250000000000 Texel pro Sekunde. Deine Anforderung ist geradezu lachhaft wenig.
Bla Bla bla... Könnt ihr mit dem Fpga vs Cpu vs Gpu wo anders spielen? Anscheinend gibt es nichts ökonomisch sinnvolles für den TO. Vielleicht mag er sich trotzdem noch mit einem beispielbild o.ä. melden. Mich interessiert was er vorhat. Vielleicht kann ihm dann sogar geholfen werden.
Deinen Text wollte ich nicht entstellen. Du hast aber in dem besagten Paragraphen mit dem Tenor abgeschlossen, dass die CPUs den FPGAs tendeniell überlegen seinen, und wörtlich gesagt: > Eine solche Gegenüberstellung suggeriert Vorteile für den FPGA, wo > tatsächlich eher Nachteile bestehen. Dem muss ich klar widersprechen. Bei der FPU kann man zustimmen, aber auch da besteht das Problem, dass die CPU eine Einzeloperation schneller ausführt, infolge der Bandbreitenthematik aber bei parallelen Anwendungen dem FPGA schnell unterliegt. Genau da ist auch ein Vorteil bei physikalischer Simulation. Man kann die Auflösug an die Aufgabe anpassen, um FPGA-Fläche zu sparen und Auflösung dort zu gewinnen, wo sie nötigt ist.
karl schrieb: > Könnt ihr mit dem Fpga vs Cpu vs Gpu wo anders spielen? Es geht darum, dem TE vorzeuhalten, was in einer CPU geht und was er in Software machen kann. bzw, was er davon in Hardware machen (lassen) muss. Ich halte das durchaus für themenbezogen. Dass er das Mischen mit der Grafikarte machen kann, sollte inzwischen klar sein. Die Frage ist wie er das Bild erzeugt.
Weltbester FPGA-Pongo schrieb im Beitrag #4685104: > Ich halte das durchaus für themenbezogen. Ich nicht, weil einfach nur stumpfes allgemeines Gefasel der Kategorie "Flamewar".Keiner von euch weiß was der TO genau vorhat. Er wird sich wahrscheinlich auch keinen FPGA zur Brust nehmen, weil das hätte er zum Mischen der Videos schon lange machen können. Wenn sich zwei eigentlich nicht am Thema beteiligte Leute 80% des Threads schnappen und dabei noch nicht mal konkret zur Lösung beitragen ist das mMn ein bißchen daneben. Mit dem original Thema "hdmi Mischer" hat eure Diskussion nun wirklich nichts zu tun und auch das Unterthema "die gpu bekommt es nicht gebacken" bringt ihr kein Stück voran. Dazu müsste der to Vielleicht auch noch mehr Infos preisgeben. was habe ich hier beizutragen? Bis jetzt auch wenig. Mich interessiert aber was das werden soll und habe konkret nach einem Beispiel gefragt (das existieren sollte weil es mit 2 fps gerendert werden kann). Euch beiden scheint es nur um die Rechthaberei zu gehen.
@karl (Gast): Der TO wird zu seinem geheimen Projekt allenfalls erst dann weitere wesentliche Informationen geben, wenn er sich ganz sicher ist, dass er es selbst in absehbarer Zeit nicht zur Verfügung stellen und verwerten kann. Dieser Tanz dauert hier nunmehr schon 14 Tage, beginnend bei Video-Mischen, über die Mannheimer Freundin, die Kunst studiert, über 3D, oder nicht 3D, usw. Vorgeführt vom freiberuflich tägigen Softwareentwickler, bei dem Du, Karl, davon ausgehst, er wäre bisher nur unbeabsichtigt zu ungeschickt, endlich mal zu spezifizieren, was er benötigt. ..."irgendjemand" hat halt von FPGA angefangen. Da dachte ich, was solls...
Kontroller schrieb: > Insbesondere ist eine sehr geringe Latenz erzielbar (bei GPUs kommen die > Daten schlimmstenfalls erstmal aus dem CPU Hauptspeicher, gehen dann in > den internen GDDRx Speicher und dann wieder zurück zur CPU - und das > kann dauern egal wie breit der PCIe Bus ist. So ist es. Bei den Spielen läuft alles im Bereich der menschlichen Reaktionszeit ab und die Konterreaktion des Systems wird kaum als Verzögerung wahrgenommen, so lange sie sich im Rahmen hält. Da sind mehrere video frames Verzögerug akzeptabel. Intuitive Dinge im Spiel wie der Wind, Wasserbewegung, Aktivität von Figuren sind überhaupt nicht zeitlich einzuordnen. Bei Echtzeitanwendungen ist das was anderes. >> Aus diesen Gründen werden FPGAs auch bei MIL und AERO verwendet. Hier ist ein link auf einen FPGA-basierten Echtzeitrender: https://www.youtube.com/watch?v=3yH8OQTkpy8 Auf den ersten Blick vermag mancher sicher nicht zu sagen, wo genau der schneller und besser ist, zumal die Grafik eher aussieht, wie aus den 90ern, aber die werden sich auch überlegt haben, was sie da machen und ob ihnen nicht eine Grafikkartenlösung reicht. Offenbar tut es das nicht. > Der TO schreibt was von einem Kunstprojekt ;-) > Denke daher das "gemalt" da ausreicht? Könnte sein. Kommt auf die Art der Kunst an. Ich würde auch gerne mal wissen, was das genau gemacht werden soll.
Weltbester FPGA-Pongo schrieb im Beitrag #4685027: > Mit der GPU-Lösung des Diplomanden kam man immerhin auf 750kHz! Damit wäre der FPGA aber immer noch mehr, als 10mal schneller, als die Grafikkarte und das, obwohl solche Berechnungen absolut ideal sind für Grafikkarten (solange man alle Rechnungen gleichzeitig reinbekommt). Ich bringe nochmal ein Beispiel für eine typische Videoanwendung, um wieder zum Thema zu kommen: Nehmen wir eine Teilbildskalierung um einen beliebigen Faktor. Da braucht es für Zomm In und Out zwei 2D-Bildfilter und einen ausreichend großen Bildspeicher, der mehrere Zeilen halten kann und voll bidirektional ausgelesen werden kann. Beide kann man bei ausreichend hoher Taktfrequenz multiplexen und kaskadieren, um in mehreren Stufen auch große Bilder verarbeiten zu können und dies auch in Mehrfarb-Modellen und mit höherer Auflösung als 8 bit je Farbe. Für einen Filter allein müssen aber mindestens 25, besser 49 Multiplikationen und 100 bzw 200 Datenverschiebeoperationen je Bildpunkt durchgeführt werden. Beim Skalieren sind es 2x4 bzw, 2x9 Multiplikationen und Addition je Bildpunkt. Da kommen bis zu 500 Elementar-Aktionen je Bildpunkt zusammen. Gerade die RAM-Zugriffe sind dabei das Problem, weil die in Richtung eines externen Speichers sequenziell laufen, während beim BRAM auf einem Port Daten geschrieben werden können, während auf zwei anderen Ports Daten fürs die Zeilenskalieroperationen gewonnen werden können. Das Ganze lässt sich so aufbauen, dass es komplett als pipeline läuft, daher ist das Bild fertig, wenn das Quellbild durch ist. Man verliert also keinen frame. Lars R. schrieb: > ..."irgendjemand" hat halt von FPGA angefangen. Da dachte ich, was > solls... Es ging um den gelinkten Videomischer, den es käuflich zu erwerben gibt. Üblicherweise sind da FPGAs verbaut - zumindest, um die IO-Chips zu treiben. Sicher sitzen da aber auch Chips drin, die Skalieren und PIP oder Bilddrehung können. Es ging weiter um eine frei programmierbare Plattform. Richtig "frei programmierbar" sind auf dem Sektor nur FPGAs, weil die Grafikarten, bzw die in CPUs integrierten Grafikeinheiten fest vorgefertigte Funktionen haben. Die scheinen aber dem TO nicht zu reichen, oder sie sind nicht hinreichend bekannt. Ich hatte auch schon in meinem ersten Beitrag darauf hingewiesen, dass nach meinem Gefühl eine Grafikkarte mit entsprechendem framework reichen dürfte. Zumindest für das, was man als Heimlösung braucht und finanzieren kann.
Planlos schrieb: > Das ging vor einem Vierteljahrhundert. In Echtzeit. Mit > Realtime-Video-Stream. Auf 08/15 Hardware. Komisch, dann frage ich mich, warum es Animationsstudios mit vollgestopften Räumen gibt, in denen mehrere Unix-Render-Plattformen tagelang gleichzeitig arbeiten, um ein paar wenige Minuten 3D-Animation fürs Kino hinzubekommen, wenn das doch jede Grafikarte kann ? > Framegrabber schiebt den Video-Stream auf eine OpenGL-Textur, > Grafikkarte macht den Rest, mit 3D-Berechnung, Z-Buffer usw. Und wer erzeugt den Videostream? Darum geht es. Was der Nutzer mit dem fertigen Video macht, ist seine Sache. Er kann es an die Wand werfen und in den Weltraum schicken. > 500000 gefüllte Pixel? 500.000 individuell in der Farbe gemäss Formeln berechnete Pixel und das für jedes Bild. Sind 32Bit Farbe x 0,5MPixel x 60Hz = 120 MByte/s. Angeblich gehen die nicht mal durch den DDR-Speichercontroller. Wie also soll man sie in Echtzeit berechnen? > Aktuelle High-End-Grafikkarten machen da mal nebenbei > 250000000000 Texel pro Sekunde Ja, in der Grafikkarte, wenn die Rohdaten drin sind.
Angehängte Dateien:
-
mk_stereotest_render3.jpg
340 KB
Lars R. schrieb: > Diesbezüglich möchte der TO, dass wir ihm das sagen. Ich habe lediglich nach der Verfügbarkeit solcher Plattformen gefragt, die schneller sind, als die existierenden Komponenten PC und GraKa. > Vielleicht soll Gebärdensprache in Echtzeit in Full HD hineingerendert > werden. Oder Augmented Reality... Es gibt in der Tat ein Projekt, wo so etwas Ähnliches angedacht ist. Das wäre aber nur ein Seitenprojekte des meinigen. >3D oder nicht 3D Die 3D-Tiefeneffekte stecken in der entwickelten Software. Die Bilder werden so gezeichnet, dass die gewünschten Tiefeneffekte entstehen, d.h. die Software zeichnet die Figuren in 2 Ansichten.
Martin K. schrieb: > Ja, in der Grafikkarte, wenn die Rohdaten drin sind. Dann verrate uns doch mal, wo Deine Rohdaten herkommen. Fallen die plötzlich vom Himmel und müssen aufgefangen werden? :-) Wir erinnern uns: Dir ging es ja darum, Martin K. schrieb: > kleine Figuren einzublenden, die man selber programmieren kann Also ist das grundsätzliche Aussehen dieser Figuren vorher festgelegt. Ich wüsste nicht was dagegen spricht, diese bei der Entwicklung entsprechend zu modellieren und sie dann zur Laufzeit von der Grafikkarte berechnen und anzeigen zu lassen. Wie ich sehe hast Du ein Beispielbild gepostet. Was ist jetzt der genaue Zusammenhang von diesem Bild mit Deinen Anforderungen? Das Beispiel erinnert mich an alte Raytracing-Bilder. Deine Themeneröffnung klingt nach was anderem.
:
Bearbeitet durch User
Martin K. schrieb: > Lars R. schrieb: >> Diesbezüglich möchte der TO, dass wir ihm das sagen. > Ich habe lediglich nach der Verfügbarkeit solcher Plattformen gefragt, > die schneller sind, als die existierenden Komponenten PC und GraKa. FPGA kann das. >>3D oder nicht 3D > Die 3D-Tiefeneffekte stecken in der entwickelten Software. Die Bilder > werden so gezeichnet, dass die gewünschten Tiefeneffekte entstehen, d.h. > die Software zeichnet die Figuren in 2 Ansichten. So? http://www.despectus.co.uk/images/easyblog_articles/40/002-001-000123.jpg http://www.despectus.co.uk/index.php/blog/dev-journal-3-the-adv7513-hdmi-transmitter-system-design
Martin K. schrieb: > Komisch, dann frage ich mich, warum es Animationsstudios mit > vollgestopften Räumen gibt, in denen mehrere Unix-Render-Plattformen > tagelang gleichzeitig arbeiten, um ein paar wenige Minuten 3D-Animation > fürs Kino hinzubekommen, wenn das doch jede Grafikarte kann ? Überleg dir, was diese Rechner-Farmen machen, und warum das überhaupt garnix mit deiner kommunizierten Anforderung zu tun hat. Wenn du natürlich meinst, ein "Videomischer" muss auch einen Echtzeit-Raytracer enthalten, Kaffee kochen & Wäsche bügeln können, und nebenbei auch noch die Lottozahlen der nächsten Woche vorhersehen können, dann solltest du vielleicht mit einem anderen Arbeitstitel neu anfangen.
Martin K. schrieb: >> Framegrabber schiebt den Video-Stream auf eine OpenGL-Textur, >> Grafikkarte macht den Rest, mit 3D-Berechnung, Z-Buffer usw. > Und wer erzeugt den Videostream? Darum geht es. Was der Nutzer mit dem > fertigen Video macht, ist seine Sache. Er kann es an die Wand werfen und > in den Weltraum schicken. Das war damals eine BT848 - Framegrabber-Karte, die hat den analogen Videostream digitalisiert und per Busmaster-DMA in die Grafikkarte geschoben. CPU hat sich derweilen gelangweilt. Die Grafikkarte konnte ohne auch nur ins Schwitzen zu kommen diese Video-Textur beliebig verwerten, z.B. auf eine virtuelle Leinwand packen, 3D-Figuren davor und dahinter platzieren, das Video beliebig verzerren (Textur auf Kugel oder flatternde Fahne mappen) usw. Genau das war doch deine Anforderung: Videostream nehmen, 3D-Objekte davor platzieren? Martin K. schrieb: > HD-Video (full HD!) zu mischen und darin > kleine Figuren einzublenden Heute sind die Rechner um Größenordnungen leistungsfähiger, d.H. heute geht das mit Full-HD/HDMI statt Analog-PAL, höher aufgelösten Texturen, mehr Polygonen, Bump-Mapping, usw. Aber das Grundprinzip bleibt dasselbe.
Planlos schrieb: > Wenn du natürlich meinst, ein "Videomischer" muss auch einen > Echtzeit-Raytracer enthalten Hm, bei Echtzeit-Raytracing ergeben die hier berichteten 2 Frames pro Sekunde dann vielleicht doch einen Sinn ;-)
Mark B. schrieb: > Hm, bei Echtzeit-Raytracing ergeben die hier berichteten 2 Frames pro > Sekunde dann vielleicht doch einen Sinn ;-) Bei "neusten" Grakarten nur bei extrem komplexen Szenen. Raytracer gibt's schon genug, und die schaffen locker zig FPS, z.B. bei obiger Szene. Nur als Beispiel: Ich habe einen Voxelshader mit 512^3 Voxel, der bei 1024^2er Auflösung >= 25 FPS schaft (Raycasting, nicht Tracing!). Je Pixel wird nicht nur der "Hit" bestimmt, sondern über einen 2. Trace auch der Schatten. Das macht je Pixel >= 1000 Shaderops. Getrennt davon kann in einem weiteren Shader eine 3D-Fluidsim (Navier-Stokes) mit 128^3 in ein 3D-Volumentexture gerendert werden. Dann läuft's noch immer mit >= 10fps. Nehme ich jetzt statt meiner 8800GTX eine neue, dann komme ich sicherlich auf >= 50 FPS, auch bei 256^3er Fluidsim. Also von daher: Mit HDMI-Framegrabber per DMA in Graka übertragen (500MB/s, ein Witz für PCIe) und dann wie auch immer per Shaderskript filtern und ausgeben, ohne Probleme auch in 10 Perspektiven. GraKa+Framegrabber gibt's für <1000 Euro, und die schaffen selbst zig Millionen von Linien/Dreiecke in > 60 FPS.
Mark B. schrieb: > Hm, bei Echtzeit-Raytracing ergeben die hier berichteten 2 Frames pro > Sekunde dann vielleicht doch einen Sinn ;-) Ich denke auch, daß die Anwendung im hiesigen Fall eher einer Raytracing-Thematik entspricht, zumindest spricht das Beispielbildchen dafür. Sigi schrieb: > Bei "neusten" Grakarten nur bei extrem komplexen > Szenen. Raytracer gibt's schon genug, und die > schaffen locker zig FPS, z.B. bei obiger Szene. Naja, solche Animationen sind beliebig kompliziert: Das gepostete Bild mit den transparanten Linsen ist so ein verdächtiges Beispiel, bei dem je Objekt mal schnell hunderte Strahlen erzeugt werden können, was die Aufgaben rasch zu Millionen an Tasks vervielfältigt und über alle Grenzen wachsen lässt. Hinzu kommen Vervielfältigungen wegen anti aliasing sowie Kamerafokus- und Bewegungsunschärfe. Wenn man an den Parametern ein bischen was ändert, landet man schnell beim n-fachen des Zeitbedarfes. Wie schnell das dann real läuft, hängt sicher von der Grafikkarte ab, d.h. je größer deren Speicher und Rechenleistung, desto mehr geht noch in akzeptabeln Zeiten. Aber die Reserven sind da nicht unerschöpflich: Ich hatte mal eine meiner Animationen auf einer 3D-Workstation eines Lieferanten rechnen lassen, um zu schauen, was mein 12-Kerner mit GeForce Grafikkarte so kann und in der Tat ging das da so rund 5mal schneller. Die ist dafür gedacht, V-Raytracing direkt mit 3DS-Max Modellen zu machen und hatte eine professionelle NVIDIA Karte (Einzelreis über €5000,-!) drin. Allerdings war auch das immer noch weit weg von Echtzeit, ein Bild dauerte halt 2Sek, statt über 10 bei mir :-) Das war aber noch eine überschaubare Animation und für Bewegung gedacht. Sobald aber richtig was los ist, im Bild, mit vielen Details, hoher Auflösung und dem Anspruch auf Fotorealität ist sehr schnell Ende mit Echtzeit. Das Modell meines Synthies braucht allein 7-8min für ein Bild! Keine Ahnung, was es da für eine Monsterkarte braucht, damit das irgendwann mal in Echtzeit geht. Angeblich verdoppelt sich ja die Leistung der CPUs und GPUs alle paar Jahre. Als Beispiel nehme ich mal diese Oberfläche für den Microwave: http://www.96khz.org/doc/vasynthesismicrowavext.htm Die lief auf dem alten XP-Rechner, mit dem sie gebaut wurde, aus der Erinnerung über 1 Minute. Der aktuelle Rechner packt es unter 10! Wäre ein Faktor 8 in 8 Jahren.
Lars R. schrieb: > Martin K. schrieb: >> Ich habe lediglich nach der Verfügbarkeit solcher Plattformen gefragt, >> die schneller sind, als die existierenden Komponenten PC und GraKa. > FPGA kann das. Jo, FPGA kann alles. Oder sagen wir mal so, es gibt ganz bestimmte Dinge, die im FPGA einfacher, andere die schneller und manche die nur damit gehen. Alles, was aber in der Grafikkarte geht, sollte man auch dort machen. >> Die Bilder werden so gezeichnet, dass die gewünschten Tiefeneffekte >> entstehen, d.h. die Software zeichnet die Figuren in 2 Ansichten. > So? Das sind aber jetzt 2 verschiedene Themen: Tiefeneffekte bestehen aus Größen- und Winkeleffekten sowie Schattierungen und Beleuchtung. Das ist zunächst einmal noch 2D. In dem gelinkten Beispiel "hdmi-transmitter-system-design" handelt es sich um Stereobilder, praktisch ist es ein einziges HD-Bild, in das die Bilder L+R mit der halben X-Auflösung erscheinen. Richtig ist, dass dafür zwei Ansichten generiert werden müssen, in denen die Objekte entsprechend ihrer 3D-Position erscheinen müssen, sofern die Karte das nicht kann, bez der Renderer das nicht automatisiert tut, (WAS diese Programme im Übrigen können !). Beim "3D-Video" ist aber der Zeichenbereich nicht größer, d.h. aus diesem Grund würde auch noch kein erhöhte Rechenbedarf entstehen, es sein denn, es gäbe 2 Quellen, die gemischt werden. Bei manchen RT-Rendersystemen existieren z.B. 2 Karten, die dasselbe Modell aus 2 Winkeln rechnen und ein Mischer erzeugt daraus das Stereobild. Diese Funktionen kann man mit einem FPGA vereinen und sich bei Stereo die unnötige Berechnung der 50% nichtbenötigten Information sparen. Dann landet man hier: Beitrag "Re: 3D-Kamera VHDL Simulationsmodel"
Jürgen S. schrieb: > Mark B. schrieb: >> Hm, bei Echtzeit-Raytracing ergeben die hier berichteten 2 Frames pro >> Sekunde dann vielleicht doch einen Sinn ;-) > Ich denke auch, daß die Anwendung im hiesigen Fall eher einer > Raytracing-Thematik entspricht, zumindest spricht das Beispielbildchen > dafür. Andererseits hat der Themenersteller weder in der Eröffnung noch danach jemals explizit gesagt, dass Raytracing betrieben werden soll.
Ein bischen Strahlverfolgung muss aber dabei sein, in den Kugeln sind ja Spiegelbilder des Untergrundes zu sehen und das erfordert munteres Rechnen mit Winkelfunktionen. Habe gerade mal gegoogelt: Die fetteste Karte, die ich habe finden können, kommt schon nackt auf >10.000k, leistet aber CUDA-mässig und vom RAM her gerade das doppelte einer Karte zu 1500,-. Eigentlich müsste es doch möglich ein, 4 Karten der 1500er Truppe zusammenzufassen und mehrere Bilder parallel machen zu lassen? Jede 15fps? Im schlimmsten Fall braucht man 4 PCs :-)
Jürgen S. schrieb: >>> Die Bilder werden so gezeichnet, dass die gewünschten Tiefeneffekte >>> entstehen, d.h. die Software zeichnet die Figuren in 2 Ansichten. >> So? > > In dem gelinkten Beispiel "hdmi-transmitter-system-design" handelt es > sich um Stereobilder, praktisch ist es ein einziges HD-Bild, in das die > Bilder L+R mit der halben X-Auflösung erscheinen. 1. Im Beispielbild des TO ist es auch die halbe Auflösung. 2. Man muss es ja nicht mit der "halben" Auflösung machen. > [Dein Design] Dann landet man hier: > > Beitrag "Re: 3D-Kamera VHDL Simulationsmodel" Der TO sucht eine Plattform, genauso wie Du auch im anderen Thread. Ich suche einen gemeinsamen Nenner. ADV7513?
Lars R. schrieb: > 1. Im Beispielbild des TO ist es auch die halbe Auflösung. So ist es. Ich war mir nur nicht sicher, ob der TE verstanden hat, dass dieses "Stereomalen" nicht mehr DSP-Power oder Grafikkartenpower benötigt. Im Gegenteil: Im FPGA lässt sich sowas (fast) ohne Mehraufwand emulieren und zwar absolut in Echtzeit. > 2. Man muss es ja nicht mit der "halben" Auflösung machen. Man muss es dann, wenn man einem 3D-Moni selbiges Bild über ein Kabel zuführen will. Das Beispiel, dass Du gelinkt hast, tut das. Wenngleich anscheinend mit "nur" 1080p30, wie mir scheint. Die 74 MHz sehen mir etwas verdächtig aus. In jedem Fall wandelt diese konkrete Schaltung auch nur ein progressives Bild in ein side bx side Format, damit die 3D-Brille es verarbeiten kann, die ein Stereobild erwartet. Das vor allem kann man auch anders lösen. > Der TO sucht eine Plattform, genauso wie Du auch im anderen Thread. Ich > suche einen gemeinsamen Nenner. ADV7513? Mir ist noch nicht klar, wo in dem Chip die Lösung für das Kunstmalen liegen soll. Der Chip tut auch kaum anderes, als parallele Videodaten auf (serielles) HDMI zu wandeln. Auf eine Videoplattform muss sowas drauf, keine Frage. Mich würde aber dennoch nochmals der Einwurf von weiter oben interessieren, was die Darstellung von Gebärdensprache angeht, die vermutet wurde. Woher weiß der Rechner, was er darstellen soll? Sprachanalyse?
Jürgen S. schrieb: > Lars R. schrieb: >> Der TO sucht eine Plattform, genauso wie Du auch im anderen Thread. Ich >> suche einen gemeinsamen Nenner. ADV7513? > Mir ist noch nicht klar, wo in dem Chip die Lösung für das Kunstmalen > liegen soll. Der Chip tut auch kaum anderes, als parallele Videodaten > auf (serielles) HDMI zu wandeln. Auf eine Videoplattform muss soetwas > drauf, keine Frage. Ja, der ADV7513 ist für die Ausgabe. Allein dessen Inbetriebnahme ist bereits ein kleines Projekt. Es gibt genügend Ideen dafür, was man graphisch ausgeben könnte, ebenso HDL-Designs dafür. Häufig fehlt jedoch die passende HW mit genau dem richtigen Preis/Leistungs-Verhältnis. Die eine universelle, FPGA-basierte Videoplattform gibt es nicht. Person1 benögigt 1xHDMI-In und 1xHDMI-Out. Person2 benötigt 2xHDMI-Out. Dem dritten ist das schon zu teuer oder er benötigt die Pins für anderes und der vierte benötigt einen anderen FPGA. Deshalb kommen bereits im Forum keine 3 Personen zusammen und es lohnt sich für keine Firma, eine solche Vielfalt zu entwickeln und vorzuhalten. Häufig lohnt es sich auch nicht, nur für eine Idee mit unbekanntem Ausgang oder für Hobby-Projekt ein komplexes Board zu bauen. Und dort, wo aufgrund von kommerziellem Interesse der Aufwand getrieben wird, wandern die PCB-Designs in die Schublade oder/und sind auf den letzten 1/10 Cent ausoptimiert und deshalb für geringe Stückzahlen "unhandlich" und "unschön". Dabei bietet sich beispielsweise für den ADV513 eigentlich ein modularer Ansatz an: Nach der Konfiguration ist die parallele Datenausgabe vom FPGA an den ADV7513 FPGA-unabhängig relativ trivial. Angenommen, Dein Design würde genau den Bedarf des TO decken. Das nützt gar nichts, weil Du laut eigener Aussage an anderer Stelle gar keine passende, preislich akzeptable HW dafür hast. Ja, man müsste/könnte ein PCB bauen und in Betrieb nehmen, wenn man nur wöllte. Nur lohnt es sich dann meistens doch nicht und daher will man nicht. Auch wenn die den Bedarf deckende Grafikkarte und Framegrabber-Karte heute noch teuer ist, morgen ist sie billig. Geht es nur um wenige Exemplare, so lohnt sich die Entwicklung eines individuellen PCB ohnehin kaum. > Mich würde aber dennoch nochmals der Einwurf von weiter oben > interessieren, was die Darstellung von Gebärdensprache angeht, die > vermutet wurde. Woher weiß der Rechner, was er darstellen soll? > Sprachanalyse? So, wie man es eben implementieren möchte/kann.
Mark B. schrieb: > Martin K. schrieb: >> Ja, in der Grafikkarte, wenn die Rohdaten drin sind. > > Dann verrate uns doch mal, wo Deine Rohdaten herkommen. Fallen die > plötzlich vom Himmel und müssen aufgefangen werden? :-) Eine Grafikkarte erhält entweder konkrete Punte und Pixelfarben oder sie bekommt abstrakte Kommandos zum Ausfüllen von 3D-dimensionalen Strukturen. Diese Rohdaten konnen viel weniger sein, als die Nettopunkte, aber: Dazu müsste man sie erst erzeugen. Meine Software liefert aber die Punktefarben als Endergebnis und daher muss ich an der Stelle schneller werden. In eine Grafikarte komme ich da schon rein, keine Sorge. Eine Möglichkeit, die Grafikkarte das alles berechnen zu lassen, inklusive finalizing sehe ich nicht. Auch andere OGL-Entwickler sahen das nicht! > Martin K. schrieb: >> kleine Figuren einzublenden, die man selber programmieren kann > > Also ist das grundsätzliche Aussehen dieser Figuren vorher festgelegt. Nein, eben nicht. Die Figuren ändern sich ständig. > Ich wüsste nicht was dagegen spricht, diese bei der Entwicklung > entsprechend zu modellieren und sie dann zur Laufzeit von der > Grafikkarte berechnen und anzeigen zu lassen. Weil das bei dieser Anwendung eben nicht geht. Die Lage der Punkte muss zunächst aus Formeln berechnet werden und dies erfordert mehrere Iterationen. Da entsteht der Rechenzeitbedarf. Allenfalls könnte man eine weitere Grafikkarte benutzen, um Berechnungen in Software dorthin auszulagern. Aber das scheitert dann an anderen Nebenbedingungen die hier auch von einigen Teilnehmern schon ins Feld geführt wurden. Ich müsste komplette Bilder oder Teilbilder hin und her schieben und das in Echtzeit. > Wie ich sehe hast Du ein Beispielbild gepostet. Was ist jetzt der genaue > Zusammenhang von diesem Bild mit Deinen Anforderungen? Es ging umd das Thema 3D-Darstellung. Das Bild ist ein Beispiel und ein einfacher Versuch mit einfachen Objekten. Die Zielbilder haben andere Inhalte, die ich hier nicht darstellen möchte.
Jürgen S. schrieb: > Lars R. schrieb: >> 1. Im Beispielbild des TO ist es auch die halbe Auflösung. > So ist es. Ich war mir nur nicht sicher, ob der TE verstanden hat, dass > dieses "Stereomalen" nicht mehr DSP-Power oder Grafikkartenpower > benötigt. Ich habe das schon verstanden, kein Problem. Meine Software ist skalierbar und rechnet jede Auflösung. Die Bezugnahme auf HD ist willkürlich. 1920x1080 ist aber das am Weitesten verbreitete. >> 2. Man muss es ja nicht mit der "halben" Auflösung machen. > In jedem Fall wandelt diese konkrete Schaltung > auch nur ein progressives Bild in ein side bx side Format, damit die > 3D-Brille es verarbeiten kann, die ein Stereobild erwartet. Das vor > allem kann man auch anders lösen. Die Situation ist mir schon klar. Halbes Bild, halbe Berechnungsanzahl. Mit einer 3D-Brille habe ich noch nicht gearbeitet, das wäre aber interessant. Allerdings benötigen wir für das Thema der Kunstinstallation eine Lösung für alle Betrachter und ich glaube nicht, dass wir hunderte von 3D-Brillen ausgeben können. Dafür sind Stereomonitore an den Säulen vorgesenen. >> Der TO sucht eine Plattform, genauso wie Du auch im anderen Thread. Ich >> suche einen gemeinsamen Nenner. ADV7513? > Mir ist noch nicht klar, wo in dem Chip die Lösung für das Kunstmalen > liegen soll. Eine spezialle Hardware kommt nur in Betracht, wenn sie käuflich zu erwerben ist. Ein Bastelprojekt kommt nicht in Frage. Man muss das System nachkaufen können. Ein Museum soll sich die Geräte hinstellen können und die Künstler müssen ihre Software drauf laufen lassen können. Momentan gibt es dazu nur die handelsüblichen PC-Plattformen mit Grafiken. Das sind die Leute eigentlich satt. > Mich würde aber dennoch nochmals der Einwurf von weiter oben > interessieren, was die Darstellung von Gebärdensprache angeht, die > vermutet wurde. Woher weiß der Rechner, was er darstellen soll? > Sprachanalyse? Das fragst du am Besten den, der das Thema aufgeworfen hat. Ich klinke mich hier jetzt mal aus, zumal das Thema ja von zumindest einer Person als nicht lesenswert gewertet wurde. :-)
Martin K. schrieb: > einer Person als nicht lesenswert gewertet wurde. :-) Das passiert in fast jedem Thread hier und ist normal. Kann übrigens auch sein, dass es 100 Leute mit +1 und 101 mit -1 bewertet haben, das weiss man nicht ;-) Ich fand den Thread sehr lesenswert. > Eine spezialle Hardware kommt nur in Betracht, > wenn sie käuflich zu erwerben ist. Auch eine spezielle Hardware müsste man "kaufen" / fertigen lassen. Die Komplexität hier wäre weit von "bastelei" entfernt - auch kostentechnisch ;-)
Martin K. schrieb: >> Wie ich sehe hast Du ein Beispielbild gepostet. Was ist jetzt der genaue >> Zusammenhang von diesem Bild mit Deinen Anforderungen? > Es ging umd das Thema 3D-Darstellung. Das Bild ist ein Beispiel und ein > einfacher Versuch mit einfachen Objekten. Die Zielbilder haben andere > Inhalte, die ich hier nicht darstellen möchte. Lieber Martin, sieh es mal so: Du willst hier Hilfe von uns. Damit diese zustande kommen kann, brauchen die anderen Menschen nun mal gewisse Informationen von Dir. Wenn Du diese nicht geben willst - nun gut, dann eben nicht. Aber dann wundere Dich nicht, wenn Dir nicht vernünftig geholfen werden kann. "Quid pro quo", das wussten schon die alten Römer. Kannst Dich gerne mal an denen orientieren.
Martin K. schrieb: > Weil das bei dieser Anwendung eben nicht geht. Die Lage der Punkte muss > zunächst aus Formeln berechnet werden und dies erfordert mehrere > Iterationen. Da entsteht der Rechenzeitbedarf. Allenfalls könnte man > eine weitere Grafikkarte benutzen, um Berechnungen in Software dorthin > auszulagern. Wenn es sich um die Modellierung von Physik handeln sollte, dann geht das auch in derselben Grafikkarte. Sieh Dir mal PhysX an. > Ich müsste komplette Bilder oder Teilbilder hin und her schieben und > das in Echtzeit. Angesichts der Speicherbandbreite von Grafikkarten wüsste ich nichts Käufliches, was schneller Bilder verschieben kann. Solange die Bilder in die Grafikkarte passen, ist das das Schnellste. Wenn Du die Bilder alle punktweise erzeugen willst und die Grafikkarten nicht ausreichen, brauchts Du ein skalierbares System in Hardware, wie es in professionellen Simulationssystemen wie bei beim Wetter oder bei der Echtzeitverarbeitung von Bilddaten wie bei Lidar oder Radar eingesetzt wird. Das dürfte aber den Kostenrahmen sprengen :-)
Kontroller schrieb: > Auch eine spezielle Hardware müsste man "kaufen" / fertigen lassen. Die > Komplexität hier wäre weit von "bastelei" entfernt - auch > kostentechnisch ;-) Daher ja die Frage, ob es was gibt. Hätte ja sein können. Ich habe jetzt Kontakt zu jemandem, der Ähnliches macht und ich werde mir da mal was ansehen. Mal schauen. Er ist übrigens auch der Ansicht, dass die gewünschten Effekte nicht mit Grafikkarten allein zu machen sein werden.
:
Bearbeitet durch User
Martin K. schrieb: > Er ist übrigens auch der Ansicht, dass die gewünschten Effekte nicht mit > Grafikkarten allein zu machen sein werden. Welche auch immer das sein mögen. :-/
:
Bearbeitet durch User
Martin K. schrieb: > Die Lage der Punkte muss > zunächst aus Formeln berechnet werden und dies erfordert mehrere > Iterationen. AHA! Da liegt der Hase im Pfeffer! Lässt sich das irgendwie beziffern? Wenn es sich um eine statische Anzahl von Iterationen handelt oder die Unterschiede in den Tiefen gering sind, kann man dies einfrieren und in eine pipe wandeln. Dann wäre es nur eine Frage der Platzbedarfes.
Georg A. schrieb: > CasparCG hat ein schönes > Steuer-Interface via Telnet Das taugt aber nur zum Mischen oder? Der TE möchte ja Bilder erzeugen, wenn ich das richtig lese! Das wäre auch mein Ansatz. Ich möchte Flächengrafiken auf der Grundlage von mathematischen Iterationen herstellen. Es sind keine Apfelmännchen, aber das Prinzip ist ähnlich: Je nach Ausgang einer Iteration (unendlich, null, -unendlich oder einer sich abzeichnenden Konvergenz) soll eine bestimmte Farbe aktiviert werden und der Bereich markiert werden können. Grafikarten können sowas standardmässig nicht, können aber mit GPU-programming dazu hingeführt werden, wenn ich die Beiträge richtig interpretiere. Andererseits werfen einige den FPGA in die Diskussion: Jürgen S. schrieb: > kann man dies einfrieren und in eine pipe wandeln. Wie macht man das konkret und bis zu welcher Tiefe ist das sinnvoll?
> Das taugt aber nur zum Mischen oder? Der TE möchte ja Bilder erzeugen, > wenn ich das richtig lese! Diese Spec kam erst später ;) Allerdings kann man auch Videos abspielen, Flash oder dynamisches HTML einblenden.
Moin, wenn ich das hier so kreuzlese, wollt ihr eigentlich Sachen machen, die in der Gamer-Szene zum 0815 gehören. Ist bei mir inzwischen 15 Jahre her, da gab es CUDA noch nicht, sondern Direktprogrammierung der Shader war angesagt. Da gingen aber schon auf einer einfachen 120€-Geforce Echtzeit-Juliamengen, usw. > > Grafikarten können sowas standardmässig nicht, können aber mit > GPU-programming dazu hingeführt werden, wenn ich die Beiträge richtig > interpretiere. > Die Shader-Units können sowas definitiv. > Andererseits werfen einige den FPGA in die Diskussion: > > Jürgen S. schrieb: >> kann man dies einfrieren und in eine pipe wandeln. > > Wie macht man das konkret und bis zu welcher Tiefe ist das sinnvoll? Gegenüber einer GPU sehe ich da den Sinn nicht so wirklich, ausser, man möchte a la Milkymist was dediziertes kreieren. Nicht aber, wenn's in richtung Raytracing geht. Dazu sind nicht mal zwingend Shader-Schweineren nötig, rein mit OpenGL kann man schon eine Menge hinfaken, dass es aussieht wie RT, pures RT a la povray verbrät eher sinnlos Zyklen. Sobald irgendwas über ein paar Frames iteriert werden muss, dürfte auch das FPGA gegenüber den Shader-Units (damals waren's glaube ich 256) verlieren. Zudem kommt man in den Genuss, sich mit RAM-Anbindung herumschlagen zu dürfen, im Zusammenhang mit strengen Video-Timings ist das schon mal so ein n-Monate-Projekt. Schneller dürfte definitiv gehen, den CUDA-Renderer von Blender an seine Zwecke anzupassen. Gruss, - Strubi
Strubi schrieb: > wenn ich das hier so kreuzlese, wollt ihr eigentlich Sachen machen, die > in der Gamer-Szene zum 0815 gehören. Wir wissen nicht so wirklich genau, was der Themenersteller denn nun eigentlich machen will. Anscheinend ist er der Meinung, dass genaue Anforderungen zu nennen ihm irgendwie schaden würde.
Strubi schrieb: > Schneller dürfte definitiv gehen, > den CUDA-Renderer von Blender an seine Zwecke anzupassen. Hier werden mehrere Themen in einen Topf geworfen: 1) Videomischen 2) Echtzeitrendering 3) CUDA für allgemeine Berechnung Wir verwenden Blender, um unsere Produkte zu designen und zu visualisieren, weil sie "in die Landschaft passen müssen" und wir vor der Geräteherstellung wissen möchten, wie es aussieht und sich einfügt. Da geht es von der Kabel- und Knopfdruckbewegung bis hin zum Schwenk von Armen und Greifsystemen, Pipetten und Injektionsnadeln. Wir haben 3 Rechner mit ziemlich fetten Grafikkarten jenseits der 1000-Euro-Grenze aber in Echtzeit geht da so ziemlich garnichts. Man kann allerhöchstens ein Drahtgittermodell mit 20fps drehen lassen und schauen, ob an die OBjektbewegungen richtig hingestellt hat. Für die Fertigstellung rechnet Blender später an einem einzigen Bild jeweils 1-2 Minuten und zur gesamten Animation sind es etliche Stunden. Für einen 5min Film braucht ein Rechner die ganze Nacht. Auch bei iterativen Berechnungen kenne ich mich sehr genau aus: Einen erheblichen Anteil der Simulationen für FEM-Berechnungen mache ich mit CUDA-Nutzung und wir haben disbezüglich auch Profisoftware im Einsatz von der ich mal ausgehe, dass sie optimiert ist, wobei ich behaupte, dass meine eigene auch nicht so gant schlecht sein dürfte :-) Für die Lösung einer Ausgleichsrechnung für mechanische Spannungen in einem Roboterarm braucht es Millionen Elemente und so rechnet die Karte bei fast 90 Grad am Anschlag minutenlang rum, um eine einzige Lösung zu erhalten, die quasi einem Momentanzustand entspricht, den man abbilden könnte. Um das in der Zeitachse genau genug aufzulösen, braucht es aber 100 Bilder die Sekunde und mehr, und somit nicht nur das, was mit Video geht. Will sagen: Bei solchen Vergleichen müsste man nochmal genau präzisieren, was bei den "gamern" anders gemacht wird, was dort genau gemacht wird und mit welchen Wiederholraten es jeweils geschieht. Einfach ein paar Männeken durchs Bild rennen lassen, die rumballern, die Hüte fliegen lassen und ihr Blut versprühen, ist halt was komplett anderes, als eine wissenschaftlich genaue Rechnung, die mit der Realisät übereinstimmt.
Strubi schrieb: > Ist bei mir inzwischen 15 Jahre her, da gab es CUDA noch nicht, sondern > Direktprogrammierung der Shader war angesagt. > Da gingen aber schon auf einer einfachen 120€-Geforce > Echtzeit-Juliamengen, usw. Hättest Du da etwas anzubieten? Ich meine, dass die Julia-Rechnungen ungefähr so komplex sind, wie die Mandelbrotmengen und bei denen weiß man ja, daß die Zahl der Iterationen ausschlaggebend ist. Oft sind das bis zu 1000 pro Punkt. Wieviel schneller ist da so eine shader unit?
Moin, > Für die Lösung einer Ausgleichsrechnung für mechanische Spannungen in > einem Roboterarm braucht es Millionen Elemente und so rechnet die Karte > bei fast 90 Grad am Anschlag minutenlang rum, um eine einzige Lösung zu > erhalten, die quasi einem Momentanzustand entspricht, den man abbilden > könnte. Um das in der Zeitachse genau genug aufzulösen, braucht es aber > 100 Bilder die Sekunde und mehr, und somit nicht nur das, was mit Video > geht. Ich glaube nicht, dass der TO wissenschaftliche Simulationen im Sinn hatte. Das ist auch generell nicht der richtige Ansatz. Der Weg ist typischerweise, gut zu bescheissen, dass es so aussieht, wie Raytracing/Radiosity, aber keine ist. > > Will sagen: > > Bei solchen Vergleichen müsste man nochmal genau präzisieren, was bei > den "gamern" anders gemacht wird, was dort genau gemacht wird und mit > welchen Wiederholraten es jeweils geschieht. > Vieles landet gar nicht in Game-Engines, aber es gibt eine Unmenge an Demos, wo eben gut getrickst wird. Bekannt sind sicher The Onion Team. Eher in 'seriöse' Richtung gehen dann die Tricks von Geomerics und Konsorten, oder auch div. Firmen, die Voxel-Rendering machen. > Einfach ein paar Männeken durchs Bild rennen lassen, die rumballern, die > Hüte fliegen lassen und ihr Blut versprühen, ist halt was komplett > anderes, als eine wissenschaftlich genaue Rechnung, die mit der Realisät > übereinstimmt. Das will man ja eben nicht. Es soll gut aussehen. Bisher sehe ich nur ein Stereo-Beispiel vom TO, was sich vermutlich problemlos in Echtzeit per OpenGL realisieren lässt und keine FPGA-technik nötig hat. M. W. schrieb: > Hättest Du da etwas anzubieten? > Ich meine, dass die Julia-Rechnungen ungefähr so komplex sind, wie die > Mandelbrotmengen und bei denen weiß man ja, daß die Zahl der Iterationen > ausschlaggebend ist. Oft sind das bis zu 1000 pro Punkt. Wieviel > schneller ist da so eine shader unit? Der Code liegt wohl auf irgend einer CD im Keller, nur die Grafikkarte ist längst im E-Schrott. Ist auch keine Hexerei gewesen, das grösste Problem war, sich die nvidia-Specs zusammenzusuchen und den Shader-Microcode richtig zum laufen zu kriegen. Das war irgend son Ordner mit div. Beispielen (Wasseroberfläche mit Reflexion, etc.). Bis ich das gefunden habe... Mal eben kurz gegoogelt, damit bist du wohl schneller: https://github.com/etotheipi/CUDA_Fractal Es ist schon so, dass der Realtime-Zoom nur bis zu einer gewissen Iterationstiefe geht, danach wird die Julia/der Apfelmann eben schwammig, oder die Framerate ging eben runter auf 10. Wie schnell die Shader getaktet waren, weiss ich nicht mehr, aber dass man entweder 128 oder 256 parallel füttern konnte. Ein Kumpel hat mit ner Suchbaum-Optimierung nochmal Faktor 5 rausgeholt. Aber wie gesagt, lange her. War nach der zweiten Pleite unseres damaligen Arbeitgebers "NaN Technologies BV" :-) Apropos: Blender als Ganzes darf man auch nicht als Mass nehmen, da das Objekt-"Kernel"/Scenegraph, wenn man es überhaupt so nennen kann, nicht mords optimiert ist, ab vielen Objekten wird's lahm, das liegt aber ansich nicht am Renderer. Gruss, - Strubi
Strubi schrieb: > Es ist schon so, dass der Realtime-Zoom nur bis zu einer gewissen > Iterationstiefe geht, danach wird die Julia/der Apfelmann eben > schwammig, oder die Framerate ging eben runter auf 10. Das ist das Problem. Das dynamische handling der Daten ist ja hier dreidimensional, was FPGA ebenfalls eine Iterationsschleife erfordern würde. Dazu braucht es entweder eine vollständige ausgerollte pipelinefähige state machine, die dafür keiner bauen würde, weil zu aufwändig und zu lange, oder eine dynamisch umschaltbare pipeline über Zeit, Iteration und Kanal, also das, was ich 3D-pipeline nenne. Das ist hoch effektiv, da zu jedem Zeitpunkt alle realisierten Architekturen rechnen, aber es hat natürlich trotzdem sein Limit im Systemtakt und der ist nun mal ein Faktor 10 geringer, als bei der CPU. Nehmen wir mal eine Iteration von durchschnittlich 1000, dann braucht man mit einem 200 MHz-FPGA-Design 100 solcher Units um für ein full-HD-Bild 10 fps zu erzielen und man braucht einen Bildspeicheir. Mit Echtzeit-Erzeugung on the fly ist da nix. Damit geht nur das hier: Beitrag "Re: So schön können Rechenfehler sein"
Mark B. schrieb: > Martin K. schrieb: >> Er ist übrigens auch der Ansicht, dass die gewünschten Effekte nicht mit >> Grafikkarten allein zu machen sein werden. > > Welche auch immer das sein mögen. :-/ du scheinst ja echt scharf drauf zu sein, meine Ideen abzuchecken, oder? :-) Du wirst akzeptieren müssen, dass die Details dazu in meinem Kopf bleiben.
Martin K. schrieb: > Details Hier liegst Du falsch. Es geht nicht um Details, sondern um absolut relevante Informationen, ohne die man Dir nicht weiterhelfen kann. Warum Leute andere um Hilfe fragen, wenn sie nicht willens sind ihr Problem hinreichend genau zu beschreiben, wird mir immer ein Rätsel bleiben.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.