HDMI Video-Mischer Experimental-Systen

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.

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.

https://www.blackmagicdesign.com/products/atemtelevisionstudio ist mit 
unter 1000 Euro dabei.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
>
> 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)

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

;-)

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?

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.

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!

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.

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.

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:
> 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.

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:
> 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:
> 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.

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?

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:
> 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

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.